Re: Thoroughly Confused Sysadmins: Raise your hands2004-07-01 23:57:15--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>
|
|