gmane.ietf.mxcomp

Re: Mail Server Registries and Foreign Sender Authentication: A Proposal

Douglas Otis — 2007-04-03T18:17:29

On Apr 2, 2007, at 8:48 PM, Randy Smith wrote: Perhaps someone could use OpenID for email submission. Providers would need to establish another method to validate the holder of the OpenID. OpenID might improve the user experience when offered as an option to those who's identity has already been validated by other means. OpenID vouches for an ID, but does not exclude bad actors holding millions of such OpenIDs. In such a case, when OpenID requires account details to change, some other method other than OpenID would be required. Perhaps OpenID provides their public key to be used as another authentication alternative. OpenID will not function in a manner similar to that of kerberos. The user agent acknowledges a query, but contains no intelligence. This makes OpenID instantly available but somewhat fragile and poorly suited for automated authentications. The OpenID could offer authorizations. : ) Review rfc2554 and rfc4409. OpenID for SMTP authentication of outbound mail would likely need to restrict the selection of the Identity servers. This would tend to make OpenID in this case a bit less open. : ) -Doug

Re: Mail Server Registries and Foreign Sender Authentication: A Proposal

Randy Smith — 2007-04-03T03:48:23

On 3/28/07, Jeff Macdonald e-dialog.com> wrote: What I was think of was using the trust features of PGP to allow the server to make decisions based on how much the key is trusted and the "trustiness" of other keys in the chain. If a web of trust could be built by some other means than PGP, that's fine. It's the trust and key signing that's important here, not the encryption. Honestly, I'm not sure as I'm not familiar with the details of Open ID. I think the best way would be for the server to verify the identity with the ID provider rather than trust the client. That's pretty close to what I was thinking.

Re: Mail Server Registries and Foreign Sender Authentication: A Proposal

Douglas Otis — 2007-03-29T18:39:33

On Mar 28, 2007, at 7:52 PM, Jeff Macdonald wrote: I don't think an SMTP extension is required. Explaining follows: There are OpenID extensions proposed to allow the exchange of public keys related to an Identity. http://openid.net/specs/openid-service-key-discovery-1_0-01.html There are OpenID extensions proposed for email-addresses such as: http://www.sappenin.com/openid/ext/oet/openid-email-transform- extension-1_0.html http://blog.phpbb.cc/2007/02/04/smtp-service-extension-for-yadis- discovery/ Now imagine an extension to DKIM, OpenPGP, or S/MIME where a query method is defined for OpenID. This would allow senders to sign messages and allow recipients to verify using extensions proposed for identifying email-addresses using OpenID. This would not require any change to SMTP, but would require a minor change to DKIM, OpenPGP, or S/MIME. But it gets better... Add: Sender- wants proof of recipient and secure receipt for web exchanged information. It would also be possible to forgo any public-key cryptography related to the message by using standardized conventions for where the web exchanged information is placed with regard to a specific identity. Perhaps a subdomain of OMail. could work where the local-part is normalized within the first path. Sub-path components could function as the message-ID, for example. When a message is exchanged using something like BURL, the identity of the sender can be deduced from the embedded URI. Nothing else is needed as it would be expected this location would be identified using SSL certs when related to commerce. It would be rather difficult to forge such messages when the entire message body is found via the link. The web server could then use OpenID to ensure only the intended recipient receives the message. When done using HTTPS, email becomes secure without use of encrypted messages. OpenID is already establishing whitelists to protect blogs. This effort could extend to whitelisting email that is sent using such conventions. There could be extensions made in the HTTP header structures found in OMail subdomain that lists the root names of all "authorized" SMTP clients, for example. I doubt this would be needed once only BURL style messages are adopted as an exclusive mode of exchange. This will take awhile. Possible, but this would require a lengthy adoption process. There could be a convention used for the SMTP client host-name that also signals use of an authorization field found within the OMail subdomain. This convention might look something like: EHLO: OMAIL-.. An extension could also be used. Which ever shows the least resistance will likely be the best choice. -Doug

