Re: CSV, NBB

> > > > > "Matthew" == Matthew Elvey <matthew(_at_)elvey(_dot_)com> writes:
    Matthew> Are you for other proposals that avoid explicitly saying
    Matthew> that in situation S, accepting and destroying a message
    Matthew> is appropriate, even though it's obvious that this is
    Matthew> what they're endorsing?

No; I'm against blackholing messages under any circumstances.  We'll
end up with an unreliable mail transport and we'll lose an important
debugging aid.

    Matthew> Problems would have to occur simultaneously: 
    Matthew> * the mail is sent in direct violation of MARID checks, and 
    Matthew> * the responsible domain admin has said -all (or the equivalent
    Matthew>   in different syntax), not ~all or ?all.
    Matthew> * the mail has gone through a forwarding system and 
    Matthew> * the forwarding system has not implemented SRS and 
    Matthew> * the forwarding system (e.g. mailing list) isn't whitelisted.

I'm more concerned with problems like misconfigured MARID records....

    >> NBB is not going to prevent the problem of joe jobs.
    >> 
    Matthew> Why not?  Your statement lacks an argument.

Because the proposal endorses SMTP level rejection (which I'm all in
favour of).  In many circumstances this will cause the upstream MTA to
bounce the message to the MAIL FROM.

    >> Nor even would SPFv1.
    >> 
    Matthew> I think that's incorrect too. 

Because again SPF mandates SMTP rejections.  Consider forged mail sent
through an open relay.  At the moment, only the undeliverable mail
will bounce to the MAIL FROM.  SPFv1 causes more of the forged mail to
be rejected and actually makes the joe job problem worse...

    Matthew> I interpret this to mean Meng disagrees with you on this.
    Matthew> "SPF was originally designed to prevent joe-jobs." -

I've never believed this, but that doesn't mean I'm against SPF and
other MARID schemes.  They're valuable for other reasons.

The only way SPFv1 will prevent joe jobs is that if it's so successful
and widely deployed that spammers completely give up attempting to
send forged mail since they know it zero chance of reaching its
recipient.  I don't see that happening in the medium term, if ever.

    Matthew> No, we have some solutions that ALLOW joe jobs, but make
    Matthew> them not directly end-user-visible (if the receiving
    Matthew> server doesn't die under the load of the joe-jobs it is
    Matthew> receiving).

Yes, that's true.

    Matthew> The end system does the accepting and destroying of a
    Matthew> message that you say is not appropriate in other
    Matthew> situations.

Correct.  It's not ideal, but it's the lesser evil.  And it happens at
a place where useful logging can occur.  And I believe it's going to
happen anyway.

    Matthew> Also they don't work when users are able to send messages
    Matthew> from wherever (without forging) using their usual email
    Matthew> address.  With what I'm proposing, they can still do
    Matthew> this.

Schemes that use a cryptographic checksum (whether in the MAIL FROM,
Message-ID or an extension header) can be made to work in these
circumstances.

    Matthew> Obviously.  The point of NBB is to address this problem.
    Matthew> So if it's solved, there's no point.  Circular reasoning.
    Matthew> The question is why my/another solution is better.

Because NBB will only prevent forged bounces from arriving in my
mailbox if *everyone* on the Internet implements it (and not even
then, given upstream bounces).

Given that's going to take a long time, I'm going to want to implement
one of the other schemes to give me protection now, rather than years
from now.

The kinds of scheme I describe are starting to be deployed, and I
expect them to start becoming commonplace...  Given this kind of
scheme is going to have to be deployed anyway, NBB adds little value
and removes an important reliability principle and debugging tool.

    -roy