gmane.ietf.mxcomp

Mail Server Registries and Foreign Sender Authentication: A Proposal

Randy Smith — 2007-03-24T02:51:55

Greetings, I was recently discussing various issues surrounding email with a coworker and had a couple of ideas for authentication systems that I would like to get some feedback on. You can read my ideas at http://perlstalker.blogspot.com/2007/03/mail-server-registries-and-foreign.html. As I said, I'm looking for feedback. Are these ideas worth pursuing or am I barking up the wrong tree? Thank you for your time.

Doug attack scenarios without SPF

William Leibzon — 2006-11-10T19:34:20

Hi, While Doug has particular issue with SPF, the problem he points to has little to do with SPF. In fact the attack is general dns attack that will work with several other records (MX, SRV, NS, most likely PTR and NAPTR and possibly CNAME [John Levine suggested it, but I don't immediately see using it by itself]). The issue that certain applications (including DNS resolver itself) by means of special DNS records can be directed to do several additional lookups. The idea of the attack is to direct those lookups to somebody else who would have to answer that it does not know about this name. Those answers if original name is large can themselves be quite large so you get amplification even though the answer i NXDOMAIN. So specially for Doug I'm going to give example of using NS and EHLO for this attack [note that my regular mail server and system with actual data is currently down, so I'm trying to give an example from head; I tested this yesterday], at the end I'll also explain why CSV is even better case for launching this attack. Lets assume that an attacker controls some domain big.bad.domain.example.net (for good amplification the name needs to be pretty long; for better view in email I'm not doing it). He sends email with SMTP session starting as EHLO big.bad.example.net and he previously set up the following in DNS: $ORIGIN bad.example.net big IN NS victim-dns1.example.com big IN NS victim-dns2.example.com big IN NS victim-dns3.example.com big IN NS victim-dns4.example.com big IN NS victim-dns5.example.com big IN NS victim-dns6.example.com big IN NS victim-dns7.example.com big IN NS victim-dns8.example.com If victim does not have enough dns servers, it can actually be done so as to direct attack againt the same server - its more complex and I don't want to go into it right now. Now lets assume that as per Doug's scenario the email is sent using botnet to many mail servers and we'll assume that those email servers are going to try to resolve EHLO name (some would some would not - both CSV and SPF would require it but many others do it anyway too). Now what happens is that each mail server that received the email would try to resolve big.bad.domain.example.net and as part of that would come to bad.domain.example.net and would be by means of NS directed to victim DNS. Victim servers would each answer that they are non-authoritive but would have to include large domain (i.e. imagine big.bad.example.com being close to maximum DNS label size) and that is where amplification comes from, i.e. the attacker only responded with one packet which include big.bad.example.com once in that packet and smaller size victim-dns (which since NS supports label compression can be even smaller) where as the response include that entire large name and comes from each and every NS server listed. The above attack can be architect ed to be more then 10:1 with certain additional tricks. Now I promised to explain why CSV makes it easy and is worse then SPF. That is due to the suggestion of having to walk the dns tree which as far as I remember it CSV specification has. Lets imagine that EHLO name is actually bad1.bad2.bad3.bad4.example.com. What happens is that CSV specifies to do lookups first to _client._smtp.bad1.bad2.bad3.bad4.example.com. Using above system you cause multiple lookups due to lame delegation at bad1.bad2.bad3.bad4.example.com that cause victims to respond they don't know how to find _client._smtp.bad1.bad2.bad3.bad4.example.com. Next per CSV (as far as I understood it), the application would have to try _client._smtp.bad2.bad3.bad4.example.com and similarly attacker can setup lame delegation but this time at bad2.bad3.bad4.example.com zone. And so this way you can easily cause many lookups for the same email session from the same system - that is why it is worse then with SPF. But in reality if you look into it deeper, the actual amplification factor would be the same as in all those cases you do one lookup for bad?.example.com and cause to do 10x responses. It is exactly the same with SPF but in that case Doug has used mx operator - he causes requests for MX hosted at attacker side and several requests from victim for addresses pointed out but MX. This all comes down to something like 10 amplification factor and not like 100 or more like Doug says. Again this is general issue that can be replicated using different DNS records - its cause is that several DNS record types cause application (or dns resolver) to do additional lookups to list of names specified in that record [and SPF is not something new to this field, nor is it some type of script like Doug says]. Another example of the same issue is when you send email such that it would bounce (you can do it although now days email systems are smarter) and you setup bad MX (like Doug did) which would cause lookups to victim. It would be the same type of attack and amplification. I can provide several more examples (email offers great choices since anti-spam systems do a lot of lookups when trying to decide if its good or bad email and if you use lots of domains for various victims like in URL then you often cause some type of lookup to find if that name exists) as well as examples in non-SMTP field (SNMP for example). I hope this helped you all to understand it. Note that I'll probably not be able to respond for a while (not only due to mail server problem which should get fixed later today hopefully but largely because I'm still going to in San Diego and expect not to spend my weekend connected to Internet and answering emails). William

Trouble with Sender Authentication

K.J. Petrie — 2006-11-02T16:12:13

I hate to spoil a good party, but it seems to me there are several minor flaws and one major flaw with all the proposed methods of reducing spam through authenticating senders, which will either prevent their adoption or render them useless once widely adopted. SPF, for instance, breaks forwarding. This will stop it catching on widely, because domain owners are likely to use forwarding for their incoming mail. If their ISP adopts SPF they could lose all incoming mail from domains with an SPF record. To prevent this, the forwarding company, over which the domain owner may have no control, must take action. So we have a proposed system which requires unrelated entities to take co-ordinated action if it is not to disrupt mail delivery to the very people responsible for enabling it. This could be fixed by adding a Recipient Protocol Framework (my name - apologies if something called this already exists) to the standard, specifying servers which were to PASS all mail addressed To: (or Cc: Envelope-To: etc) the domain without checking the sender's domain. The RPF record could then be set up by the domain owner, either as a separate string or an entry in the same string, at the same time as the SPF record, and so forwarding could be enabled by the person who should control it- the domain owner, without worrying about whether one company or another had implemented the checks. However, this is only a minor flaw. Much more significant is the fact that all these systems depend on publishing information. What is published for the use of the good guys is also available to the baddies, and that's the real problem. For among the hundreds (or, more likely thousands) of requests for SPF records name servers would receive from MTA's every second could be hundreds of identical requests from a data-mining program seeking to build a reverse-lookup database. Once the spammers have such a database it will be relatively simple for them to write software which spoofs credible domains for every spam injection point they use. And where will that leave us? Back where we started, but with increased network traffic and DNS load doing useless checks. Certainly, my experience with spam is that, wherever it appears to come from, there are only five or six basic variants being sent repeatedly at any one time. Therefore, it is likely all this mail is coming from only five or six real sources which have managed to infiltrate the Internet at a large number of points. Do we really imagine people who do that will be put off by the need to run a little more automated research? Identifying spammers (or, more likely, trojanised mailers) and their reply websites (or, again more likely, trojanised proxies) is only as good as the abuse desks which take action, and overstretched resources take time to close down these gateways. The spammers know this, and presumably make their profit in the intervening interval, and are always ready to move on. They are the Internet's suitcase boys, standing on a street corner and ready to run when a police officer comes within sight. To make spamming and the associated activities unprofitable requires an automated system which either cannot be abused, or which punishes abuse so rapidly it cannot be worthwhile. I don't want to be negative, but it seems evident that a lot of highly talented effort is being directed at something which is not a solution, and that effort could be better used devising something more radical and effective. I realise such a solution might be off-topic for this list. I have no ideas at present, I'm afraid. I was directed to this list by the spf-discuss sign-up response. Best wishes, K.J. Petrie.

Out of Office AutoReply: STATUS

Romascanu, Dan (Dan — 2006-08-11T11:28:15

I am out of office on vacation. I will be back on August 21, 2006. I will not read and respond to e-mails during this period. If you need to contact me urgently, please leave a voice mail message at my office number. Regards, Dan

A request for your support of: hutzler-spamops-05.txt

Carl Hutzler — 2006-01-26T16:25:49

All: Dave Crocker, Pete Resnick, Robert Sanders, Eric Allman and I pulled together a BCP (Best Practices) document as a result of a number of discussions between some ASRG members and the old ASTA (antispam technical alliance) group. The latest version of the document is published on the MIP Association site and has been submitted to the IETF. We have gone through 5 drafts now with reasonable review during each stage. Document locations: http://mipassoc.org/spamops/draft-hutzler-spamops-05.txt http://ietfreport.isoc.org/all-ids/draft-hutzler-spamops-05.txt If you are not familiar with the document, the main ideas expressed are how: 1) To improve lines of *accountability* for controlling abusive uses of the Internet mail service. (when abuse happens, which party is responsible) 2) To provide recommendations for *constructive operational policies* between independent operators of email transmission services including the submission (or posting) of email into the transmission network (certainly very relevant to the deployment of DKIM and other email authentication type technologies) We are at a stage in the life cycle of this document where it would be helpful to see a renewed support from the technical community. *So how can you help? Simple! * Just reply back to me or any of the authors (email addresses available in the document itself) with a couple of words of support: - how this document might help you justify doing the right thing (maybe to your management) - how this document helps establish inter-isp best practices and breakdown of responsibilities for abuse situations - how this document helps establish important operational practices in the area of Email Authentication deployment - other? We will pull together the words of support and provide them to Bert Wijnen as a way to show the level of interest in getting this thing through. (FYI, Bert Wijnen is the Operations and Management Area Director we have been working with on this final stage.) Thank you in advance, Carl (on behalf of all of the authors)

Research question: How many legitimate mail sources are out there?

Matthew Elvey — 2005-08-13T04:09:02

Would someone out there please take a stab at answering this question? Or has it been answered already? What to I mean by a 'mail source'? Well, in technical terms I'm thinking someone could say something like: "Here's info from a large ISP (handling mail for x million customers). Over a period of ____ it accepted mail from x IP addresses that it thinks were sending it mostly ham" I'd be even happier with something like this: it accepted mail from x TLD Names in the HELO. I could live with something like: my greylisting server whitelisted x IP addresses (I'm figure John Levine could give us this number quite quickly for his a "several hundred individual mailboxes, a few dozen mailing lists, and the abuse.net message forwarding system.") Of course, sometimes several servers send through one IP, or one server sends through several IPs... I'm guessing that there are under a million such mail sources. There are around .1 billion TLD Names*. This is apropos this thread: SPF Loses Mindshare at http://www.circleid.com/article.php?id=1157_0_1_0_C/ *http://www.registrarstats.com/zonefile_enlarged.asp (Could be a few times more more, as this doesn't list ccTLDs...)

A New Great Anti-Spam Tool??

Hector Santos — 2005-07-26T19:48:23

Now for lighter side of the market! This might explain why our Russian spam has decreased!!! RUSSIA'S BIGGEST SPAMMER MURDERED IN ROBBERY ATTEMPT The murder of Russia’s biggest spammer Vardan Kushnir was not connected with his Internet activity, but with a straightforward robbery, Moscow investigators reported. Kushnir was found dead in his Moscow apartment on Sunday. http://www.mosnews.com/news/2005/07/26/kushnirclonidine.shtml Moral: Beware! - SPAM at your own RISK!!

Paper on Path and Cryptographic Authentication Technologies

william(at)elan.net — 2005-06-10T15:08:15

Hi, I've finished and now making available full version of the paper on Email Security with Path and Cryptographic Authentication Methods - 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 About 3/4 of the paper is an overview of the various email anti-spoofing technology proposals that were/are discussed at MARID and MASS. Even though many people already know about these topics I think it'll be worth it for you to read (or at least glance through) anyway, parts on the overview and how its structured are unique as it has number of tables and focuses on how the technologies protect various email identities and these interactions and differences. 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 - 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. The reminder 1/4 (chapter 6) of the paper is my proposal on how different path and cryptographic technologies can compliment each other. In particular I propose that cryptographic mail signature when added by MTA include "hostname" of the system adding the signature and this be considered an identity and be verifiable as being correct host that added the signature. After that path authentication technology can use verified hostname as the source for say SPF authorization (in place of where SMTP Client IP would normally be used), this allows to effectively bypass "forwarding problem" as SPF would now be able to directly verify if original source mail server that mail came though (before forwarding) is on list of mail systems authorized to be source of messages with given email address in MAILFROM or some other identity. Having bypassed forwarding problem this makes it possible to actually reject safely using SPF, although it requires number of additional policy records, including info that all source systems are adding signatures. ------------------------------------------------------------------------ IPR Disclosure: Algorithm I described above for doing path authorization after forwarding based on hostname from crypto signatures is patent pending. License is expected to be compatible with GPL programs. ----------------------------------------------------------------------- There is a public comment section open on website also where you can post your comments on the paper and its content and I'll gladly take those on the mail list or privately.

draft-schlitt-spf-classic-02.txt

Douglas Otis — 2005-06-08T19:15:12

1. Introduction ... ,---- | An additional benefit to mail receivers is that after the use of an | identity is verified, local policy decisions about the mail can be | made based on the sender's domain, rather than the host's IP address. | This is advantageous because reputation of domain names is likely to | be more accurate than reputation of host IP addresses. Furthermore, | if a claimed identity fails verification, local policy can take | stronger action against such e-mail, such as rejecting it. `---- 2.5.3. Pass ,---- | A "Pass" result means that the client is authorized to inject mail | with the given identity. The domain can now, in the sense of | reputation, be considered responsible for sending the message. | Further policy checks can now proceed with confidence in the | legitimate use of the identity. `---- This is where SPF and Sender-ID make a very serious mistake. This assumes "server authorization" is equivalent to "sender authentication." It would be like me making a declaration that the postal service is authorized to deliver my letters, where recipients are then claiming any letter received from the postal service bearing my name is authentically or genuinely from me. Of course that would be a false assumption, yet this draft describes the sender as "considered responsible for sending the message." Review the many assumptions being made before arriving at this conclusion. This false assumption is also why publishing SPF records is unwise for the majority of domain owners. 2.1. The HELO Identity ,---- | The "HELO" identity derives from either the SMTP HELO or EHLO command | (see [RFC2821]). These commands supply the SMTP client (sending | host) for the SMTP session. Note that requirements for the domain | presented in the EHLO or HELO command are not always clear to the | sending party, and SPF clients must be prepared for the "HELO" | identity to be malformed or an IP address literal. At the time of | this writing, many legitimate e-mails are delivered with invalid HELO | domains. | | It is RECOMMENDED that SPF clients check not only the "MAIL FROM" | identity, but also separately check the "HELO" identity by applying | the check_host() function (Section 4) to the "HELO" identity as the | . `---- There is an expression, when your only tool is a hammer, everything looks like a nail. While checking the HELO may extend the use of name reputation into the initial exchange, the use of SPF to confirm the HELO is using a rather heavy hammer. The need for checking the HELO would be to protect network resources using a unified name reputation service. The potential for hundreds of DNS queries to resolve something as simple as HELO means this scheme has a rather basic flaw. While there is no reason for SPF to define how results are tallied, effectively this check could double an already sizeable overhead. Would the HELO override the MAILFROM? With respect to finding a means to stop abuse at the source, the HELO would prove more useful. However, SPF is poorly suited to fulfill this function. The prior justification for attempting to resolve the HELO was limited to the handling of a DSN message with a null MAILFROM. With SPF failure expected in this case, wouldn't something like BATV be more effective in this situation? 2.4. Checking Authorization ... ,---- | Without explicit approval of the domain owner, checking other | identities against SPF version 1 records is NOT RECOMMENDED because | there are cases that are known to give incorrect results. `---- Do you really think this sentence will cause a company to change their released version of Sender-ID? Sender-ID advocates will be quick to indicate they use both methods looking for any authorization. This becomes potentially a disaster when reputation is then misapplied, due to there being a lack of sender assurances. If you insist at retaining the v=spf1 record, providers should expect needing a license to assure the PRA. I fail to see the justification for not offering a positive means to express the scope of the record. Depreciate the version 1 record. Both SPF "new classic" and Sender-ID may continue to utilize these older records. Moving forward, a scoped version of the record offers a safer approach. It would also permit SPF records to be used for white-listing only. There have been many technologies thwarted by a large company's ability to dictate the definitions they promulgate. A large company may not be right or fair about their selection. Something as simple as data compression caused sizeable losses by a last minute imposition, even when eventually adjudicated as unfair. Accept this banal reality. -Doug

Resent- header fields

william(at)elan.net — 2005-05-29T14:31:06

You probably all know that I have a problem with how SID drafts says Resent header fields are to be used... Well, just out of curiosity I wanted to know how they are they really used in the real world and lucky me I use one of those mail clients that actually supports it (though I've never tried this feature before and kind of came upon it by accident). Anyway, I'm going to demonstrate (and also test it with mail list) in a moment as I forward copy of this post back here with resent headers.

Resent- header fields

william(at)elan.net — 2005-05-29T14:31:06

draft-schlitt-spf-classic-01.txt

Douglas Otis — 2005-05-26T20:02:25

My previous message was to explain why the MARID reflector is being used for these comments. SPF could offer white-listing utility, provided there is consensus on the record's scope. Such use requires that this scope be defined, or not used as a basis for accruing reputations. Of course, this would make SPF useless for anything other than white-listing. Nor would I trust anyone to honor such exclusion. However, SPF proponents still insist this mechanism is fair with respect to assessing reputations. I say it is fundamentally flawed, as assumptions of assured identifiers place domain owners in serious jeopardy. The email provider must be held accountable in any meaningful approach for abating abuse. However, SPF avoids such accountability. A provider may feel SPF based reputation systems are of little concern to them, but it should be of tremendous concern for their customers, who are often little more than domain owners. Only signatures offer domain owners a modicum of control and oversight in their pursuit of protecting their domain's reputation. Be that as it may, I see this effort as reducing the harm created by SPF. : < 1. Introduction ,---- | The current e-mail infrastructure has the property that any host | injecting mail into the mail system can identify itself as any domain | name it wants. Hosts can do this at a variety of levels: in | particular, the session, the envelope, and the mail headers. While | this feature is desirable in some circumstances, it is a major | obstacle to reducing Unsolicited Bulk E-mail (UBE, aka "spam"). | Furthermore, many domain name holders are understandably concerned | about the ease with which other entities may make use of their domain | names, often with malicious intent. '---- This paragraph lists many different identities that could be used to identify the sender, and implies any could be examined to discover possible server authorization. As just mentioned, some still consider this provides a method for performing sender authentication. These same individuals will happily block any such domains, once they are assumed abusers. After all, abusers can and will also publish SPF records. A disagreement regarding which of these identifiers MUST be assured by the sending server (to protect their client's reputation) occurs within this draft and the draft-lyon-senderid-core-01.txt. It is amazing that this happens even though both of these drafts share the same author. Of course, protecting one's reputation depends upon this important detail. However this draft only defines use of MAILFROM within the message, and ignores this rather serious concern. This is not FUD, this is just F. : ) Unless providers can assure their customers that there are no conflicts within all message PRAs, any other customer would be allowed to create serious harm. This harm could originate from a Zombied computer of such a customer. The abuser may utilize SPF records to obfuscate where the message originates to prolong their success, when seeing such messages are not blocked by the sending server. SPF based reputation systems could employ local or divergent databases that attribute domain abuse based upon the "assumed" sender. (I want to say based upon "Sender Assumptication.") How can the domain owner restore the use of their domain, after their provider naively believes they can assume how a record will be interpreted which has an undefined scope? Wouldn't providers be negligent when advising the use of SPF and not making strict PRA validations? Publication of a dummy record for PRA, which may cause loss of messages, does not seem a satisfactory solution, as provided in the Sender-ID draft. 10.2. SPF-Authorized E-Mail May Be UBE ,---- | The "MAIL FROM" and "HELO" identity authorizations must not be | construed to provide more assurance than they do. It is entirely | possible for a malicious sender to inject a message using their own | domain in the identities used by SPF, to have that domain's SPF | record authorize the sending host, and yet the message content can | easily claim other identities in the headers. Unless the user or the | MUA takes care to note that the authorized identity does not match | the other more commonly-presented identities (such as the From: | header), the user may be lulled into a false sense of security. '---- An interesting, albeit fuzzy, warning indeed. Add another warning of a similar nature. Because there may be an assumption made regarding server "authorization" (even potentially a neutral authorization) being equivalent to sender "authentication," your domain may be attributed for abuse which forges any identifiers other than MAILFROM. Microsoft describes a PRA process based upon this specific SPF record, used in conjunction with SmartScreen, for example. This creates the potential for serious harm to the domain owner's reputation, when providers ignore potential PRA conflicts. Add a warning that examination of the PRA is REQUIRED for cases where the recipient uses draft-lyon-senderid-core-01.txt, which only utilize the record syntax described in this draft. Publishing an SPF record will not ensure which identifier will be held accountable for abuse. If your email-provider does not license the PRA algorithm, there should be no expectation that your domain's reputation is being protected. I'll be happy to agree with Carl about the white-listing utility of an SPF record. To repair this draft, there appears little choice, but to adopt the later version of the SPF record which includes the scope of the identifiers assured by the sender. That was the reason for including scope in the first place. Ignoring this issue would be ignoring a rather big elephant in the room. It would also represent serious negligence on the part of the provider. 10. Security Considerations ,---- | SPF implementations SHOULD limit the total amount of data obtained | from the DNS queries. For example, when DNS over TCP or EDNS0 are | available, there may need to be an explicit limit to how much data | will be accepted to prevent excessive bandwidth usage or memory | usage, and DoS attacks. | | MTAs or other processors MAY also impose a limit on the maximum | amount of elapsed time to evaluate check_host(). Such a limit SHOULD | allow at least 20 seconds. If such a limit is exceeded, the result | of authorization SHOULD be "TempError". '---- With this draft mandating more than one hundred DNS lookups, this raises a concern regarding how the 20 second time limit is employed. A local recursive DNS resolver may act as a UDP amplifier. Congestion avoidance depends upon the application making the requests to wait, in order to maintain stability. There should be some language that warns against doing these many lookups in parallel, and simply timing out the effort to resolve server authorization for a particular message. If parsing routines have not made these provisions, then setting up a two-tier DNS resolver where the Internet facing DNS resolver is not recursive and is rate limited on port 53, could offer a solution. There should also be a warning about acceptance of duplicate records. The same two-tier approach would offer protection when older DNS resolvers are being used that do not ensure replicate lookups are prevented. -Doug

"If you believe that the SPF concept is fundamentally flawed,please subscribe at http://www.imc.org/ietf-mxcomp/"

Douglas Otis — 2005-05-25T23:51:13

The following is a greeting when subscribing to spf-discuss: ------------------------------- ----------------------------------- It would appear subscription to spf-discuss acknowledges acceptance of the SPF concept. However, problems related to SPF have become even more pronounced since dissolution of the MARID WG. Sender-ID has usurped the initial SPF record for PRA evaluation, and is advising use of methods in conflict with bounce-address validation efforts. The Sender Authentication Whitepaper, passed on to MAAWG from the FTC conference, has not undergone requested changes. There are several assertions that remain misleading and in error. SPF _is_ fundamentally flawed as it removes accountability from the email providers, at the expense of the domain owners and consumers. Contrary to the promotions, SPF will not stop spam. SPF will not prevent your domain from being forged, without great diligence by now anonymous email providers, as well as, universal compliance at each public MTA, and a slew of modification made to every email client. I can not accept the premise there are no serious concerns related to publishing SPF records. No scheme without a reputation assessment will prevent email abuse. Abusers are among the first to adopt changes offering greater access. Reputation puts the teeth in any email protection scheme. Beware, SPF may bite! You may get bit by recipients that consider SPF authorization is equivalent to identifying the source of a message. This assumption is unsafe and wholly unfair. This assumption is unsafe as forgery can still continue. This assumption is unfair as a basis for accruing the reputation of a domain owner, as they often have no administrative oversight with which to assure their protection. Instead of SPF records preventing harm when a domain is forged, SPF authorization may actually cause an otherwise impeccable domain obtain a bad reputation, when forgery nevertheless continues. Abusers may actually utilize your SPF records to usurp previously good reputations. What is worse, redemption of your reputation may not be practical. Abusers may take advantage of your desire to ensure your emails are delivered. Abusers may also take advantage of your email provider's desire to not license Microsoft's Sender-ID algorithm, which sets terms incompatible with open-source software. The selected domain offering server authorization is assumed to have originated the message. Microsoft calls this unfair assumption, “Sender Authentication.” Calling Sender-ID “Sender Authentication” would be like me making a declaration that the postal service is authorized to deliver my letters, where recipients are then claiming any letter received from the postal service bearing my name anywhere is authentically or genuinely from me. Of course that would be a false assumption, and Sender-ID is no different. How will abusers take advantage of these normal desires and false assumptions? While strictly limiting authorization to just the email provider's servers reduces some risk of your domain being forged, this may cause your messages to become lost as a result. This loss may occur when recipients use providers that select accountable domains based upon the “classic” bounce-address algorithm. The recipient may forward messages, which then makes your message appear to be from an unauthorized server. Your message may also become lost when sent through some list-servers, or through servers running older versions of email protocol. Why quibble over who is responsible for implementing a plethora of fixes, where any change to email often takes decades? The remedy for the loss of your messages is to leave your SPF server authorization list open-ended. When from an unknown server, the open-ended list then declares a lowered level of authorization. This lowered level of authorization is intended to alert recipients to increase the scrutiny given such messages. However, this lowered level of authorization will not ensure your reputation remains protected from forgery. For example, abusers take advantage of Microsoft's automatic image fetching to compile valuable lists of active email accounts, just by using encoded image links. These abusers don't really care which folder or level of authorization they obtain. They don't care that recipients fail to respond to their email either. These abusers would be thrilled to see recipients unsubscribe. Your concern is whether the recipient also clicks the “spam” button, when these messages have forged your domain. With SPF records being very public, your domain's reputation will be exposed to any abuse possible. Publishing open-ended SPF records may even act as an invitation, should a SPF reference become mandated by some providers. Furthermore, a provider that does not ensure Sender-ID headers are not in conflict with any of their other customers, may risk your domain's reputation, especially when this provider's limitation becomes known. When viewed by Sender-ID, such providers can not ensure your domain will not be forged. Of course, Microsoft may see this problem as being to their advantage. Once this becomes enough of a problem for domain owners, providers may find it necessary to license Microsoft's algorithm after all. With phishing techniques becoming seemingly epidemic, Microsoft is quick to offer Sender-ID as a remedy. With respect to phishing, Sender-ID considers the From header as the lowest priority for basing acceptance, even though this is the header typically seen by the recipient. Microsoft has made this problem worse by displaying the user friendly name, known as the “pretty” name, rather than the actual mailbox address. Phishing ploys often use disposable domain names for obfuscated links, which could also provide SPF authorizations. SPF records can also be constructed to covertly and fully authorize all servers within the entire Internet. SPF can covertly enable Zombies anywhere in the world. Sender-ID, even as a lame phishing deterrent, presumes wide adoption of proprietary algorithms by mail clients and providers. Assurances offered by Sender-ID aware applications are dangerous, due to the acceptance of hidden headers, and expectations of compliance to these proprietary algorithms. This may actually place consumers trusting such assurances in greater peril. Sender-ID itself may weaken the integrity of the DNS, where Microsoft only offers the advice that providers use "properly paranoid DNS resolvers.” Sender-ID requires that domain owners trust their email providers, although many providers do not authenticate their own customers. Heedless publishing of SPF will expose domain owners to substantial risk. In addition, Sender-ID does not identify these providers either, so there is little to directly motivate email provider diligence. Signatures are a safer alternative to this nonsensical approach that depends upon a magic wand that mysteriously transforms “server authorization” into “sender authentication.” There is already a digital signature technology, S/MIME, that can be handled by more than 400 million email clients such as Outlook, Outlook Express, Lotus Notes, Novell Groupwise, Netscape, Mac Mail, Mozilla, Thunderbird, Eudora, Becky!, Bat!, Mulberry, Blackberry, and more. Surely, financial institutions being phished can afford the digital certificates needed to verify their From address. Very soon major providers will offer DomainKeys signatures on outbound messages, and will be checking these signatures when messages enter their email gateway. The use of email signatures is on the near horizon. DomainKeys can be deployed within email gateways, and easily implemented. Compared to S/MIME with browser Certificate Authorities, DomainKeys lowers cost barriers, and does not depend upon the end-user email applications. When deployed for solicitations unrelated to commerce, cost is often a greater concern as well. Signatures can indicate where the message originated, regardless of the use of subsequent relays, or message forwarding, and offer a truly safe means to defeat phishing attempts. Unlike signature methods, Sender-ID limits the domain owner's choice of providers, and will likely create endless consumer complaints. Signatures indicate where the message originated without changing email's architectural paradigms. Signature verification only requires the recipient make the required checks, and is not required that these checks be performed at every intervening server that relays the message. Even spoofed bounce messages can be curtailed by signing the bounce-address using Bounce Address Tag Validation. Domain owners can sign their own email, and safely use providers that may exercise dubious diligence, without jeopardizing their domain's reputation or exposing their recipients to phishing threats. There is little benefit derived from jumping upon the Sender-ID bandwagon, but there is much more to loose when publishing SPF records. Consider DomainKeys instead. -Doug

draft-lyon-senderid-core-01.txt

Douglas Otis — 2005-05-20T20:07:32

1. Introduction ,---- | This document defines a pair of closely-related tests. One validates | a message's Purported Responsible Address (PRA) as defined in [PRA]. | The other validates a message's Reverse-Path (also known as MAIL-FROM | address) as defined in [SPF]. | | An e-mail sender complying with this specification SHOULD publish | information for both tests, and SHOULD arrange that any mail that is | sent will pass both tests. An e-mail receiver complying with this | specification SHOULD perform at least one of these tests. `---- This "SHOULD" advice makes it difficult for an email provider to ensure mailbox addresses are without conflict, without also licensing the PRA algorithm. 2. Problem Statement ,---- | In the long run, once the domain of the sender is authenticated, it | will be possible to use that domain as part of a mechanism to | determine the likelihood that a given message is spam, using, for | example, reputation and accreditation services. (These services are | not the subject of the present mechanism, but it should enable them.) `---- Because the server was authorized to support an "assumed accountable sender," this process has "authenticated" the sender? Would this be like me saying "Because I authorized the postal service, and express carrier, therefore any letter from them bearing my name is "authentically" from me." Reconsider the problem of not knowing which identity was implied by the sender initially. While this mechanism provides for a case where a message arrives through an unauthorized server, which may allow the message to be rejected, this by no means provides assurances sufficient for accruing reputations against the "assumed accountable sender." This would be wholly unfair. 3.1 Version and Scope ,---- | Under Sender ID, receiving domains may perform a check of either the | PRA identity or the MAIL-FROM identity. Sending domains therefore | require a method for declaring whether their published list of | authorized outbound e-mail servers can be used for the PRA check, | the MAIL-FROM check or both. `---- This does not prioritize these two checks. 3.4 Compatibility ,---- | Domain administrators complying with this specification are required | to publish information in DNS regarding their authorized outbound | e-mail servers. [SPF] describes a format for this information | identified by the version prefix "v=spf1". Many domains have | published information in DNS using this format. In order to | provide compatibility for these domains, Sender ID implementations | SHOULD interpret the version prefix "v=spf1" as equivalent to | "spf2.0/mfrom,pra", provided no record starting with "spf2.0" exists. | | Administrators who have already published "v=spf1" records SHOULD | review these records to determine whether they are also valid for use | with PRA checks. If the information in a "v=spf1" record is not | correct for a PRA check, administrators SHOULD publish either an | "spf2.0/pra" record with correct information, or an "spf2.0/pra ?all" | record indicating that the result of a PRA check is explicitly | inconclusive. `---- Those that do not wish to be assessed by a system using a dubious "authorization" as a basis for compiling reputations, will have difficulty expressing this desire as a result of these semantics. To "opt-out" of Sender-ID, a weak level of authorization must still be offered. There have been presentations where weak authorizations would eventually be refused, and coupled with warnings these types of records could potentially lead to damaging one's reputation. I would describe this as the "Sender-ID trap." 6.1 DNS Attacks ,---- | An MTA could largely defeat such an attack by using a properly | paranoid DNS resolver. `---- While noting the format and related processing of the DNS record is defined in draft-schlitt-spf-classic-00, it seems this statement could elaborate on specific attacks. Warnings regarding the processing of lookups in parallel, asserting a truncated timeout, or preventing replicate lookups, rather than assuming any attack related specifically to SPF/Sender-ID is resolved by way of paranoia. : ) 7.1 Simple E-mailers ,---- | In the majority of cases, the domain's published information will be | the same for both the PRA and MAIL FROM variants of this test. In | this case, domains SHOULD publish their information using an SPF | record with the prefix "v=spf1". Doing so will render their | published information usable by the older SPF protocol, too. (See | [SPF] for information on the SPF protocol.) `---- A SHOULD publish "v=spf1" interpreted as applying to either PRA or MAILFROM ensures lack of clarity. To achieve a modicum of spoofing resistance, depreciate "v=spf1" in the SPF draft, which is integral to this draft. 7.2 E-Mail Forwarders ,---- | In order to pass the PRA variant of the test, a program that forwards | received mail to other addresses MUST add an appropriate header that | contains an e-mail address that it is authorized to use. Such | programs SHOULD use the Resent-From header for this purpose. | | In order to pass the MAIL FROM variant of the test, a program that | forwards received mail to other addresses MUST alter the MAIL FROM | address to an address under its control. Should that address | eventually receive a DSN relating to the original message, that DSN | SHOULD be forwarded to the original MAIL FROM address. However, if | this altered address receives any messages other than DSNs related to | the original message, these messages MUST NOT be forwarded to the | original MAIL FROM address; they SHOULD be refused during an SMTP | transaction. `---- Forwarding DSN? This seems challenging and problematic. This also drops the typical "on vacation" response. It also weakens BATV efforts. 7.5 MUA Implementers ,---- | When displaying a received message, an MUA SHOULD display the | purported responsible address as defined by this document whenever | that address differs from the RFC 2822 From address. This display | SHOULD be in addition to the RFC 2822 From address. `---- Again another SHOULD use a licensed algorithm? Although this may be intended to stop phishing attacks made against financial institutions, the predominate MUA does not display anything other than the pretty name of the From. In addition, Sender-ID places the From at the lowest priority of accepted headers. As another consideration, financial institutions place great value on assured delivery, that is incompatible with the strict authorization needed to protect the user from seeing phishing attempts. There are less wrenching and safer alternatives. If financial institutions were to use S/MIME and browser compatible certificates, this could already be handled by more than 400 million email clients such as Outlook, Outlook Express, Lotus Notes, Novell Groupwise, Netscape, Mac Mail, Mozilla, Thunderbird, Eudora, Becky!, Bat!, Mulberry, Blackberry, and more. If not understood by the MUA, or the recipient is aware of signature related problems with their provider, the signature attachment could be ignored. At least wary recipients could check certificates to be assured of the From address without using a proprietary MUA. In addition, there are other lower cost signature schemes, such as DomainKeys, that can be implemented on the MSA and MDA, independent of the MUA, and afford real consumer protections with much stronger assurances, without expecting all users will adopt a proprietary MUA. Calling Sender-ID "Sender Authentication" should stop. This is overstating to a great degree the assurances afforded from a confirmation of server authorization by an apparent sender. Remember, these records are public, and it is typical for email providers to be shared by many different domain owners. It is hard enough getting providers to authenticate their clients, without expecting them to enforce new constraints that are sure to cause endless complaints. While it remains the email provider most able to ensure abuse is curtailed, Sender-ID ignores their accountability. I find it difficult trust this approach that offers no means to verify who was actually accountable. At least with a signature, there is little doubt. -Doug