ietf-mxcomp
[Top] [All Lists]

Re: So here it is one year later...

2005-02-02 06:16:14

Douglas Otis wrote:
 
SPF may say, "Here is a comprehensive address list", when in
reality it can never be comprehensive.

Of course it is.  There are at most 512 IPs sending mail from
whoever(_at_)xyzzy to somebody(_at_)elsewhere(_dot_)  The other 254*256*256*256
IPs don't do this, unless they are forwarding mail from me, and
then it's something arranged by somebody(_at_)elsewhere(_dot_)  He's free
to do whatever he likes, but of course he shouldn't check one
of his relay IPs against "my" 512 IPs.

And there at most 512 IPs who could say HELO xyzzy.claranet.de.
In reality no MTA should do this, but for this minor detail SPF
isn't good enough, maybe CSV could catch the remaining 512 IPs.
BTW, can it ?

This is a problem created by the sender

"v=spf1 ip4:212.82.225.0/24 ip4:195.170.96.0/24 -all"
isn't "a problem created by the sender", it's simply the truth.

SPF does not prevent spoofing of the domain, as many share
common providers

If somebody authorized to use one of these 512 IPs spoofs "my"
vanity domain, then I'm sure that the abuse desk of my ISP can
solve this problem very quickly, otherwise they'd risk to lose
a happy customer.

And SPF offers solutions for this situation where necessary,
e.g. some existing policies use ? instead of + for shared IPs.

there is no consensus which identities are checked against
such records (when these records are even examined)

2821-From and -HELO are checked.  Anything else won't work as
expected.  Of course I can't force you to do "the right thing",
you could check something else somewhere else, but why bother
with DNS and SPF if you want some random rejects ?  Try BLARS,
its cheaper than SPF for this purpose.

CSV is intended to protect the network using the same name
basis.

So far I haven't seen any spoofed HELO xyzzy.claranet.de in
bogus "bounces to" me, so probably CSV would have done nothing
at all for my problem.

This domain assertion is not constrained to zone cuts.  After
lengthy consideration, it was determined this too would be
inappropriate.

Can it identify HELO xyzzy.claranet.de as rubbish ?  I've read
the discussions about SPF's "zone cut" in CLEAR, and the Jan 4
plus Jan 6 entries in <http://www.livejournal.com/users/fanf/>
- but that doesn't explain the details.  And I haven't found a
case where `nslookup -q=ns sub.dom.ain.example` fails to find
the "zone cut".

A well understood problem is not FUD

Claiming that SPF causes mails to be lost is definitely FUD,
Like the collection of monstrous lies in the PDF:
<https://antiphishing.kavi.com/events/Conference_Notes/sender_auth_myths_and_domainkeys.pdf>

BTW, I found that link on the page:
<http://podcast.resource.org/rf-rfc/index.html#item0003>

A script based language is inherently complex

Yes, the macro language has its drawbacks, and the TINW in "we"
had some problems to get it right for some obscure cases like a
slash in a FQDN used as HELO.   Actually that was in one of two
relevant articles in MARID (with thanks to Julia and Margaret)

OTOH Wayne now defined exactly 10 macro letters, 8 are used in
sender policies, anything else is an error.  That's not too
complex.  Don't try to convince me that the SPF "explanations"
are ridiculous, I wouldn't disagree (one of the minor issues I
hoped to get rid of in the former MARID WG, but here we are).

  [overall timeout]
From the Schlitt's draft:

ACK, error on my side, this "implementation detail" is still a
part of the draft, and maybe I'll discuss it with Wayne on the
SPF list, it's unnecessary.  Of course there must be a way to
report and log "local error conditions".

In the lentczner-drafts the optional overall timeout was a very
important part of "processing limits" and indirectly "security
considerations", now it's on the same level as say a "sigterm".

The draft requires these 101 to 201 lookup limits depending
upon the mechanisms.

If you have some local reasons to ignore a sender policy, then
just do it.  And if you want a documented reason to state that
a sender policy is erroneous follow the spec.  The latter is a
reason to reject the mail with a PermError, the sender policy
has to be fixed.

By checking per HELO, the rate CSV does a lookup is some
multiple less than SPF, and constrained to a single lookup
and not hundreds of lookups.  This aspect is critical.

For me it's critical that a forged "mail from me" is rejected,
and CSV won't do this trick.  If you think that the two lookups
to check any "mail from me" are too much just don't do it.

SPF worked for me as soon as some "important players" (defined
from the POV of "my" spammer) implemented it, it's not critical
if you don't use it.
                     Bye, Frank