Stats comp.mail.misc (last 7 days)

"Caveat: Quantity is not necessarily a measure of Quality"


Newsgroup.................: comp.mail.misc
Stats Were Taken..........: Mon, 05 Dec 2005 08:06:46 GMT
Stats Begin...............: Mon, 28 Nov 2005 09:35:10 GMT
Stats End.................: Mon, 05 Dec 2005 00:48:31 GMT
Days......................: 7
Total No. of Articles.....: 35
Total No. of Characters...: 79630
Total Volume..............: 77
Messages Per Day..........: 5.0
Characters Per Day........: 11375.7
Average Daily Volume......: 11 kB
Total Posters This Week...: 23
Messages with Sigs........: 14.29%
Original Content Rating...: 74.97%

Top 10 Prolific Posters: Posts / Posts per Day / Percent Share
============================================================ ==
1. Sam...............................................: 4 0.6 11.4%
2. Ynotssor..........................................: 3 0.4 8.6%
3. Ak................................................: 3 0.4 8.6%
4. M1r0..............................................: 2 0.3 5.7%
5. Gamik@Ifrance.Com.................................: 2 0.3 5.7%
6. Mark Crispin......................................: 2 0.3 5.7%
7. dennisj...........................................: 2 0.3 5.7%
8. ng................................................: 2 0.3 5.7%
9. Andrew Butchart...................................: 1 0.1 2.9%
10. Hector Santos.....................................: 1 0.1 2.9%

Top 10 Bandwidth-Consuming Posters: kBytes / kBytes per Day / Percent Share
============================================================ ===============
1. Sam...............................................: 16 2.4 21.6%
2. Ak................................................: 10 1.5 13.2%
3. jari.aaltoATpoboxes.com...........................: 4 0.6 5.7%
4. Garen Erdoisa.....................................: 3 0.6 5.0%
5. dennisj...........................................: 3 0.5 4.7%
6. Ynotssor..........................................: 3 0.5 4.3%
7. Gamik@Ifrance.Com.................................: 3 0.5 4.1%
8. MAS-FAQ...........................................: 3 0.4 4.0%
9. Mark Crispin......................................: 3 0.4 3.9%
10. feenberg..........................................: 2 0.4 3.6%

Top 10 Popular Threads: Posts / Posts per Day / Percent Share
============================================================ =
1. Spam Database.....................................: 5 0.7 14.3%
2. Who should run a mail server?.....................: 5 0.7 14.3%
3. Difference of LOGIN and AUTH in ipop3d logs?......: 4 0.6 11.4%
4. Email Transfer....................................: 4 0.6 11.4%
5. procmail recipie help.............................: 4 0.6 11.4%
6. Mail box full message in when disk qouta reaches 8: 3 0.4 8.6%
7. What e-mail addresses are compulsory?.............: 3 0.4 8.6%
8. procmail locking..................................: 2 0.3 5.7%
9. Better spamtrap...................................: 1 0.1 2.9%
10. Despairing of the current state of IMAP clients...: 1 0.1 2.9%

Top 10 Bandwidth-Consuming Threads: kBytes / kBytes per Day / Percent Share
============================================================ ===============
1. Email Transfer....................................: 14 2.0 18.3%
2. procmail recipie help.............................: 10 1.5 13.7%
3. Who should run a mail server?.....................: 10 1.5 13.4%
4. Spam Database.....................................: 8 1.2 10.9%
5. FAQ: Canonical list of questions Beavis refuses to: 6 1.0 8.6%
6. What e-mail addresses are compulsory?.............: 5 0.8 6.8%
7. Difference of LOGIN and AUTH in ipop3d logs?......: 4 0.7 6.4%
8. Fighting email spam and anti-UBE pointers.........: 4 0.6 5.7%
9. Mail box full message in when disk qouta reaches 8: 3 0.5 4.6%
10. Pointer to Mail Archive Servers FAQ...............: 3 0.4 4.0%

Top 10 Original Content Ratings: (Original Bytes) / (Orig. + Quoted Bytes)
============================================================ ==============