Re: Mail Server Registries and Foreign Sender Authentication: A Proposal

Jeff Macdonald — 2007-03-29T02:52:57

On Wed, Mar 28, 2007 at 07:42:51AM -0600, Randy Smith wrote: Randy, could you use OpenID terms in describing your SMTP extension? I'm having trouble understanding how this would work from your description in your blog. Adding PGP seems to add additional overhead for what OpenID provides (unless I'm totally mis-understanding OpenID). Here are what I think are some of the relevant terms: MTA terms: C:Sending MTA- sending message S:Receiving MTA- receiving message OpenID terms: Consumer- wants proof End User- wants to prove their identity to Consumer User Agent- End user web browser I is the Identity server Say there is a new ESMTP keyword, OPENID. Here's a breakdown loosely following your example: C->S: connects S->C: banner C->S: ehlo S->C: OPENID is returned along with whatever else C->S: OPENID S: S->I: S->C: 250 S->I: associate with identity provider? Section 4.1.x C->I: go to identity provider? Section 4.2.x C->S: OPENID CRED S->C: 250 Ok Credentials are OK I may of abused SMTP extensions in this example (re: OPENID CRED).

Re: Mail Server Registries and Foreign Sender Authentication: A Proposal

Dean Anderson — 2007-03-29T02:50:28

On Wed, 28 Mar 2007, Randy Smith wrote: This is myth, stated since at least 1996, probably earlier. 10+ years of anti-spam work shows that one does not need to know "who" is sending mail to effectively complain. One only needs the IP address and a time. Their ISP knows who they are, or they don't. The ability to lie is irrelevant. That's as good as that identity information gets, too. Privacy laws would preclude anything else. The biggest problem is that the real commercial bulk emailers comply with CAN-SPAM, and thus aren't a problem, while the miscreants send pure annoyance with no commercial purpose, but it takes a bit of research to figure that out. One really needs to find out who the miscreants are. I've identified a few: they were pretending to be anti-spammers. They still pretend to be anti-spammers. This was tried and didn't work. 'Trust' for email sending, extends to everyone, and the system is still subject to abuse, albeit cryptographically signed abuse, and now you have a problem with key management, and you still need their ISP to translate a real identity to a crypto key, which they still can't do without a court order or warrant. And a new account comes with a different crypto key, and keys will be stolen by viruses and rooting. Same problem, many dollars later. But good if you are selling crypto-email systems and consulting. I showed in 2003 that information theory PROVES that the miscreant abusers cannot be stopped by technical means, because a communications system that is free from abuse [that is 'can't be abused' in contrast to just 'isn't being abused'] is also free from covert channels, and hence contrary to a thereom of information theory which states that a communication system can't be proven free of covert channels. Covert channels are always possible. It is always possible to abuse a communication system. So, whack-a-mole is as good as it gets. Actually, that's not a strong enough statement. This is better: Whack-a-mole is as good as it CAN get, without upending information theory. Since information theory is tied to thermodynamics, and is physically and mathematically sound, that probably won't happen. What to do? Get good a whack-a-mole. Indeed, we can get better at that: standard forms for abuse complaints comes to mind. Maybe a standarized web app for submitting such forms, that can be supported by every ISP complaint/ticket system as a standard interface. -- It is quite ironic that the people who talk most about reputation systems have no problem associating _themselves_ with very disreputatable people and court-proven liars, people pretending to be anti-spammers, but obviously not. I suspect there is a story there, somewhere; amid the people who pretend to be anti-spammers while engaging in abuse and lies for their personal gain. A long time ago, I said that someday, when the script kiddies get to be adults, and the statute of limitations expires on their activity, that they will come forward and spill their beans on who, what, why and when. I think the "Kevin Mitnicks" of the script-kiddie spamming world will want to tell their stories. The first generation of script kiddies should be coming of age and beyond the statute of limitations pretty soon. --Dean

Re: Mail Server Registries and Foreign Sender Authentication: A Proposal

william(at)elan.net — 2007-03-28T15:03:40

