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

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 f

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 p

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

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 b

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 complian

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

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

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

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

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, t

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