On 6/19/04 5:25 AM, Roy Badami sent forth electrons to convey:
"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'm simply being honest about the suggested disposition of such
messages, where other proposals avoid *explicitly* saying that in
situation S, accepting and destroying a message is appropriate. But
it's implicit, even when there are statements such as "An SPF email
system MAY choose to reject or discard email on the basis of local
policy" and "Policy decisions regarding particular messages are outside
the scope of SPF." (See SPF quote below as well.)
Is this acceptable? :
The NBB idea is:
Take CSV, and add a new requirement: mail that has failed (as in
there is a MARID record AND the sending IP isn't there AND there's no
?all) a 2821.FROM check should be treated according to local policy for
such messages.
In other words, DON'T
require SRS, but DO enable mail that goes via non-SRS systems that would
lead to bounces to systems that didn't originate the original message
be treated according to local policy.
Are you for other proposals that avoid explicitly saying that in
situation S, accepting and destroying a message is appropriate, even
though it's obvious that this is what they're endorsing?
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.
Problems would have to occur simultaneously:
* the mail is sent in direct violation of MARID checks, and
* the responsible domain admin has said -all (or the equivalent in
different syntax), not ~all or ?all.
* the mail has gone through a forwarding system and
* the forwarding system has not implemented SRS and
* the forwarding system (e.g. mailing list) isn't whitelisted.
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.
Why not? Your statement lacks an argument.
Nor even would SPFv1.
I think that's incorrect too.
I believe Meng has said that he'd be happy if this is all that SPF+SRS
does. I interpret this to mean Meng disagrees with you on this.
"SPF was originally designed to prevent joe-jobs." - http://spf.pobox.com/
This also proves my point earlier - proposals just aren't being up front
about it, but clearly the intention is to make it safe to accept and
destroy a class of messages. (SPF is supposed to work fine on MUAs.)
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.
No, we have some solutions that ALLOW joe jobs, but make them not
directly end-user-visible (if the receiving server doesn't die under the
load of the joe-jobs it is receiving).
The end system does the accepting and destroying of a message that you
say is not appropriate in other situations.
Also they don't work when users are able to send messages from wherever
(without forging) using their usual email address.
With what I'm proposing, they can still do this.
Once we have protection against unwanted bounces (and we need that
anyway) NBB gains us nothing.
Obviously. The point of NBB is to address this problem. So if it's
solved, there's no point. Circular reasoning. The question is why
my/another solution is better.