On Wed, 28 Mar 2007, Randy Smith wrote: Hence we have SPF and proposals such as DKIM and others. One of the issues is that SMTP is not fully client-server but rather store-forward protocol. When you communicate with someone over SMTP as a client you do not know if its true end-user or not. SMTP is built in such a way that extensions to SMTP that any serious extensions only you support are to large degree exactly like a new protocol. We have that in a way - EHLO provides list of capabilities of the server. keywords issued during RCPT and MAIL FROM provide list of capabilities of the client. Even with additional EHLO-like keyword that client would issue the issue is that it could "lie" if it does not want to list certain capabilities based on what it saw capabilities of the server are - so its all volunterily in the same way MAIL FROM and RCPT keywords are when client wants to advertise and turn on certain protocol functions. EHLO is already basicly list of supported extensions where each one can be further subdevided (this is rarely used) into support sub-extensions/parameters No problem, that's what we're still here for :)

Re: Mail Server Registries and Foreign Sender Authentication: A Proposal

Randy Smith — 2007-03-28T13:42:51

On 3/26/07, Douglas Otis mail-abuse.org> wrote: Perhaps. Simpler from the recipient's perspective would be to have the send specify a the URL as part of the SMTP conversation. I hadn't thought of that but it might be an interesting fringe benefit. Since OpenID is built to allow authentication, among other things, against 3rd party systems, it seems like an excellent way to allow and recipient server to authenticate all users who wish to send or deliver mail with their server. Thanks for taking the time to respond.

Re: Mail Server Registries and Foreign Sender Authentication: A Proposal

Randy Smith — 2007-03-28T13:36:41

On 3/25/07, Hector Santos santronics.com> wrote: The biggest problem, IMO, is not the open system but the anonymous one. One reason spam works so well is that its so very easy to lie about who the sender is. I don't think there's any reason why a mail admin couldn't setup their own registration server but as the recipient, I need to have some way of knowing that I can trust the registry, hence the web of trust built around server keys. [snip: fidonet history] What I'm thinking of would be an extension to SMTP rather than an entirely new system. As the main admin for an ISP, the last thing I want to do is build a second system to handle a new protocol that hardly anyone uses (at least, until the rest of the Net migrated). I think the hand shake could be complete wrapped within the SMTP conversation. It may be necessary to add a capabilities keyword similar to IMAP or specify that the EHLO response include a list of supported keywords. Thank you for taking the time to respond to my ramblings. :-)

Re: Mail Server Registries and Foreign Sender Authentication: AProposal

Douglas Otis — 2007-03-27T01:20:20

On Fri, 2007-03-23 at 20:51 -0600, Randy Smith wrote: It would seem OpenID is ideal for controlling a recipient's access to information being sent using BURL style messages. OpenID means the sender would not need to control how the recipient confirms their identity. There would need to be a convention established to translate email-addresses to a URI convention suitable for use with OpenID. This would protect message content as well as confirm the recipient actually received their message. This seems like an ideal mechanism for various sensitive commerce related transactions. By pointing to the message with a URI, there would not be any need to verify the identity of the message source. However, the source URI should use the same conventions as that used for OpenID recipient. As OpenID really needs a specialized viewer, where one designed to function as an MUA would not be unreasonable. OpenID could also help establish filtering criteria as well. OpenID is an interesting mechanism. -Doug

Re: Mail Server Registries and Foreign Sender Authentication: A Proposal

Frank Ellermann — 2007-03-26T04:33:09

HECTOR SANTOS wrote: Nobody was forced to use it for sending mail, unless that person was a *C obliged to test that applicants can receive FTN1 mails. I needed FTN1 for crash mails (rarely, but still). Nope. The FTSC was the standards committee, like IETF/IESG/IAB. The NodeLists were controlled by the *Cs (ultimately the ZCs of the relevant zones), that's like ICANN. The FTSC controlled the definition of the nodelist format (in theory, never changed in my time), not the content. Frank

Re: Mail Server Registries and Foreign Sender Authentication: A Proposal

