Brian, I am taking this conversation back on-list now that the draft is
public.
On Tue, Feb 24, 2004 at 06:24:28PM +0000, Brian Candler wrote:
|
| I like this because it attempts to crack the correct nut - namely, From:
| header forgery, rather than envelope sender forgery. Its mechanism for
| dealing with forwarding (just adding Resent-From: headers) is also arguably
| simpler than envelope sender rewriting.
Its forwarding model is better in theory, but breaks in practice
(if you bounce/forward a message to someone from your MUA, the Resent-*
headers are *appended* not *prepended*) so the model fails.
Trying to attack From: forgery without crypto is unwise, because what
will you do when spammers forge
From: bad(_at_)spammer(_dot_)com (service(_at_)paypa1(_dot_)com)?
I didn't want to make a promise I couldn't keep. If there is a Sender:
or Resent-* header, you get the possibility that what the user sees in
the MUA will be different from the subject of authentication. So you
have to make sure every MUA displays the responsible-sender as
determined by your algorithm. That's a lot of MUAs that will need to
change.
If you can't guarantee that the MUA will display the responsible-sender,
it's hard for an ISP to do the C-ID checking knowing that a message
Sender: bad(_at_)spammer(_dot_)net
From: service(_at_)paypal(_dot_)com
will get through because it is not technically forged.
Given these complexities, I didn't want a situation where people buy a
thing thinking they're getting a certain set of features, but when they
take it home and unwrap it, they find out it doesn't actually work as
advertised.
| But after a quick scan, I can't see that it really discusses the SMTP
| envelope at all; nor what would be an appropriate action to take at a
| forwarding host or end-point host if a header were determined to be invalid.
| Bounce it I guess?
Caller-ID explicitly ignores the SMTP envelope.
Caller-ID's action is to silently sink the message. Bouncing is
definitely wrong because you know the sender is forged. Sinking is less
wrong, but because the sender never sees the bounce and the recipient
never sees the message, it reduces the integrity of the email system.
Rejecting at SMTP time is the only way to give the sender a chance.
This is why I consider SPF more FP-friendly; if SPF wrongly rejects a
message at least the sender gets a URL in the bounce message with
detailed instructions about how to reconfigure. Or they can just pick
up the phone and call me. And when we talk, it won't be the
conversation of "did you get my email?" "What email? Maybe it's in my
spam folder."
Many people in the Internet community feel this way; the designers of
Caller-ID perhaps discounted this concern in their design.
Furthermore, rejecting at the SMTP level *before* DATA saves bandwidth
and CPU. The reason we have over 100,000 domain names covered by SPF is
simple: parked domains never send any email, and there are a whole heck
of a lot of them. SPF lets them say "v=spf1 -all" and be done with it.
Caller-ID says "well, I'll download the entire spam/worm/virus first,
and then sink it." DK doesn't even address this, but then it wasn't
really designed to.
I asked the list whether bandwidth was a cost to them, and consensus
appeared to be "yes". I believe the design behind Caller-ID implies
that bandwidth is not a significant cost.