I'd like to apologize up-front for the length of this post. Feel free
to skim it if you think I'll never get to the point. (I'm likely to
have guessed wrong on some details of SPF anyway.)
Meng Weng Wong <mengwong(_at_)dumbo(_dot_)pobox(_dot_)com> wrote:
On Tue, Jun 29, 2004 at 10:27:50AM -0400, John Leslie wrote:
|
| Andy closed the jabber session with several action items:
|]
|] andy: We were given 3 use cases today. It would be good if meng could
|] take his 2 to the list, and jfenton his to the list.
|] andy: Then let's let the CSV proponents explain two things for each,
|] 1) how CSV handles them, and
|] 2) how SPF does not.
...
[15:43:30] <jlcjohn> Quick answer on case with problem:
workers at home using their cable system to send email for
their work domain.
...
[15:44:14] <mengwong> lemme see what the EHLO and the MAIL
FROM look like real quick.
[15:44:38] <mengwong> (taking the MAIL FROM to be close
enough to the PRA that SPF Classic and SenderID look the
same in this case)
[15:45:15] <mengwong> EHLO cable-12-23-34-56.cty.cableco.net?
...
[15:45:54] <jlcjohn> Actually, it might be that, or the
cable provider might force use of their server.
...
[15:46:07] <mengwong> ok, so we have two subcases ...
[15:46:22] <mengwong> if the cable provider forces use of
their server, we have EHLO mta4.cableco.net
[15:46:28] <mengwong> MAIL FROM:<worker(_at_)work(_dot_)com>
...
This case being simpler, let's start with it.
CSV will take the EHLO mta4.cableco.net, and do both a reputation
check (out-of-band) and a SRV query on _client._smtp.mta4.cableco.net.
Hopefully that will return authorized=1 and list-empty=0, and hopefully
the IP address will match one on the list returned. Thus authorization
will be established. There's a pretty good chance that reputation will
come back OK, because reputation services hate to turn off the main
mailservers of cable providers.
But, IMHO, the cableco.net reputation is unlikely to be good
enough to bypass further checks. For the sake of argument, let's say
the receiving SMTP server chooses to do SPF checks against the
RFC2821 MAIL FROM.
This, alas, will flunk if work.com publishes a SPF record which
does not include mta4.cableco.net. In practice, cable providers have
multiple outgoing MTAs, and work.com will probably have to use the
"include" mechanism for a recursive query or a "redirect" modifier
to tail-recurse to cableco.net. (More likely the former, since they
are likely to have different home-workers at different providers.)
Hopefully, this will all result in a SPF "pass".
Now we come to the reputation question. The reputation queried
will be work.com. Let's break here, and come back to it after
discussing what SPF-without-CSV will do.
SPF-without-CSV may or may not evaluate the EHLO. (I hope I'm
right there: I haven't seen a SPF draft that says otherwise;
please correct me, Meng, if I'm wrong.) If it does, I would expect
it to yield a "pass", no different from CSV.
SPF-without-CSV will evaluate the MAIL-FROM, and the results
will be the same as for the with-CSV case. Hopefully that gets us
back to where we broke off: the reputation question.
The difference between with-CSV and without-CSV will show up in
the reputation-service ratings of work.com. In the with-CSV case,
reputation-service rating of the EHLO cases will always accurately
correlate with the CSV semantics of assuming responsibility, and
_if_ (a big if, as things appear right now, but I'm an optimist!)
cableco.net ever acquires a good enough reputation on EHLO, work.com
will no longer have to include it by reference in its SPF record,
eliminating the risk of work.com's reputation being sullied by a
cableco.net lapse.
Please understand that the social pressure which inflates the
cableco.net rating will _not_ similarly inflate the work.com rating.
Reputation services will feel much freer to downgrade work.com, and
leave it downgraded longer.
I fully agree, BTW, that this difference is subtle, and may not
be worth worrying about. But we're discussing a case which shouldn't
happen in the first place: the case where cableco.net blocks both
port 25 direct sending and port 587 submission.
The way things _should_ happen Meng described as:
[15:45:15] <mengwong> EHLO cable-12-23-34-56.cty.cableco.net?
and
[15:46:28] <mengwong> MAIL FROM:<worker(_at_)work(_dot_)com>
(I think that exact case unlikely, and will describe it only on
request: the EHLO string must be programmed, and IMHO it is unlikely
that the worker would program that funky cableco string.)
Let me instead describe:
EHLO mail4.work.com
MAIL FROM: worker(_at_)work(_dot_)com
CSV will query the reputation of "mail4.work.com" and query for
a SRV record at _client._smtp.mail4.work.com. This will return
authorized=1 and list-empty=0, and the IP address will match if
the DNS record is updated to match the latest IP-shuffle of the
cable provider. (If it hasn't we'll get timely warning when <worker>
tries to send mail from home.)
The reputation will match the actual responsibility for operating
this MTA: good if it's operated carefully, and bad if it's not.
That's important! There's a real incentive to operate carefully.
Let's assume that <worker> does operate carefully. In that case the
reputation report will be excellent, and the receiving SMTP server
will be programmed to skip the SPF check on MAIL FROM.
But if there is to be a (later) SPF check, work.com has no need
to recursively include domains over which it has no control, and
can use tricks like the "exists" mechanism to track potential abuse,
or simply leave the record open with ?all if no problems show up.
Conversely, SPF-without-CSV MAY check EHLO or may not. Hopefully
if it check, it'll pass. But reputation services won't have a clean
division of responsibilities, because work.com will be forced to
use recursive includes. work.com's reputation is likely to suffer
when cableco.net suffers a lapse.
And, SPF-without-CSV _will_ check MAIL FROM, with the same issues
as above.
If _this_ difference seems subtle, I must not have explained it
very well, because here we have the difference between accurate
reputation matched to clean semantics of CSV, versus reputation
sullied by the not-too-great reputation of a much larger entity,
with semantics so confused that I don't believe any reputation
service will be able to sort out the difference between "accept
responsibility for the actions of this MTA" and "this MTA is not
under our control, but may send our email anyway".
--
John Leslie <john(_at_)jlc(_dot_)net>