HECTOR SANTOS — 2007-03-25T20:24:06

Randy Smith wrote: In my opinion, you are not barking up the wrong tree, but the "inevitable tree." Its not a new concept, but a concept we have moved away from in the name of having an open anonymous system. But we seem to be reinventing ourselves to go back to this direction. In short, you are simply talking about a client/server negotiation handshake stage. In my opinion, maybe not in our "engineering" life time, this is will be the ultimate method of client/server operations. The anonymous sender will be "thing" of the past. Look at the old Fidonet technology, 100% based on a similar client/server negotiation concepts. 1) Every server MUST be "registered" with a "HOST", in Fidonet, that would be your uplink Net or Zone Host. In the internet, that might be your "ISP", the early forms of Fidonet Net/Zone Hosting systems that were the backbone of the topology. 2) When installing the software, you applied for a FIDONET address and your "ISP" would check your system for 100% FTN compliance before you were assigned a Fidonet Address. 3) You were not allowed to be part of the "net" if you did not have a 100% FTN compliant client and server. Not compliant? No Fidonet address was given to you. 4) There were four basic requirements: 4.a) The software support the legacy FTN1 file transfer protocol. The more advanced IEMSI is akin to what we have today with EHLO and extended server attributes. 4.b) Although you can apply for a private address, ALL servers must be available during Zone Mail Hour (ZMH). This is akin to having a 100% closed system but there were designated times where you allowed anonymous mail (from a registered FTN member) to come in. 4.c) ZMH was designed for making sure ROUTED mail is ALWAYS available. So even if you didn't allow DIRECT mail, a person can send routed mail to you via your HOST which you must ALWAYS accept. 4.d) During ZHM, at a minimum FTN1 must be supported. There were probably others, but the above were the main things and in addition, the most contentious issues during the "Fidonet/Internet Migration Days." The legacy FTN1 protocol was REALLY old and it has major problems in packet switching networks. ZMODEM and other file transfer protocols designed for Packet switching networks were part of the newer generation Fidonet software, but were OPTIONAL and not required. However, new developers were not bothering with the older problematic FTN1 protocol and using the new protocols which at least 99% of all systems supported. But the old school FTN net police insisted on FTN1 and rejected applications, registrations of any person installing newer and better software if it didn't have FTN1 support. This turned off alot of developers and with the Internet humming around the corner, and new FTSC (akin to IETF) groups created to get around these policing issues, Fidonet began on a death spiral. The one thing the FTSC had control of was the NodeList, this would be akin to DNS. So new Nodelist ZONE files were created to establish new networks where the FTSC had no control. In any case, conceptually, we are talking about the same type of direction. - Registration of servers and clients within some "controlled and centralized" nodelist/DNS system. - It will confronted with the same Legacy issues of supporting legitimate clients that might not part of the "controlled network." As with Fidonet, this is where you will have the major uphill battle. The IETF is dead set against breaking the the current open network integrity of the system. Legacy software must be supported. I happen to agree. Legacy software must be supported, however, I am also open to introducing a ZMH like idea where systems are allowed to designate "open" and "closed" times for legacy systems. Based on these experiences, I had started a IETF draft awhile back that basically defined "SERVER ATTRIBUTES" records that clients will use to obtain server attributes that will cover these client/server negotiation parameters. I happen to believe the idea will be eventually be a major part of the system, in some form or another and we are beginning to touch based with it with DKIM and its SSP ideas. Also look at the growth of SIP communications. It is all going (back) in this direction. -- Hector Santos/CTO Santronics Software, Inc.

Re: Mail Server Registries and Foreign Sender Authentication: A Proposal

Frank Ellermann — 2007-03-24T04:25:01

Randy Smith wrote: The tree is right, but it's not here: This list is dead. For slightly more active lists see the ASRG or the SMTP lists. You might wish to check out DKIM (an RFC approved recently now waiting for its RFC number), SPF (RFC 4408), and draft-irtf-asrg-howe-siq-03.txt for proposals in similar directions, some pieces of the puzzle already exist. They're not based on OpenID, that's rather new. Frank

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.