Top 10 Crossposting Groups: Posts in Group
==========================================
1. comp.answers................................................ .: 2
2. news.answers................................................ .: 2
3. comp.sources.wanted......................................... .: 1

===============================
End of stats for comp.mail.misc







--

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

Email expiry?

Hi,

is there any standard to add an email header
for an expiry date?

If this expiry is reached and the mail is not yet delivered
the MTA shall delete the mail.

Is something like this existing?

thanks for some comments,

Marcel

Re: Email expiry?

Marcel Ruff wrote:
> Hi,
>
> is there any standard to add an email header
> for an expiry date?
>
> If this expiry is reached and the mail is not yet delivered
> the MTA shall delete the mail.
>
> Is something like this existing?
>
> thanks for some comments,
>
> Marcel

This is an automatic function of email server software so you don't have
to worry about it.

For example: sendmail when it accepts an email for delivery will queue
any given email for up to 5 days and keep trying to deliver it until it
either delivers the mail to the intended recipiant, or times out. If it
times out in the queue, then sendmail will attempt to return the email
to the apparent sender (the email address in the Return-Path: header
field), or if that fails, will attempt to deliver the email to
postmaster@localhost, so that eventually a human should be made aware
that there is a possible problem. If sendmail can't deliver a queued
email to anyone, I believe that it will just delete it.

I believe that most standard email server software will do similar
things, though the queue timeouts may vary with each.

Garen

Re: Email expiry?

Garen Erdoisa wrote:
> Marcel Ruff wrote:
>
>> Hi,
>>
>> is there any standard to add an email header
>> for an expiry date?
>>
>> If this expiry is reached and the mail is not yet delivered
>> the MTA shall delete the mail.
>>
>> Is something like this existing?
>>
>> thanks for some comments,
>>
>> Marcel
>
>
> This is an automatic function of email server software so you don't have
> to worry about it.
>
> For example: sendmail when it accepts an email for delivery will queue
> any given email for up to 5 days and keep trying to deliver it until it
> either delivers the mail to the intended recipiant, or times out.

Hi Garen,

thanks for this insight.

But what is this 'times out'?
Is this time out value an attribute of the email itself or an attribute
of the MTA configuration?
I have the case where a 'ping' email should timeout and be dropped after
some 60 seconds, whereas some other emails containing database replication
information should timeout after 2 hours (and be silently erased after that).

In my case the expiry is a characteristic of the email instance
and not of the MTA.

If i would introduce an email header like

"X-EmailExpiryDate:2005-12-08T12:45:01"

does this have any impact on delivery or leads to misbehaving MTAs?
Do i have to take care on naming conventions?
I could then write a plugin for my final MTA (james.apache.org)
which drops such mails.

Any better ideas?

Thanks
Marcel

> If it
> times out in the queue, then sendmail will attempt to return the email
> to the apparent sender (the email address in the Return-Path: header
> field), or if that fails, will attempt to deliver the email to
> postmaster@localhost, so that eventually a human should be made aware
> that there is a possible problem. If sendmail can't deliver a queued
> email to anyone, I believe that it will just delete it.
>
> I believe that most standard email server software will do similar
> things, though the queue timeouts may vary with each.
>
> Garen

Re: Email expiry?

>Hi Garen,
>
>thanks for this insight.
>
>But what is this 'times out'?
>Is this time out value an attribute of the email itself or an attribute
>of the MTA configuration?
[snip]

In general it's clearly an MTA configuration issue. The RFC's define
that e-mails must time out and they also define that the duration over
which delivery attempts have to be made are reasonable long, but there
are no strict values give. From my personal experience I would say
most MTAs try for several days in the range of 4 - 5 days.

If you introduce a header line as you proposed it's up to your plugin
(in other words your personal implementation of your MTA) to do with
it what you want.

While you are fine with the naming convention by using an X- header, I
still would name the header so as it's very unlikely to result in a
conflict. I.e. you could include your "product" name into it and
create something like "X-myplugin-ExpiryDate yadda yadda"

HTH

Markus

Re: Email expiry?

