Re: Thoroughly Confused Sysadmins: Raise your hands

--Gordon Fecyk <gordonf(_at_)pan-am(_dot_)ca> wrote:

> OK, admittedly I've given up on following every single thread in this list
> because the arguments have gone way over my head.  And before you even
> suggest that I shouldn't be here because of that, understand this:
>
> I HAVE TO IMPLEMENT THIS GARBAGE.

I am right there with you... I am a sysadmin too.


> Which brings me to the point of this rant.  Exactly what are you trying to
> accomplish here?  All of it.
>
> Because it's gone far beyond simply verifying a sender's address or a
> forwarder's address and into theological - not even technical but
> religious! - arguments about DNS overloading, SMTP overloading, breaking
> existing semantics of each, building new semantics that don't even fit in
> the existing rules (ie: DNS packet sizes), a servere unwillingness to
> abandon consistently abused things.  And that doesn't include all of the
> political infighting, harsh business accumen, introductions of
> proprietary / patented crap in doomed efforts to sell said crap, obscene
> stubbornness and ignorance of hard data, and I don't know what else
> anymore.

Here's my 2 cents.  I am a supporter of SPF and I was put off by CallerID, 
and at first I thought any compromise with MS would be impossible.  But, 
around the time of the MARID Interim meeting, something strange began to 
happen.  SPF supporters and MS supporters decided to set aside some strong 
differences and get to work on a merged proposal.  This was based on a lot 
of work MARID had done in going over identities, and way back when we were 
talking about identities to check, I think we reached a loose consensus 
that we wanted to check 2821 and 2822 identities, each for their very own 
good reasons.
Despite some strong religious differences, a merged proposal came out of 
it.  I was only there for the tail end of it, but it was heady stuff.  The 
idea that you could use the same mechanism to check MAIL FROM +SRS and PRA 
using the same tool was a good one.  The idea that the religious 
differences like 2821/2822 and SPF/XML didn't matter as much as the 
underlying features was a better one.
CSV supporters are faced with similar issues now.  Checking HELO is 
something a few people wanted (and was a good fallback in case of MAIL 
FROM: <>) so SPF had that built in from the start.  If you were to design a 
tool that only does HELO checking, and nothing else, would you have a much 
simpler tool?  Of course.  Is SPF sufficient to check HELO by itself, if 
overpowered for that?  Probably.  But to even discuss such a merger is 
quite beyond CSV's most vocal supporters for what I think are "religious" 
reasons. [*]
I guess I would be more stressed about this if CSV had more than a handful 
of supporters.  I think most folks in the WG believe as I do, that either 
SPF or SenderID gets us one step closer to stopping forgery, and CSV 
represents a step sideways -- neither necessary nor sufficient.
Unified SPF, I think, is really an attempt to say, if you want to check 
these other identities, here's a way to do it.  Now all that is missing is 
the value of checking in each context, the semantics of what it means, and 
some recommendations on why you would want to check ID-du-jour and what you 
might want to do with the results.  CSV has done a lot of this "semantic" 
work in terms of HELO, so some of that might be compatible, if it could be 
pried away from its "One True Implementation" dogma of SRV records.  HELO 
checking has some value -- that is why SPF has had it there for quite some 
time (mostly for bounces which have blank MAIL FROM)  But... I have decided 
to stop trying to coax CSV supporters into an agreement, since I don't care 
enough about HELO checking anyway.

[*] In this context a "technical" argument is one that says "What you want 
to do is impossible or infeasible because X".  A "religious" argument is 
one taken on faith such as "Nobody will want to use X records" or "X is the 
correct way to do this".  Also, taking a scale which defines a wide range 
of correct choices and leaning hard to one side is a form of religious 
argument.

> Since Meng, Harry, Bob and others in their camp were charged with drafting
> this stuff and you've now had a chance to be thoroughly nitpicked, please
> you three - explain what you're doing so a tired and confused network
> administrator can understand it.  And tell me what I have to do to
> implement it, even if I have to write it from scratch in C or Perl or
> (Gaia forbid) VB or Python or whatever.  I'm not looking for source code,
> I'm not looking for examples and it doesn't have to be a multi-page essay
> written so a five-year-old can read it.  Just answer the fundamental
> questions tersely: Who, What, Where, When, Why and if you wish, How.

I wasn't technically a party to the merged Sender ID proposal being 
decided, but I was one of the first to hear about the main points of it.  I 
think the combined proposal serves most of the same purposes CallerID and 
SPF were trying to solve separately and has more value than either of them 
taken alone.
So, here is my quick attempt to answer based on my understanding of Sender 
ID.
WHO: domain owners who wish to protect misuse of their domains, and 
receivers who want to honor their intentions and bounce unauthorized mail.
WHAT: domain owners: publish your IPs in DNS using simple mechanisms like 
"a mx ptr" that refer to other stuff in DNS that receivers usually look up 
anyway.  receivers: bounce mail on Fail, treat with normal policy 
(filtering or IP DNSBL) on Pass or Unknown, use Pass to whitelist by name.
WHERE: DNS TXT records and your MTA.  More specifically...  PRA: something 
that is easy for forwarders to add (unlike SRS) and some MTAs like Postfix 
have it in there already.
WHEN: NOW: publish SPF records.  SOON: start checking inbound mail, and 
whitelist known forwarders (e.g. using trusted-forwarder.org whitelist). 
Forwarders get busy on adding some headers.  Careful admins will want to 
log results only and switch to -all publishing and FAIL-Bounce receiving 
after showing FP rate is low enough.
WHEN: LATER: Other cool stuff becomes possible such as showing the PRA in 
MUA with a verification icon next to it.  Mail sent directly with no 
forwarding immediately gets a "verified" icon.  In the future, if PRA is 
the receiver's own forwarding address, some MUAs may choose to trust 
Received: lines added by PRA agent and also show the "previous PRA" as well 
(similar to the SPF checks on Received: lines that SpamAssassin does).
WHY: eventually force spammers to get their own names at increasing cost. 
In the shorter term, spammers will abuse names that are not SPF-protected 
disproportionately, creating a good incentive to publish with -all.  There 
will be additional pressure on registrars to check mailing address (or at 
least credit card billing address) on all domains, or for inclusion into a 
voluntary whitelist as an extra paid service.  Third parties may also 
provide this mailing address verification service for a small fee, with the 
caveat that domains terminated for spamming will cause other domains at the 
same street address to be delisted as well.

OK that's enough for now.  Above all, Don't Panic.  We will get through 
this!
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>