[Top] [All Lists]

Re: Proposal for Adjusted DATA Timeout

2008-05-26 17:38:51

John Levine wrote:

But I agree it would be nice to do that in less than 10 minutes.

As I hardly need tell people here, if you make stuff more idiot proof,
you'll meet more ingenious idiots.  I'm wondering how many of the over
10 minute messages were a) of interest to the people they were sent to
and b) couldn't have been worked around reasonably easily.

We wouldn't want to make processes take long. Of course not.

But when a vendor offers generic features to "operators" so that they can do multiple things, some of which are independent of each other:

    - RBM rule based messaging (filters)
    - SpamAssassin
    - Sieve
    - And we can add hash-heavyweight DKIM to this list

and I'm sure I'm excluded a lot of unknowns, then we are no longer in "control" here.

I think 10 minutes is a good enough SWAG, but the issue is not the 10 minutes.

It is MTAs out there, like,, who are fixed on using 5 minutes across the board for all the SMTP states.

Unless I'm reading the Mozilla Thunderbird MTA source code incorrectly, I see a 1 minute socket timeout across the board. I see settings for IMAP but not for the SMTP client.

If we want to address the blow back seriously, then we need to get SMTP clients on board to better understand that it isn't the same old days where quick mail drops off and post mail processing was the name of the game.

In conversation with the customer who highlighted all this, he clearly stated the case when he wrote to us:

    "Well, one of my selling points has been that I DON'T HAVE
     size limits. Some people (using AOL, and other free email)
     have been frustrated by this, so I don't have any size limits.
     In the past, I have sent/received 30-40MB files with no trouble.
     However, since I upgraded to the anti-spam version of the
     mailserver, the duplicate email (because the sending server
     doesn't think it was sent OK) has been coming up as a
     serious problem."

(The AVS version added hooks into the DATA state).

But I pointed out that because there is a 10 minute standard, but in practice, many use lower like 5, this correlates to must having a size limit in order to keep with the current SMTP model.

Finally, yes, in this case, we can speed up the callouts. He was using an simple RBM example we provided and just added lots of rules to it and it also wasn't too smart on skipping thousands of base64 lines. So we can handle that and most likely it will be the end of it.

But I still think 5 minutes is too small to be use by am MTA as a constant value regardless of the file size it is sending.

At the very least, these MTAs need to step it up to the next limit - the 2821 recommendation of 10 minutes when sending multi-megabytes emails.

Short of that, we need a new ESMTP proposal with "Keep Alive" concepts.


Hector Santos, CTO