ietf-mxcomp
[Top] [All Lists]

Re: CSV, NBB

2004-06-19 05:25:58

"Matthew" == Matthew Elvey <matthew(_at_)elvey(_dot_)com> writes:
    Matthew> The NBB idea is: Take CSV, and add a new requirement:
    Matthew> mail that has failed (as in there is a MARID record AND
    Matthew> the sending IP isn't there AND there's no ?all) a
    Matthew> 2821.FROM check MUST NOT be bounced; instead it MUST
    Matthew> either be refused at SMTP time, or accepted and
    Matthew> destroyed.

Personally I'm very strongly against any mandate for accepting and
destroying messages.

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.

NBB would seem to go against this long established principle that
blackholes are bad.  The problem is not with messages that are
genuinely forged, but with messages that are mistakenly determined to
be forged as a result of a configuration error.  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.

NBB is not going to prevent the problem of joe jobs.  Nor even would
SPFv1.  All NBB can do is avoid trying to make the joe job problem
worse as a result of MARID/LMAP checks.  But we need (and will have)
other ways of preventing joe jobs, whether by checking a token in the
envelope address, checking the Message-ID, or something else.

Once we have protection against unwanted bounces (and we need that
anyway) NBB gains us nothing.

If we throw away the principle of reliable mail delivery for short
term expediency, it will be very difficult to get it back, we'll
regret that decision for a long time...

Or in summary: the cure is worse than the disease...

   -roy