Re: Doug attack scenarios without SPF

Douglas Otis — 2006-11-20T19:14:53

On Nov 18, 2006, at 6:40 PM, Markus Stumpf wrote: When domains routinely process SPF scripts for accepted messages (not stopped by their block-lists), the potential impact of this operation might be extremely high. There would be little a victim could do to remedy the situation, which makes this a really big problem for them. The NS record technique amplifies effects of an SPF script resolving addresses within 100 different domains executed for each email- address evaluated. The evaluation process may occur for both the PRA and the Mail_From, for example. This would then mean 200 domains times some number of errant and targeted DNSs contacted within a recursion process. The spf-dos-exploit even excluded recursion overhead from the example attack gain calculations. Without this overhead, the example SPF script generates 64 kbytes of DNS traffic per execution! This random domain selection is facilitated by the SPF script (without changing the script itself) as illustrated in the example attack. There is a big difference. UDP does not provide congestion avoidance. SPF routines abruptly timeout execution of a script, where a new script is then started. The prior script may have encountered exponential back-off by DNS. Running another script without waiting defeats congestion avoidance of DNS. The problem described is an exploit made virtually free to attackers using a bot- net where complete flooding of a network backbone is made all too possible. An EHLO lookup would be for 1 host-name, and not the 10 host-names resolved within an SPF MX mechanism. SPF also allows 10 MX mechanisms, which means SPF expects 100 times the number of DNS transactions (ignoring the transactions for the SPF TXT or RR 99 records and that this might be done more than once per message). Exactly. But the same is not true for SMTP clients offering SPF scripts resulting in passing or neutral results. : ( If there are MailFrom of the SMPT client checks made against a receiving MX record (which seems silly as this must be allowed to fail), then SPF would still increase the impact of this checking by an order of magnitude! No. The victim can do nothing to prevent this attack, and there is nothing that those cooperating in the attack will notice. The domains within the message can be completely different from the domains being attacked in the malicious SPF scripts. It is rather common for bot-nets to use hundreds of throw-away domains each day (often at no cost to them). Worse still the SPF results might be providing a PASS for all attacking messages referencing the malicious SPF scripts. While a DNS based attack is not new, the level of obtained by this attack would be, and by a sizable amount. -Doug

Re: Doug attack scenarios without SPF

Dean Anderson — 2006-11-20T19:04:27

On Sun, 19 Nov 2006, Markus Stumpf wrote: I agree. The SMTP server should not try to resolve the EHLO/HELO argument. There is nothing to learn from by resolving this argument. It just adds to the DNS load, and it increases the time to handle a signle message. This then reduces the rate at which the mail server can process messages, and increases the resources consumed by the email server. (gun-foot-fire-aim)

Re: Doug attack scenarios without SPF

Markus Stumpf — 2006-11-19T02:40:48

Hoi, On Fri, Nov 10, 2006 at 11:34:20AM -0800, William Leibzon wrote: while I agree that there is some potential for a attack I don't see it as a really big problem. 1) AFAIK no caching DNS server sends out to *all* servers in NS records immediately. Some are rather clever in detecting identical DNS servers. 2) Caching helps even against lame delegations (ok - the botnet may use random subdomains) 3) Neither for the sender nor for the receiver does it make a real difference how large the hostname in the query is as long as it fits in one UDP packet. It's a packet on the wire. Compared to web traffic hammering against busy webservers it is still peanuts. 4) It is easy for the MTA to check for the length of the EHLO argument and ensure that it fits in one UDP packet 5) It is easy for the MTA to immediately establish temp. blocks for IPs sending EHLO arguments that lead to errors 6) A lot of MTAs already now checks the domain of the 2821.MAILFROM so it is already now possible to start that kind of attack. This is nothing newly introduced. 7) LHS wildcard blocks for abusive domains will also fix the problem rather fast and can be automated. For the attack to work the attacker must own the SLD (or sometimes 3rdLD) to be able to introduce lame delegations. Also the DNS servers for those domains can be automatically isolated or blocked. As I said - there is a potential for attacks but no new one. \Maex

