On Aug 9, 2010, at 5:10 PM, Dave CROCKER wrote:
> > G'day. > > It's Monday. I'm feeling aggressive... > > Once upon a time, it was deemed important to respond after crlf.crlf as quick > as possible. Pausing for additional processing of varying complexity and > delay was deemed unacceptable. > > There seems to be an emerging constituency that thinks this stricture is not > applicable to modern email services. > > I did a 10-second scan of 5321 and didn't find the relevant text, but I'd > like to resolve -- and preferably squash -- this issue quickly. > > Can folks offer pointers to normative language? Tail end of section 6.1 of 5321: "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. " However the same section also says: "if there is a delivery failure after acceptance of a message, the receiver-SMTP MUST formulate and mail a notification message" If you're doing any useful level of spam / virus filtering then your only option which will comply with both of those requirements will be to send a notification to the reverse-path - which in the case of the vast majority of spam and virus-laden email, is an unrelated third party. Cheers, Steve
