--Matthew Elvey <matthew(_at_)elvey(_dot_)com> wrote:
I think CSV can protect 2822.From, and with a major tweak, prevent
joe-job damage, while being much easier to implement broadly than SPFing
, and accomplish the goal of tying email better to a responsible party,
bringing us much closer to a realistic near-FUSSP.
Wow, that's a tall claim, I don't even think Dave has made such a claim.
Remember, whatever the source for the domain that MARID validates,
blacklists and reputation services will be an integral part of the system.
A domain with a MARID record used in email with malicious forged From: is
gonna get in an RHSBL lickety-split: If you get word of From: forgery,
you're gonna be motivated to do some work to get the spammer's domain
blacklisted, for example by putting him in your RHSDRBL (Right Hand Side
Distributed RBL), which will stop the forgery and phishing.
Does that mean we should be checking HELO names against RHSBLs also? Is
that common?
Are users forced to send
through MTAs authorized for the domain they use in outgoing mail: no for
Crocker/CSV, yes for SPF, C-ID, Y!DK (even stricter!). MTA admins just
need to ensure that they are sending appropriate HELO strings, which
nearly all already are, and create DNS records. Wow, that's not a lot of
systems that need touching, relatively speaking! (Around 2 orders of
magnitude fewer than SPF+SRS).
Right, because only HELO is validated, it's a tad easier to set up... but
that's because it accomplishes far less.
ALL the other proposals so far don't
accomplish significantly more than Crocker's CSV, and yet do impose
significantly larger costs.
I strongly disagree with both. Many of the reasons people want LMAP boil
down to "stop joe-jobs and phishing" (which mean checking From:/Sender:)
and "stop bounce spam" (which mean checking MAIL FROM). It's possible that
CSV+{something else} could do this, but CSV by itself cannot.
The problem with this argument is that
CSV lacks the early adopter self-interest motivation of SPF: preventing
joe-jobs. Early on, a spammer can use any SMTP server to send From: or
MAIL FROM forgeries of an early adopter's domain.
Right, you have hit on it. CSV doesn't protect From: or MAIL FROM. It
might do so when added to some other part, but I would need to see that to
evaluate it. I believe CSV by itself is not complete enough to be called a
"solution" to anything MARID-related.
If CSV can be tweaked
to provide this early adopter self-interest motivation, it becomes a
killer proposal. One (not great) way to do this would be to combine it
with SPF, but that comes with SRS, and adding something that makes
adoption much harder in order to make it more compelling for early
adopters is a tough bargain. I think I've found a better way. How 'bout
this: No SRS required, but 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 MUST NOT be bounced; instead it MUST either be
refused at SMTP time, or accepted and destroyed. In other words, DON'T
require SRS, but DO require that mail that goes via non-SRS systems not
lead to bounces to systems that didn't originate the original message.
That's an interesting idea. I like it. However, SPF can do this all on
its own... if SPF check fails, the receiver may choose to pass the message
along anyway but with a return path that leads to null. CSV is not really
doing any heavy lifting in that scenario.
PS Yes, my views on the criticality of MARID directly and fully
protecting 2822.From have changed - I didn't see that there was an
alternative way to protect it.
I guess I still don't see it. CSV needs something added to it... something
I haven't seen yet. By itself it is neither necessary nor sufficient for
what I want.
PPS, I know Andrew just posted that we should do 2821, then 2822. The
details of how and why people will adopt MARID I think suggest strongly
that we not go down that road.
Actually, CSV is a 2821 proposal.
(FYI, SPF was recently modified so that the HELO parameter can be checked
at any time, not just when MAIL FROM is null, so SPF can now protect the
HELO name similar to the way CSV does, but with a simpler setup)
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>