Re: Doug attack scenarios without SPF

John Leslie — 2006-11-10T21:39:12

... clarifying one small portion... William Leibzon leibzon.org> wrote: This deserves some explanation. The CSV design team considered it important to have a way to specify that any subdomains which send mail will have explicit CSV records. (Or, more commonly, that _no_ subdomains should be sending mail.) It is quite specifically intended that the bit which specifies this will be queried and cached by other players than the receiving SMTP server. Thus, you will find in section 7 of the CSA spec: ] ] A receiving SMTP server MAY discover domain assertion information ] (after finding no record for the specific domain in the EHLO string) ] by searching for CSV-CSA records in parent nodes of the EHLO string, ] within the DNS hierarchy. Such a search MUST NOT query a top-level ] domain (such as COM, NET, or UK), and SHOULD NOT query deeper than a ] sixth-level domain. We quite clearly intended that implementors would provide a way to disable these extra queries if they ever prove to be a problem. Speaking for myself only, I expected that reputation services would perform these queries as new EHLO domains come to their attention and periodically thereafter; and that their reputation reports would reflect the domain owners' intent that subdomain EHLOs are not authorized. I was not able to get agreement of the design team to say this in as many words in the spec. Nonetheless, the spec _is_ clear that any reputation service would be entitled to do this. Thus, IMHO, it is likely that this feature would not be available to be abused; and that at worst it might allow five extra queries. -- John Leslie jlc.net>

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

Re: Trouble with Sender Authentication

Dean Anderson — 2006-11-10T17:07:59

On 10 Nov 2006, John Levine wrote: Actually, the top candidates for DNS amplification abuse are large SPF records, followed by large collections IN-ADDR records for a single IP, as is the case for large virtual hosting sites. Both practices are advocated by anti-spammers. I recently saw a ~4k byte SPF record, published by an anti-spam site. DNSSEC signed SPF records will probably break the 8K limit. Thats about a 90 to 1 amplification factor. You can get some amplification with any record type. You can only get the high amplification with certain types and certain practices. --Dean

Re: Trouble with Sender Authentication

Dean Anderson — 2006-11-10T17:00:37

On Fri, 10 Nov 2006, Julian Mehnle wrote: These questions happen to real businesses all the time, and don't usually represent frauds, but rather honest mistakes; mistakes that the business corrects promptly. You example doen't show any evidence that the person in that case was defrauded. Too bad. I'm sure your job isn't for your amusement. Wait.... You are handling support for a pharmacy? A genuine commerical bulk-emailing pharmacy? Yes, you forgot to mention whether the person bought a product from a CAN-SPAM compliant emailer, or using a web site not involved in bulk email, and then just had a problem with email, later. Funny that, huh? But it seems to have come from your company.... But you do have a point about there existing real frauds. However, real frauds are already crimes. SPF is not going to stop real frauds, nor real criminals. Criminals will put up SPF records. Spammers were in fact the early SPF adopters. Criminal con-artists used to (probably still do) rent storefronts, too, to appear legitimate during the con. The notion that SPF records somehow prove email legitimacy just helps promote frauds by confusing users about what defines legitimacy. I'm not saying that there aren't real frauds out there. But I am saying that the 600 spams I recieve a day mostly do not represent real frauds. Only about 70 of them represent genuine commercial bulk emailers. Practically all of the ~70 are CAN-SPAM compliant That leaves an awful lot that are neither real frauds, nor genuinely commercial. --Dean

Re: Trouble with Sender Authentication

Douglas Otis — 2006-11-10T16:58:33

On Nov 9, 2006, at 9:24 PM, John Levine wrote: Chaining CNAMEs does not offer the same distributed attack. CNAME chaining uses resources of the attacker. While CNAMEs can be a problem, they represent a threat than can be identified and handled by the affected party. The SPF attack can not be identified and there is no defense possible. I would call that a qualitative difference. -Doug