Paper on Email Authentication (Authorization really) (was - Re: Micorsoft's Sender ID Authentication......?)
On Tue, 7 Jun 2005, Fergie (Paul Ferguson) wrote: -- william(at)elan.net [EMAIL PROTECTED] wrote: Since it appears NANOG continues to be used for mail-related discussions and a some of what goes here is based on not understanding technologies and issues involved, I'll make a link to a paper that I'm working on available (when its ready) and it will hopefully be good information to understand what's up in email authentication front and what each technology can and can not do. That would be much appreciated. :-) My paper on Email Security Anti-Spoofing Protection with Path and Cryptographic Authentication Methods is now available at http://www.metasignatures.org/path_and_cryptographic_authentication.htm Printable PDF version of the paper (21 pages) is also available - http://www.metasignatures.org/Path_And_Cryptographic_Authentication.pdf First parts (part 1-4) are an overview of the various email anti-spoofing technology proposals that were proposed (in IETF or IRTF ASRG) in the last 2-3 years, what email identities they focus on, their interactions and differences in proposals because of that. It should be easy enough for NANOG readers to read and understand even if you're not mail expert. In part 5, I also go through why none of the proposals are really anti-spam and promotion of the methods as such is misleading. There are also chapters on Accreditation and Reputation (including section on spamhaus .MAIL) and authorization vs authenticity question that has been raised by some when criticizing path authentication technologies like SPF - I explain that is really problem for both path and cryptographic proposals and its tied to question on if mail servers are enforcing submission rights at mail origin. Part 6 may or may not be of interest here and is result of my research presenting proposal on how to use cryptographic signatures to correct for SPF failures after forwarding and allow for safe rejection based on SPF records. Note: Some people reported that PDF version is not readable in all circumstances, in that case send me note privately when that happens with specs for your system, PDF reader version OS and I'll try to get an idea of what needs to be corrected. Note that PDF is really just printout of html version so if it does not work, read the original. In general if you know good way to create PDF out of HTML for documents such as mine (perfect if it could insert page numbers into table of contents), let me know privately. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: Paper on Email Authentication (Authorization really) (was - Re: Micorsoft's Sender ID Authentication......?)
On 06/13/05, william(at)elan.net [EMAIL PROTECTED] wrote: In part 5, I also go through why none of the proposals are really anti-spam and promotion of the methods as such is misleading. No matter how the authors may promote their methods, most people don't perceive that there's any great separation between anti-spam and anti-forgery techniques. As far as they're concerned, all e-mail threats are basically the same. E-mail authentication's promise is that it will improve the overall state of the global e-mail infrastructure. Chopping that into smaller bits may be a fun intellectual exercise, but it doesn't help explain what's going on to anyone outside of our fairly small technology-focused circles. -- J.D. Falk blong! you are a pickle! [EMAIL PROTECTED]
Re: Paper on Email Authentication (Authorization really) (was - Re: Micorsoft's Sender ID Authentication......?)
On Mon, 13 Jun 2005, J.D. Falk wrote: On 06/13/05, william(at)elan.net [EMAIL PROTECTED] wrote: In part 5, I also go through why none of the proposals are really anti-spam and promotion of the methods as such is misleading. No matter how the authors may promote their methods, most people don't perceive that there's any great separation between anti-spam and anti-forgery techniques. As far as they're concerned, all e-mail threats are basically the same. This attitude is exactly playing in the hands of DMA which wants to make it seem like spam is only those UBE with forged origin data. E-mail authentication's promise is that it will improve the overall state of the global e-mail infrastructure. Chopping that into smaller bits may be a fun intellectual exercise, but it doesn't help explain what's going on to anyone outside of our fairly small technology-focused circles. Chopping off complex issue into pieces which can be worked and looked at separate is exactly the approach that has very often been used in research, engineering, politics/diplomacy and many other areas. This is no different and should be easy enough to explain to non-technical folks. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: Paper on Email Authentication (Authorization really) (was - Re: Micorsoft's Sender ID Authentication......?)
On 06/13/05, william(at)elan.net [EMAIL PROTECTED] wrote: No matter how the authors may promote their methods, most people don't perceive that there's any great separation between anti-spam and anti-forgery techniques. As far as they're concerned, all e-mail threats are basically the same. This attitude is exactly playing in the hands of DMA which wants to make it seem like spam is only those UBE with forged origin data. I'm not describing my own attitude above, so you can stop being insulting. What I've described is a common perception held by end-user types. I'm not saying their perceptions are correct, I'm just saying they exist and shouldn't be ignored. This is moving further off-topic, so I'll leave it at that. -- J.D. Falk blong! you are a pickle! [EMAIL PROTECTED]
Re: Micorsoft's Sender ID Authentication......?
On Thu, 09 Jun 2005 17:40:55 PDT, Matt Ghali said: So you see, the reputation has nothing to do with your mom, and everything to do with the controlling entity, her ISP. Which makes the whole address-based sender reputation scheme almost workable, if you ignore the scaling issues. That's suspiciously close to Ralph Nader or Ross Perot could have been elected President, if you ignore the scaling issues. :) Other than that, what Matt said is correct - the problem is that legitimate mail can come from literally millions of places whose reputation we have no clue on pgpSE8hY8vYEX.pgp Description: PGP signature
Re: Micorsoft's Sender ID Authentication......?
On Fri, 10 Jun 2005 [EMAIL PROTECTED] wrote: On Thu, 09 Jun 2005 17:40:55 PDT, Matt Ghali said: So you see, the reputation has nothing to do with your mom, and everything to do with the controlling entity, her ISP. Which makes the whole address-based sender reputation scheme almost workable, if you ignore the scaling issues. That's suspiciously close to Ralph Nader or Ross Perot could have been elected President, if you ignore the scaling issues. :) Yes. There's a reason I did not include a ringing endorsement of sender reputation schemes as the FUSSP; it has colossal inherent scaling issues; however I believe the 90/10 rule will make it at least somewhat effective. Other than that, what Matt said is correct - the problem is that legitimate mail can come from literally millions of places whose reputation we have no clue on Yes. Sender reputation on an per-ip level is a lot of state. However; I believe that sender reputation on a swip level may be attainable, and provide positive value. matto PS: Even though it's painfully obvious, I speak only for myself and no entity currently/previously employing me- Especially those kooks at UCB. [EMAIL PROTECTED]darwin The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke
Re: Micorsoft's Sender ID Authentication......?
We've already tackled reputation systems, they were called web site certificates. You have to submit to a few fairly stringent checks on who you are, typically provide a DB id which isn't very expensive or difficult but not all that easily defrauded w/in some reasonable parameters (it ain't bank security but it's good enough to be pretty sure you're giving your credit card info to who you think you are, damn, you hand your card to strange bartenders right?) But there was real money in web site certificates, indirectly, in the form of e-commerce. And that area had the good luck of evolving rapidly in a huge market boom. There's basically no such money in e-mail, not versus not adding a reputation system. No further explanation should be necessary. However, I'll add my voice that I believe reputation systems as an approach to spam-prevention are neither useful nor sufficient w/o repeating what others have said. The problem is really pretty simple; we're trying to solve a big problem w/o creating any concomitant economics to support a solution. It's a nice fantasy, and that's what it remains after a decade. -- -Barry Shein Software Tool Die| [EMAIL PROTECTED] | http://www.TheWorld.com Purveyors to the Trade | Voice: 617-739-0202| Login: 617-739-WRLD The World | Public Access Internet | Since 1989 *oo*
Re: Micorsoft's Sender ID Authentication......?
On Thu, 9 Jun 2005, Barry Shein wrote: We've already tackled reputation systems, they were called web site certificates. You have to submit to a few fairly stringent checks on who you are, typically provide a DB id which isn't very expensive or difficult but not all that easily defrauded w/in some reasonable parameters (it ain't bank security but it's good enough to be pretty sure you're giving your credit card info to who you think you are, damn, you hand your card to strange bartenders right?) This is accreditation, not reputation. When you contact somebody and ask to verify your credentials this is accreditation (and it says nothing about how you're going to act, just verifies your identity and provides additional info about you). When somebody else looks at your activity and makes subjective judgement (mosly based on multiple reports from users) and then lets this judgement about your activities be available to other users then its reputation. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: Micorsoft's Sender ID Authentication......?
On Thu, 2005-06-09 at 13:54 -0700, william(at)elan.net wrote: On Thu, 9 Jun 2005, Barry Shein wrote: When somebody else looks at your activity and makes subjective judgment (mostly based on multiple reports from users) and then lets this judgment about your activities be available to other users then its reputation. This judgment of activities should be premised on knowing who is actually accountable for the activity. With either SPF or Sender-ID, this mechanism is just offering server authorization. When the mailbox-domain appears to be supported by server authorization, without also assuming all preceding MTAs ensure exclusive use the specific mailbox-domain, it could be incorrect to conclude the mailbox-domain originated the message. Domain owners are not clearly warned by the respective drafts of this add MTA requirement when reputation is involved. Both drafts suggest the mailbox-domain may subsequently accrue a reputation, when supported by server authorization. The SPF camp elected to drop scoped records, which would have allowed the sender to declare which mailbox-domain has been assured exclusivity. Sender-ID will also use this record to discover authorization for either the Purported Responsible Address (PRA) or the bounce-address. The opt-out solution offered by Sender-ID will create problems at some destinations, which means both the PRA and bounce-address require exclusivity at the MTA. Snap goes the Sender-ID reputation license trap. Both schemes demand greater diligence by MTA administrators when mailbox-domain authorization/reputation schemes are implemented, while simultaneously leaving negligent MTA administrators unscathed. While this may seem like great news for the MTA administrator, and bad news for domain owners, it risks litigation. The mailbox-domain owner is otherwise without recourse, when finding their domain blocked. -Doug
Re: Micorsoft's Sender ID Authentication......?
Thus spake Barry Shein [EMAIL PROTECTED] However, I'll add my voice that I believe reputation systems as an approach to spam-prevention are neither useful nor sufficient w/o repeating what others have said. Agreed. If my grandmother has a reputation for sending legitimate email, and she inadvertently installs some spam zombie software, it is certainly feasible (and probably trivial) for the spammer to steal all her credentials and thus her reputation. Spam will get out for a while, but once her reputation significantly degrades, it will be stopped -- as will any future legitimate email from her. This solution strikes me as worse than the problem it tries to address. S Stephen Sprunk Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do. K5SSS --Isaac Asimov
Re: Micorsoft's Sender ID Authentication......?
On Thu, 9 Jun 2005, Stephen Sprunk wrote: If my grandmother has a reputation for sending legitimate email, and she inadvertently installs some spam zombie software, it is certainly feasible (and probably trivial) for the spammer to steal all her credentials and thus her reputation. Spam will get out for a while, but once her reputation significantly degrades, it will be stopped -- as will any future legitimate email from her. No. You are (I suspect) deliberately ignoring the Big Picture. Your grandmother, if she is like most grandmothers, does not have a box coloed with a static IP from which she runs her own MTA. She gets a dynamic address assignment from her ISP. When her computer becomes infected with malware that causes it to emit abusive traffic, the reputation for that IP (or its containing netblock) is affected. The longer her ISP allows the abusive traffic, the lower the reputation becomes for that address (or its containing netblock). So you see, the reputation has nothing to do with your mom, and everything to do with the controlling entity, her ISP. Which makes the whole address-based sender reputation scheme almost workable, if you ignore the scaling issues. This solution strikes me as worse than the problem it tries to address. I'd never call it a solution, but it is certainly a useful tool to use along with others in order to more successfully manage the problem. matto [EMAIL PROTECTED]darwin The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke
Re: Micorsoft's Sender ID Authentication......?
On 06/09/05, Stephen Sprunk [EMAIL PROTECTED] wrote: If my grandmother has a reputation for sending legitimate email, and she inadvertently installs some spam zombie software, it is certainly feasible (and probably trivial) for the spammer to steal all her credentials and thus her reputation. Spam will get out for a while, but once her reputation significantly degrades, it will be stopped -- as will any future legitimate email from her. Anyone who has been paying much attention to the spam problem in the past few years already knows that assigning a bad reputation forever is a bad idea -- especially to dialups. What's more likely to happen in your Grandmother's case is that her IP/e-mail address will have a bad reputation for a while, and then she'll call you and you'll come over and un-zombify her cmoputer and say okay, Grandma, remember what we said about clicking on links on porn sites? and she'll say oh, but it was blinking such pretty colors! and a few hours/days later the reputation will have returned to the default state. -- J.D. Falk blong! you are a pickle! [EMAIL PROTECTED]
Re: Micorsoft's Sender ID Authentication......?
On 08/06/05, J.D. Falk [EMAIL PROTECTED] wrote: We can't have reliable reputation until we know who the mail is coming from -- so reliable identity is a necessary first step. What the doctor ordered seems to be something like an API that'd let you plug dkim + csv into $mta Anyone? --srs -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: Micorsoft's Sender ID Authentication......?
Reputation is a missing element in all sender authentications schemes and will (likely) be solved separately. No approach is perfect, but building closer to a solution is preferred over sitting on our hands and debating, which (historically) seems to be the IETF's approach. - Dan On 6/8/05 12:37 AM, John Levine [EMAIL PROTECTED] wrote: Yes, there was lots of teeth gnashing and screams of agony allegedly because MS refused to license the technology on the terms that folks wanted. MS was more than willing to let folks have it at no cost, they just weren't willing to give the naysayer everything they wanted, so everyone went home. (that is, of course, a biased assessment, but not an unfair one) There were two problems with the patent license that the MS lawyers offered. The first was that it reserved to them the right to stop granting new licenses, thereby pulling the rug out from under anyone who'd used licensed technology in a product, particularly an open source product. The said they didn't plan to do that, but MS' lawyers adamantly refused to change that, so a lot of us concluded that if they thought the pull out the rug language was important, so did we. The second problem was that the license was for two unpublished patent applications that they described in general terms. When the applications were published (on a schedule known from the day they were filed), they turned out to cover vastly more than MS had ever said. That left a bad taste in a lot of people's mouths. See my blog entry at http://www.taugh.com/weblog/patapp.html In the mean time, nothing stops MS (and everyone else) from building Sender-ID into their MTAs. SPF is a standard and Sender-ID utilized SPF records to perform inbound phishing control based on PRA. (Danger: operational content ahead.) Sender-ID and SPF have serious practical problems. The first is that they don't match the way that a lot of mail is really sent. If all of your mail comes from a single set of servers, like if you're a big company or an ESP, then SPF or Sender-ID work reasonably well to tell people which mail is yours. On the other hand, if you're a university who lets its graduates keep using their whatever.edu addresses after they graduate and forwards their mail to them, they doen't work at all. (Other than a legalistic version of work in which you publish a useless SPF record saying that mail could come from anywhere.) This would not be a problem except that SPF has been greatly oversold, the SPF community has not been particularly diligent in disabusing people of their misconceptions, and I can promise that the moment there is a Sender-ID checkbox in Exchange, clueless MCSEs will set it to reject anything that fails Sender-ID, it'll reject buckets of normal valid mail, and when people complain, they will insist that the mail must have been sent wrong because Sender-ID said it was spam. Even for fixed senders, Sender-ID is useless against phishing, because it can only tell you that a message purporting to be from phoop.com came from a source that is OK for phoop.com, but it cannot tell you whether phoop.com is someone you want to get mail from. This is a real problem. For example, I got mail the other day from customercenter.net purporting to tell me about the status of my MBNA credit card, with a link to mbnanetaccess.com. Was that a phish? Or consider mbna-account.com and mbna-accounts.com. One is MBNA, one is not. Does your MUA know which one is which? Spammers and phishers can publish SPF records just like anyone else, and Ciphertrust has said that of the mail they see that passes SPF, there's more spam than legit mail. I am all in favor of sender authentication, if it's real sender authentication. But Sender-ID isn't. Domainkeys will be better since it matches mail sending patterns better, but it has the same problem that a sender that's been authenticated has nothing to do with whether its mail is desired. Shameless plug: over in the anti-spam research group at asrg.sp.am I sure would like it if people were working on reputation systems to plug the gaping hole left by all these authentication schemes. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor More Wiener schnitzel, please, said Tom, revealingly. -- Daniel Golding Network and Telecommunications Strategies Burton Group
Re: Micorsoft's Sender ID Authentication......?
On Wed, 8 Jun 2005, Daniel Golding wrote: Reputation is a missing element in all sender authentications schemes and will (likely) be solved separately. No approach is perfect, but building closer to a solution is preferred over sitting on our hands and debating, which (historically) seems to be the IETF's approach. You miss the point. Reputation is already widely being used today - every blocklist is a reputation system and we have lots of those for mail server reputation and for network reputation and for domain names there is SURBL All those are of course bad reputation lists and John wants to see good reputation lists, but it can only happen once authorization is used, but initial technologies are there. For when something more complex is needed there is in fact siq being developed at ASRG http://www.ietf.org/internet-drafts/draft-irtf-asrg-iar-howe-siq-01.txt so what is really needed are people willing to come to asrg and work with authors on RD (with emphasis on d part) and if it does not work well than ASRG will look at something else. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: Micorsoft's Sender ID Authentication......?
On Wed, 8 Jun 2005, william(at)elan.net wrote: You miss the point. Reputation is already widely being used today - every blocklist is a reputation system Strike that point. Not every blocklist is reputation system, though the most widely used ones like SBL, SORBS, SPAMCOP are all like that. But there others simply provide certain info about corresponding ip or domain which is derived from domain info itself (like what country its from, if its bogon/not-allocated space for ip, etc), those would be closer accreditation data. I seriously doubt this distinction is that important for those at nanog. But anyway, I had to correct myself, since my statement was not accurate. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: Micorsoft's Sender ID Authentication......?
In message [EMAIL PROTECTED], Daniel Golding writes: Reputation is a missing element in all sender authentications schemes and will (likely) be solved separately. No approach is perfect, but building closer to a solution is preferred over sitting on our hands and debating, which (historically) seems to be the IETF's approach. I'm not a fan of authentication as an anti-spam technique (see my Inside RISKS column for details). That said, if you're going to use the concept there are good and bad ways to do it. SPF (and hence Microsoft's scheme) are really lousy ways to do it, for the reasons John gave. Beyond that, a lot of people at the IETF had the impression, rightly or wrongly, that Microsoft was trying to use its patents as another weapon to use against open source software. The IETF isn't nearly as nimble as it should be, but rushing to adopt a bad solution is not a good idea. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: Micorsoft's Sender ID Authentication......?
On Wed, 8 Jun 2005, Suresh Ramasubramanian wrote: On 08/06/05, J.D. Falk [EMAIL PROTECTED] wrote: We can't have reliable reputation until we know who the mail is coming from -- so reliable identity is a necessary first step. What the doctor ordered seems to be something like an API that'd let you plug dkim + csv into $mta I don't think the lack of standard APIs is a problem: it seems to me that the various MTA authors have been reasonably keen to support the various nascent specifications, especially if they have a reasonably good reference implementation library. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD.
Re: Micorsoft's Sender ID Authentication......?
Wasn't there a lot of turmoil within the IETF last year on sender authentication because Microsoft was trying to push it's own sender ID authetication mechasnisms as a draft standard? In part the problem was 'legal' (versus technical)...the folks involved in the working list from MS...technical people, offered ongoing reassurance that the as-yet-unpublished patent apps were benign, that it would always be available free, etc. etc... but once the patent apps were published, they were far over-reaching, included SPF aspects, etc.. (I have _zero_ doubt that the legal/corporate folks upstairs at MS were responsible for that, and that the good folks from MS on the working list were as surprised as were the rest of us). Anne Anne P. Mitchell, Esq. President/CEO Institute for Spam and Internet Public Policy IADB Email Sender Accreditation Database: http://www.isipp.com/iadb.php Professor of Law, Lincoln Law School of SJ Advisor, Kinar Secure Email Advisor, Relemail Email Privacy Certification Advisor, Virus Bulletin Asilomar Microcomputer Workshop Planning Committee
Re: Micorsoft's Sender ID Authentication......?
On 08/06/05, Tony Finch [EMAIL PROTECTED] wrote: I don't think the lack of standard APIs is a problem: it seems to me that the various MTA authors have been reasonably keen to support the various nascent specifications, especially if they have a reasonably good reference implementation library. Easier for those of us who run multiple MTAs, especially large farms of them But yes, you do have a point that it is not exactly a problem. Is there something in the works for postfix and qmail yet? regards srs -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: Micorsoft's Sender ID Authentication......?
In part the problem was 'legal' (versus technical)...the folks involved in the working list from MS...technical people, offered ongoing reassurance that the as-yet-unpublished patent apps were benign, that Folks, For all the reasons already cited in this thread, it's clear that legal concerns were a factor. However the reality is that the IETF working group was not converging on consensus and showed no ability to repair this fatal barrier. The legal issues were part of this, but it is far from obvious that fixing the legal issues would have gotten a better outcome. Besides the criticisms of the basic path registration (somewhat akin to registering source routes) schemes used by SPF and Sender-ID, those two different specs have different constituencies and were not overly successful as merging. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net
Re: Micorsoft's Sender ID Authentication......?
DomainKeys are the work of the devil Well it is one of the most untidy headers DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:mime-version:content-type:x-mailer:x-mimeole:thread-index:in-reply-to:message-id; b=A7ZrgGGQFcA2+oJOMAHBFh6JTlNevGsVUn6qe8hx+7flOVzwxxJ6qB+V5EE3ylz0ZmILAfhBu6b3GKwDJdw0NfF4AqsshdQ0xEyvMpFHUytXunQ50ui37DQjqvk3KK+5SxYt4kbVhyk8UWn16Ory0MqKJJ5q12iITUtxIGIWLDs= brandon
Re: Micorsoft's Sender ID Authentication......?
On Tue, 7 Jun 2005, Fergie (Paul Ferguson) wrote: Wasn't there a lot of turmoil within the IETF last year on sender authentication because Microsoft was trying to push it's own sender ID authetication mechasnisms as a draft standard? That time it did not work. But they are still trying to push it as experimental RFC and in the mean time continue to advocate it trying to make it open standard despite technical and other objections. Or maybe I'm confused... SenderID is bad technology. Technically: 1. Its proposal contains recommendation that are directly opposite to existing RFC2822 standard (which specifically mentions in section section 3.6 that using resent fields is a different operation from forwarding) 2. It tries to change the meaning of message sender from real message source to intermediate agents, this would have problems with other email authentication technologies 3. Its using spf1 records, but they are used for information on sources for different identity (SMTP2821 MAIL FROM) and would not always have the same data as what would apply for RFC2822 Sender or its derivatives. There is no consent being asked from those entered SPF1 records if they meant them used for SID and this basically means people who wanted to participate in SPF inadvertently are put in danger (it can also be viewed as attempt to steal somebody else's record). For more on technical issues see my recent message to IESG regarding SID when they were evaluating it: http://www.gossamer-threads.com/lists/spf/discuss/19859 Politically it has problems too: 1. Its patent license is not open-source compatible and so can not be used in any GNU or BSD licensed program 2. The senderid word itself is trademarked and its use also basically being stolen by Microsoft --- Since it appears NANOG continues to be used for mail-related discussions and a some of what goes here is based on not understanding technologies and issues involved, I'll make a link to a paper that I'm working on available (when its ready) and it will hopefully be good information to understand what's up in email authentication front and what each technology can and can not do. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: Micorsoft's Sender ID Authentication......?
That would be much appreciated. :-) - ferg -- william(at)elan.net [EMAIL PROTECTED] wrote: Since it appears NANOG continues to be used for mail-related discussions and a some of what goes here is based on not understanding technologies and issues involved, I'll make a link to a paper that I'm working on available (when its ready) and it will hopefully be good information to understand what's up in email authentication front and what each technology can and can not do. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: Micorsoft's Sender ID Authentication......?
Yes, there was lots of teeth gnashing and screams of agony allegedly because MS refused to license the technology on the terms that folks wanted. MS was more than willing to let folks have it at no cost, they just weren't willing to give the naysayer everything they wanted, so everyone went home. (that is, of course, a biased assessment, but not an unfair one) There were two problems with the patent license that the MS lawyers offered. The first was that it reserved to them the right to stop granting new licenses, thereby pulling the rug out from under anyone who'd used licensed technology in a product, particularly an open source product. The said they didn't plan to do that, but MS' lawyers adamantly refused to change that, so a lot of us concluded that if they thought the pull out the rug language was important, so did we. The second problem was that the license was for two unpublished patent applications that they described in general terms. When the applications were published (on a schedule known from the day they were filed), they turned out to cover vastly more than MS had ever said. That left a bad taste in a lot of people's mouths. See my blog entry at http://www.taugh.com/weblog/patapp.html In the mean time, nothing stops MS (and everyone else) from building Sender-ID into their MTAs. SPF is a standard and Sender-ID utilized SPF records to perform inbound phishing control based on PRA. (Danger: operational content ahead.) Sender-ID and SPF have serious practical problems. The first is that they don't match the way that a lot of mail is really sent. If all of your mail comes from a single set of servers, like if you're a big company or an ESP, then SPF or Sender-ID work reasonably well to tell people which mail is yours. On the other hand, if you're a university who lets its graduates keep using their whatever.edu addresses after they graduate and forwards their mail to them, they doen't work at all. (Other than a legalistic version of work in which you publish a useless SPF record saying that mail could come from anywhere.) This would not be a problem except that SPF has been greatly oversold, the SPF community has not been particularly diligent in disabusing people of their misconceptions, and I can promise that the moment there is a Sender-ID checkbox in Exchange, clueless MCSEs will set it to reject anything that fails Sender-ID, it'll reject buckets of normal valid mail, and when people complain, they will insist that the mail must have been sent wrong because Sender-ID said it was spam. Even for fixed senders, Sender-ID is useless against phishing, because it can only tell you that a message purporting to be from phoop.com came from a source that is OK for phoop.com, but it cannot tell you whether phoop.com is someone you want to get mail from. This is a real problem. For example, I got mail the other day from customercenter.net purporting to tell me about the status of my MBNA credit card, with a link to mbnanetaccess.com. Was that a phish? Or consider mbna-account.com and mbna-accounts.com. One is MBNA, one is not. Does your MUA know which one is which? Spammers and phishers can publish SPF records just like anyone else, and Ciphertrust has said that of the mail they see that passes SPF, there's more spam than legit mail. I am all in favor of sender authentication, if it's real sender authentication. But Sender-ID isn't. Domainkeys will be better since it matches mail sending patterns better, but it has the same problem that a sender that's been authenticated has nothing to do with whether its mail is desired. Shameless plug: over in the anti-spam research group at asrg.sp.am I sure would like it if people were working on reputation systems to plug the gaping hole left by all these authentication schemes. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor More Wiener schnitzel, please, said Tom, revealingly.
Re: Micorsoft's Sender ID Authentication......?
On 06/07/05, John Levine [EMAIL PROTECTED] wrote: Shameless plug: over in the anti-spam research group at asrg.sp.am I sure would like it if people were working on reputation systems to plug the gaping hole left by all these authentication schemes. Not sure if it's a gaping hole, so much as an unfortunate fact that sender reputation is already proving to be even harder to standardize than how to confirm the identity of a sender. We can't have reliable reputation until we know who the mail is coming from -- so reliable identity is a necessary first step. Operationally, this means that ISP's can't yet abandon whatever reputation systems they already have in place (most of which are based on the source IP address, or on in-message criteria.) But they can (and should) start testing whichever verification scheme best fits their mail flow patterns, so that all of our internal reputation engines can start evolving. -- J.D. Falk blong! you are a pickle! [EMAIL PROTECTED]
