Roy Badami <roy(_at_)gnomon(_dot_)org(_dot_)uk> wrote:
Personally I'm very strongly against any mandate for accepting and
destroying messages.
This is already happening on the net today, due to deficiencies in SMTP.
I don't believe that this or any other IETF WG should be contemplating
removal of the mandate in RFC 1123 5.3.3 and RFC2821 6.1 that once
mail has been accepted it MUST be either delivered or bounced.
That requirement is impossible to implement in practice. SMTP makes
*no* provisions for verifying that a bounce path exists. Therefore,
once a message has been accepted for delivery, it is *impossible* to
bounce it in the general case. The MTA can try, but there's no
guarantee that the MAIL FROM parameter will be resolvable, or that the
host will even know about the message which caused the bounce.
All of the RMX/SPF/etc. proposals can be looked at as giving the
recipient more information with which to validate the bounce path.
This property is independent of their other effects.
Obviously rejection at the SMTP level is best (but this may just
generate a bounce upstream anyway), but if this is not possible then
it is vital that these messages are bounced, rather than discarded,
to allow the configuration error to be detected and corrected.
Bounced where? How can you tell that the bounce path is valid, and
that you're not spamming the MAIL FROM site with bounces from forged
messages?
Alan DeKok.