On Wed, Apr 21, 2004 at 10:56:35AM -0700, Hallam-Baker, Phillip wrote:
|
| The sender has no control over what the receiver does with the
| information, and neither does this group.
|
While this may be true, I do not think it is proper for the
specification to admit it.
I want to explain why I'm concerned about vagueness in the spec
regarding receiver behaviour. This is an important issue for me because
it's one of the few points where we seem to have significant
disagreement. We do agree on pretty much everything else.
My main concern is customer calls. From an ISP point of view, anything
that causes complaints from customers to tech support is bad. If
there's no good answer to the complaint, things get even worse.
If I'm a sender's ISP, the conversation I do not want to have with my
customer is:
- Why did my mail get rejected by third-party-ISP?
- Probably because it contained "viagra" and "penis", sir.
- So?
- So it looked like spam to them, sir.
- But I'm a fertility doctor. What can I do to not get blocked?
- Maybe you could stop talking about penises, sir.
Anything based on heuristics will have this problem. Content filtering
is just the first example.
I would rather have this conversation:
- Why did my mail get rejected by third-party-ISP?
- Because, as the error message says, it was not conformant with
RFC3823, which requires X, Y, and Z.
- Oh. What can I do to not get blocked?
- You could configure your mail client as shown at this URL ...
- And if I do that, my mail won't get blocked?
- Your mail won't get blocked for technical reasons. It may still get
blocked for policy reasons. But try fixing your config first. If
it still doesn't get through we can then try leaning on the receiver
ISP, or you can talk to them directly.
The important thing is that the blocked party should have recourse.
If receiver behaviour is not clearly defined, sender recourse is
similarly undefined. That leads to conversation #1 instead of #2.
You also get a sort of institutionalized second-guessing, which has no
place in a protocol. In some cultures, you expect people to be late and
so you secretly tell them to show up half an hour before you really want
them there, which works for a while, but after they figure out you're
bluffing, you have to increase it to one hour and two hours and three
hours and as the arms race progresses everybody's left guessing about
what time the thing really starts. I'd rather live in a world where you
can expect everybody to show up on time so you just tell them what time.
Of course, for that to work, the people you invite have to be
responsible adults.
A specification that doesn't encourage responsibility can't expect to get it.
Senders have to know what receivers will do before they can publish
records with confidence. There's always a possibility that receivers
will do something undesirable. But if the spec permits ambiguity, that
possibility becomes a probability. And once that line is crossed,
confidence vanishes.
Certainly, if the common cases work well enough so that in practice no
problems arise, that's fine. But in a world where spammers will exploit
any cracks we leave in the system, I am not confident we can trust every
possible receiver implementation to produce unarguable behaviour in all
cases, especially if the costs will fall on parties who are powerless to
affect the situation.
This is why RFCs go to such lengths to specify legal vs illegal syntax.
If syntax is loosely defined and subject to multiple conflicting
interpretations, the spec needs to be fixed. The SPF spec needs to be
fixed because it doesn't say anything about case sensitivity: is "mx"
the same directive as "MX"? It's obvious to me that it is, but the spec
needs to make it obvious to everyone.
Interoperable implementations are not allowed to disagree on syntax.
Why should they be allowed to disagree on semantics?
I understand that it is tempting for receivers to do what they will with
the published MARID information. Receivers are already coming up with
ad-hoc policy. Heck, even the Perl SPF library will read Caller-ID
records and repurpose them toward SPF. This is exactly the sort of
behaviour the specification should not condone. It may still happen,
but it should not happen with the permission of the spec.
If a receiver is going to apply local policy, it should not be able to
claim justification from an ambiguous RFC; it should stand up and say
"yes, the RFC says I should not do this, and I'm doing it anyway; if you
have a problem with that, you may call my customer support desk and
complain."
I do not want receivers to say "well, the RFC doesn't really say
anything about how I should interpret the data, so if I'm interpreting
it in a way that's unfavourable to you, too bad." Those kinds of
responses lead to feelings of powerlessness, rage, and ill-will between
ISPs and their customers. That's a sign of a bad protocol.
If the MARID information is going to be used for 2822 authentication ---
and I believe that it should not, because that conflates the concepts of
sender and author --- then we should at least provide a well-defined
algorithm for all receivers to apply. If the algorithm we come up with
is subject to gaming by spammers, we should admit that LMAP and 2822
just don't go together. We should then focus on LMAP and 2821, and
focus 2822 energies toward crypto.
I believe that 2822 authentication and LMAP don't go together. I
illlustrate the argument here:
http://spf.pobox.com/slides/crossingbeams/0100.html
(click on the rhs of the page to go forward)
I do believe that 2822 authentication is important; I just don't think
LMAP approaches are a good solution for 2822, and to do the job right
we'll need crypto.