On Tue, 19 Apr 2005 09:41:59 -0400, David F. Skoll wrote > The big downside with option 1 is a potentially long delay after > the end of DATA as the message is scanned N times. For a message > with 100 recipients, this post-DATA delay can be considerable, and > the RFCs explicitly say that implementations should take pains to > minimize the post-DATA delay (because of a potential race condition > if the sender times out before the receiving MTA.)
I am not sure it would be any more or less worse than option 2 in those regards and the potential savings of being able to reject from the MTA prior to the data phase would most likely outweigh any additional costs after the data phase. This is especially true for any messages with payloads that can be blocked based off pre-DATA information. Some of the multi-part mime html spam also approaches absurdity in message size. Besides, why exactly would a MTA have to scan the data part "N times" in any regards... at that point it has a list of recipients and the data... it needs to do no more than it does now when MD scans them individually using stream by recipient, and only then if it finds customized rules for a particular recipient, except perhaps, generate a reject instead of a bounce so that may be a cost savings as well. Personally I would rather run through the recipients prior to the data just for the opportunity to be able to reject before a costly data phase.... esp since any per user filters woudl have to be run afterwards in either case. Jim -- EsisNet.com Webmail Client _______________________________________________ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [email protected] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
