[Mimedefang] Streams and MaxRecipientsPerMessage

James Ebright jebright at esisnet.com
Tue Apr 19 15:06:41 EDT 2005


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




More information about the MIMEDefang mailing list