Re: CSV, NBB

> > > > > "Matthew" == Matthew Elvey <matthew(_at_)elvey(_dot_)com> writes:
    >> 
    Matthew> Not true.  If recipients of x %, e.g. 90% of the mail out
    Matthew> there implement NBB, then as soon as you publish MARID
    Matthew> records for your domain, you'll get around x %, e.g. 90%
    Matthew> fewer joe jobs.

Agreed.  But I have to wait for a substantial proportion of the
Internet to implement NBB before I begin to see the benefits.

    Matthew> Meng's latest SPF plan (in which he has borrowed my idea
    Matthew> of CSV semantics using SPF records) makes it much easier
    Matthew> to implement SPF than the plan in the current RFC draft.
    Matthew> Implementation of SPF by nearly all legit senders will be
    Matthew> much more feasible soon. Yay!

It's an interesting idea; do you know if an ID is forthcoming?

    Matthew> BTW, you are not accurate when you say SPF 'endorses'
    Matthew> SMTP rejection.  The spec says "An SPF email system MAY
    Matthew> choose to reject or discard email on the basis of local
    Matthew> policy." It also says "MTAs MAY reject the message using
    Matthew> a permanent failure reply code.  (Code 550 is
    Matthew> RECOMMENDED. ...)"  That's MAY, not SHOULD or MUST.

I misremembered.  But I'd still call that an endorsement.  It's not
exactly a SHOULD NOT.

    Matthew> I would be interested to hear what others think - should
    Matthew> SMTP+SPF receivers reject or discard messages that SPF
    Matthew> "fail" (e.g. hit -all, not "error" or "unknown")?
    Matthew> (Perhaps it makes sense to reject for a while by default
    Matthew> and then sunrise discard as the default.)

I'm dead against that.

For the record, this is my current position:

I think SMTP-time rejection should be used whenever possible.  I'm
currently of the position that when it's not possible it's reasonable,
and even disirable, to originate a bounce, despite the high
probability that the MAIL FROM may be forged.  I'm willing to be
convinced otherwise on this point though...

I'm absolutely dead against the idea of lying in the SMTP response
codes, and claiming you've accepted the message when you've already
determined you're going to do know such thing.  That way lies madness.

I can see why it might be expedient to do this (AFAICS it's the only
way to prevent upstream bounces to forged addresses) but as I said
before (IMHO) the cure is worse than the disease...

       -roy