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

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-T

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 v

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 htt

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 authen

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 t

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 thei

"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

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