Marcel Ruff wrote:
> Garen Erdoisa wrote:
>
>> Marcel Ruff wrote:
>>
>>> Hi,
>>>
>>> is there any standard to add an email header
>>> for an expiry date?
>>>
>>> If this expiry is reached and the mail is not yet delivered
>>> the MTA shall delete the mail.
>>>
>>> Is something like this existing?
>>>
>>> thanks for some comments,
>>>
>>> Marcel
>>
>>
>>
>> This is an automatic function of email server software so you don't
>> have to worry about it.
>>
>> For example: sendmail when it accepts an email for delivery will queue
>> any given email for up to 5 days and keep trying to deliver it until
>> it either delivers the mail to the intended recipiant, or times out.
>
>
> Hi Garen,
>
> thanks for this insight.
>
> But what is this 'times out'?
> Is this time out value an attribute of the email itself or an attribute
> of the MTA configuration?

It's an attribute of the MTA configuration, probabaly defined at compile
time. Users normally have no control over it. Typically a server will
send a notification of attempted delivery after about 4 hours, but will
keep trying for several days until the MTA finally gives up or receives
a 5xx reject message from the recipient's server.

> I have the case where a 'ping' email should timeout and be dropped after
> some 60 seconds, whereas some other emails containing database replication
> information should timeout after 2 hours (and be silently erased after
> that).
>
> In my case the expiry is a characteristic of the email instance
> and not of the MTA.
>
> If i would introduce an email header like
>
> "X-EmailExpiryDate:2005-12-08T12:45:01"
>
> does this have any impact on delivery or leads to misbehaving MTAs?
> Do i have to take care on naming conventions?
> I could then write a plugin for my final MTA (james.apache.org)
> which drops such mails.

We are talking about a couple of different layers here. One the MTA
(Mail Transport Agent) and MDA (Mail Delivery Agent)

The queue timeout I was referring to is in the MTA layer. i.e.: where
you send an email, another server receives it, accepts it and queues it
for delivery. Usually the delivery handoff is immediate, but in cases
where a temporary failure 4xx message is received, or the MTA can not
contact the next server in the chain, it will just leave the email in
it's queue, and keep trying to deliver it until finally giving up. This
default queue timeout for sendmail is set at 5 days. The reason it is so
long is to give site administrators enough time to recover from failed
hardware, system crashs, power failurs, network outtages, etc. and not
lose any queued email that was attempted during the outtage.

Once the mail is on the final destination server, that MTA on the final
destination server will handoff the mail to the MDA on that same server
to deliver it to the intended mailbox.

In the X-header you mention above, the MTA generally will pay no
attention to any X-header. Depending on the MDA some (such as procmail)
can be programed to pay attention to such headers. This is controlled by
each recipient or server admin.

I am not aware of any specific standard header that a sender could add
to an email that would cause a email held in an MTA queue to timeout early.

Even if there is a header that could be used as such (I don't remember
ever reading about such a header), it would still be up to each email
administrator to configure their servers to honor or ignore such headers.

You might want to check the following RFC's for an answer to your
questions about standard email headers.

RFC821
RFC2821
RFC2822
RFC3464
RFC3851

If there is such a header you can use, it should be documented in one of
those RFC's.

>
> Any better ideas?
>
> Thanks
> Marcel
>
>> If it times out in the queue, then sendmail will attempt to return the
>> email to the apparent sender (the email address in the Return-Path:
>> header field), or if that fails, will attempt to deliver the email to
>> postmaster@localhost, so that eventually a human should be made aware
>> that there is a possible problem. If sendmail can't deliver a queued
>> email to anyone, I believe that it will just delete it.
>>
>> I believe that most standard email server software will do similar
>> things, though the queue timeouts may vary with each.
>>
>> Garen

Garen

RE: Email expiry?

Hi again,

this is a answer for a question is send 2006-01-21.

This is what i currently know about how to mark an email
with an expiry flag (email can be deleted if date has elapsed):

RFC1036 defines a "Expires:" header (for news)

RFC2156 defines an optional "Expires:" header for X.400 -> RCF822(email) gateway
(Before in RFC1327 its name was "Expiry-Date:")

The MTAs will probably ignore it so you have to implement
discarding the mail yourself...

regards
Marcel