MARID to close [LWN.net]

From:		David Woodhouse <dwmw2-AT-infradead.org>
To:		editor-AT-lwn.net
Subject:		[Fwd: MARID to close]
Date:		Thu, 23 Sep 2004 12:09:10 +0100

I don't think I've seen you comment on this. The MARID working group
which was looking at the possibility of standardising something based on
Microsoft's SenderID or the equally fundamentally flawed SPF has
terminated.

Strike one for sanity :)

The problem with SPF and SenderID was that they made flawed assumptions
about how the world works -- in particular with respect to forwarding.
They each put forward a plan to make their assumptions come true, but
they required that _everyone_ out there should upgrade to make it all
viable.

Even if that were a realistic plan, their 'fix' was to make all mail
servers rewrite the 'responsible' address when forwarding mail, to take
responsibility for it themselves. When all mailservers are doing
something like that, it becomes _only_ a way of checking how much you
trust the individual mail server which is sending you the mail.

For example, my server could send a mail claiming to be from
	SRS0+xx+yy+lwn.net+editor@srs.infradead.org
... which _looks_ like it was from editor@lwn.net, but via one of my
servers. You have no idea; you only know how much you trust _me_.

And it _is_ all about trust. With spammers publishing SPF records to get
themselves a 'pass' you had to look up the domain in a
blacklist/whitelist -- some kind of trust database.

But given that SPF/SenderID could only really manage to work out a trust
level for _one_ hop -- the mail server which was actually sending you
the mail -- there was no point in what they were doing, and no point in
all the breakage with forwarding. You might as well have done it based
on the HELO instead, without breaking the whole world while you're at
it.

So let's let SPF and SenderID rest in peace.

Now it's time we got together and fixed up a real end-to-end solution
for verifying mail ownership, like DomainKeys or IIM.

In the interim, if you want to be able to stop receiving bounces to mail
you didn't actually send, try BATV. It's fairly trivial to implement and
it's unilateral -- you can just _do_ it and nobody else needs to know or
care.

http://archives.listbox.com/spf-discuss@v2.listbox.com/20...
http://brandenburg.com/CSV/draft-levine-mass-batv-00.html

-- 
dwmw2

(Log in to post comments)

MARID to close

Posted Sep 30, 2004 9:20 UTC (Thu) by beejaybee (guest, #1581) [Link]

"Now it's time we got together and fixed up a real end-to-end solution
for verifying mail ownership, like DomainKeys or IIM."

What's wrong with PGP/GPG signed messages? I have a lot less faith that spammers would easily be able to forge my electronic signature than that they are able to implant my email address into an RFC header.

The "secure" approach would be

(a) allow mail relays to add new headers but not remove or alter existing ones

(b) at each relay checksum and sign the entire message (using the relay's digital certificate)

Won't stop spammers forging addresses but would make the point of entry of forged messages transparent. Does require full changeover to new system plus implementation of certificate infrastructure.

MARID to close

Posted Oct 1, 2004 9:56 UTC (Fri) by dd9jn (subscriber, #4459) [Link]

The problem with PGP is also the trust database (aka PKI). Don't expect the Web of Trust to magically help you here. It is fairly simple to sign a message with a random key or have zombies signing messages.

MARID to close

Posted Oct 6, 2004 14:17 UTC (Wed) by jschrod (subscriber, #1646) [Link]

Executive summary: Too difficult to use, too much upfront work.

For private email, this might work. But I must be reachable via my business email with as few upfront hurdles as possible -- if I would demand PGP usage from a potential customer (or even from some of my existing customers where non-confidential information is exchanged), they would take their business elsewhere. And, let me tell you, my staff would also not like this; this money pays their salaries, after all.

In addition, the difference between signing and trusting keys is too complex for most users. In particular, for the management types who didn't come in over the technical track. I.e., those with the money...

Even with my email address that I use for Open Source related activities, I want to be reachable. If somebody wants to send me a note on xindy, I want to make it easy for him -- our user community is small enough as it goes, and I'll do anything to bring new people in. (See, I even use LWN comments to plug it. :-)

Btw, from the roughly 500 spam emails I get every day, SpamAssassin with Bayesian training catches ca. 496 (i.e., 4 come through each day); no false positives in emails with a score < 10 in the last 9 months; and I haven't even updated to 3.0 yet. Do other people really have so much a problem with spam in their INBOX?

Cheers, Joachim

MARID to close

Posted Oct 7, 2004 8:15 UTC (Thu) by Wol (guest, #4433) [Link]

Executive summary: Too difficult to use, too much upfront work.

Why? All that is happening is that EACH link in the chain is verified. The end user notices nothing if they don't care. But if somebody IS injecting spam, either they can be tracked back to source if the entire chain is valid, or the point of forgery can be *quickly* identified (and then you can check the ISP's dialup records or whatever :-) or an offending ISP can get slapped upside the head and told to "sign up or we'll blacklist you for encouraging spam".

To repeat - the user will see no change if they don't want to look. But tracking where spam came from will become MUCH MUCH easier.

Cheers,
Wol

MARID to close

Posted Oct 7, 2004 9:33 UTC (Thu) by jschrod (subscriber, #1646) [Link]

???? I don't understand your comment. I was reacting on the proposal to use PGP by the end user, not by signing emails by MTAs.

Anyhow, MTA signing won't work either. PKIs are simply too difficult to setup on a global scale. There are reasons why no large PKI deployments are really available, beyond the scale of one company. The Web of Trust for MTA keys? C'mon -- do you propose keysigning parties for all who run an MTA? And before you ask: I don't think that Verisign et.al.'s X.509 certificates are a good and valid PKI. There is no implemented and deployed revocation infrastructure. (Revocation is also a problem with real-world usage of PGP, btw.) My company does security, and I have struggled with digital certificate implementations for more than a decade already -- I know that all proposals from that area that tell `it's easy' or `no problems for the end users' are rubbish. No personal offense to you, just my factual experience.

Joachim

MARID to close

Posted Oct 2, 2004 23:10 UTC (Sat) by giraffedata (subscriber, #1954) [Link]

I think you missed the point of this technology. If I trust you, it's because I know you wouldn't send me a mail claiming to be from lwn.net unless you had verified the claim yourself. And you have two ways of verifying that: 1) it came from a server that you trust to have verified it; or 2) you looked up lwn.net in DNS and found out that the server you got it from is specifically authorized to send mail for lwn.net.

In practice, nobody's going to trust your personal mail server anyway. I trust my own mail gateways or ISP, and that's it. If I get mail from your server claiming to be from lwn.net, I look up lwn.net in DNS myself. If your server doesn't show up as an official sender of lwn.net mail, I assume it's a forgery.

I like this technology because it means my personal mail server, which is never going to be in anybody's trusted list, can still send mail with from addresses in my own domain. (In fact, I don't even have to add fancy new DNS records, because the from domain's A record points right at my mail server).

Other anti-spam technologies will kill my mail server. I'll be forced to send mail through some trusted institution such as my ISP.