I have no problem with this proposal, per se. However, I don't think it will
help with the spam problem much because I doubt that the illegit spammers will
be using an MTA that supports this option.
Tony
Eric A. Hall wrote:
After some thinking on this, I believe that an adaptation of the LMTP
approach is going to provide the most bang with the least breakage. This
means providing all of the RCPT addresses before the DATA exchange, and
then allowing for per-recipient confirmation after the DATA sequence. This
guarantees that spamtrap addresses work properly, that extensions like
quota are trapped properly, etc., and also preserves the existing state
machinery pretty closely, in that the envelope exchange can "complete"
before data, with the confirmation responses simply being treated as
in-line DSNs.
Focusing exclusively on an "in-line DSN" capability allows for a smaller
protocol machine, and is somewhat different from the deferred RCPT model
used in LMTP. Specifically, I'm suggesting that we provide a mechanism
where per-recipient ACKs are *allowed* but servers can continue to
accept/reject globally as well. Messages that are universally good or
universally bad can still use a global 2xx/5xx after the end-of-data,
while mixed success can be responded to on a per-recipient basis.
An example:
C: EHLO foobar
S: 250 INSTANT-DSN
C: MAIL FROM:<malware> INSTANT-DSN
S: 250
C: RCPT TO:<hardass>
S: 350 will defer
C: RCPT TO:<sucker>
S: 350 will defer
C: RCPT TO:<postmaster> # <---- notice
S: 250 always accepts # <---- notice
C: DATA [...]
S: 550 message contains a virus; unacceptable for all recipients
or
C: DATA [...]
S: 250 content accepted for all recipients
That is basically the same as things work now; the only difference is the
deferred RCPT confirmations, and the confirmations are unnecessary since
the content was globally accepted/rejected.
An example of the deferred responses for the deferred recipients:
C: DATA [...]
S: 350 content smells okay
S: 550 <hardass> does not like this content
S: 452 <sucker> insufficient quota space
S: 250 content accepted for some recipients
<postmaster> accepted earlier so no reason to respond
Another option allowed by this model:
C: MAIL FROM:<malware> INSTANT-DSN
S: 250
C: RCPT TO:<hardass>
S: 350 will defer
C: RCPT TO:<spamtrap> # <---- notice
S: 550 always rejects # <---- notice
C: RCPT TO:<sucker>
S: 550 refuses # <---- now rejects
C: RCPT TO:<postmaster>
S: 550 refuses # <---- now rejects
C: DATA [...]
S: 550 message addresses spamtrap; universally refused
So it seems that this model is the most flexible, preserves the existing
state machinery and extension model, but also provides for per-recipient
acceptance and rejections.
I can write this up pretty quickly (need to figure out a couple of other
small issues first) but otherwise, anybody see any problems with this?
Thanks