[Mimedefang] Streams and MaxRecipientsPerMessage

David F. Skoll dfs at roaringpenguin.com
Mon Apr 18 15:21:41 EDT 2005


WBrown at e1b.org wrote:

> OK, since we're adjusting how we all look at mail as we deal with spam 
> filtering, maybe this is one thing that should be tweaked.  Allowing each 
> recipient to set their own rules (which is why we have stream by 
> recipient) should be integral in the new world of SMTP.

There have been a few proposals to remedy this, but none has made it
very far in the standardization process.  The two proposals I saw
were:

1) An extension that allows one response *per recipient* after the final
dot after DATA.  So if both ends agreed to the extension, the conversation
would go something like this:

      S 220 server ESMTP
      C: EHLO client
      S: 250-server Hello
      S: 250-DSN
      S: 250 MULTIRETCODE
      C: MAIL FROM:<sender at domain.net> MULTIRETCODE=1
      S: 250 2.1.0 Sender OK
      C: RCPT TO:<recip1 at domain.net>
      S: 250 2.1.5 Recipient OK
      C: RCPT TO:<recip2 at domain.net>
      S: 250 2.1.5 Recipient OK
      C: DATA
      S: 354 Enter mail, end with "." on a line by itself
      C: <sends data followed by .>
      S: 250 2.0.0 Message accepted for delivery
      S: 551 5.7.1 Message rejected - unacceptable content

So the 250 reply code is for recip1 and the 551 is for recip2.

2) Another extension involves a "CPRCPT" command.  You do this (I won't show
all the server responses this time):

      C: MAIL FROM:<sender>
      C: RCPT TO:<recip1 at domain.net>
      C: DATA
      C: <sends data followed by .>
      S: 250 2.0.0 Message accepted for delivery
      C: CPRCPT <recip2 at domain.net>
      S: 551 5.7.1 Message rejected - unacceptable content

Either extension would do what we need.  I think (2) is cleaner
because it doesn't break the expectation of exactly one reply code
per command.

We just need the IETF to go along with this.  We then also need
everyone who runs an MTA to upgrade. :-( Remember, even with these
extensions, it's in spammers' interests NOT to use them, and unless
they become mandatory, we're stuck.

Regards,

David.



More information about the MIMEDefang mailing list