On Fri, Nov 28, 2003 at 12:13:19PM +0000, Matt Bernstein wrote:
> At 11:28 -0000 Chris Edwards wrote:
>
> >I'd be wary of introducing delays at this critical point in the dialog
> >(after DATA). There is a risk duplicating bona-fide mails. The delay
> >between the client sending the `.' and the server sending the response
> >should be as short as possible. See RFC 1047 for discussion of this.
> RFC1047 is dated "Feb-01-1988" and its status is "UNKNOWN". In particular,
> 1988 was pretty much still in those heady days when spam simply wasn't a
> problem, and although viruses did exist, e-mail was not a good medium for
> them to propagate.
The discussion, to be fair, is at least referred to, and the summary (keep
the delay to the minimum) (S4.5.3.2, S6.1 (final para)). You'd be violating
a MUST if you chose to add in a delay there, RFC1047 is referenced as ref
28. I wasn't going to quote it, but, for those of you who don't like going
and looking up such things:
| 6.1 Reliable Delivery and Replies by Email
[...]
| To avoid receiving duplicate messages as the result of timeouts, a
| receiver-SMTP MUST seek to minimize the time required to respond to
| the final <CRLF>.<CRLF> end of data indicator. See RFC 1047 [28] for
| a discussion of this problem.
> >Those of us doing content scanning at this point are in effect going
> >against this advice. However, in our environment, the average scan time
> >is around 0.3 seconds which seems to be quick enough in practice.
> >I think anti-spam delays need to happen earlier in the dialog.
> This is obviously impossible with content scanning!
The other option is to content scan once you've accepted the message,
and do some tagged forwarding and dropping, and leave it up to the
user to deal with policy. This is the MailScanner approach.
> I take your point, but I'm prepared to take the gamble. My Cyrus store can
> deal with duplicates :-P
I've never liked that solution personally, though I have the same system,
with the same properties running on my machine. Mail Message-ID headers
were never, unlike NNTP's, stipulated to be globally unique, and
constructed in such a way as to enforce uniqueness constraints. This, to
me, implies the small, but non-zero possibility of losing mail.
Cheers
MBM
--
Matthew Byng-Maddick <mbm@???> http://colondot.net/
