> -----Original Message----- > From: Julian Mehnle > Sent: Tuesday, January 06, 2004 3:08 PM
[ Snip ] > > As each message is injected into the "public" internet by a SMTP > > server, that message is signed with a private key controlled by > > whoever owns the injecting domain. > > > > From that point on, anyone can query the DNS for that > domain and get a > > public key; if the public key doesn't "unlock" the message, it > > *is* forged, > > and can be immediately dropped. SPF can only suggest that > it might be > > forged, and use that information to feed into subsequent filters; > > Yahoo's scheme is authoritative. Further, using SPF every stage > > (relaying or forwarding) must provide SPF sender verification > > otherwise there is no benefit. Using Yahoo's crypto > scheme, you can > > copy the message onto a floppy disk and hand carry it around and at > > the other end you can still authenticate the message. > > I don't see what SPF does NOT do (to prevent sender domain > forgery) that IS being done by YASAF. SPF only validates that the host that claims to be on the other end of the SMTP connection is the 'correct' host (or a correct host) for that domain. In most cases (see Sam's remarks) YASAF validates that the 'From:' line is being used legitimately. Still, the main thing that YASAF *does* is based on the fact that it is sponsored by Yahoo who is one of the major e-mail domains out there, while SPF is sponsored by more-or-less no-one. SPF may be acceptable, but any fair assessment will acknowledge that the use of crypto signatures *is* a harder nut to crack when it comes to forgeries, so YASAF can be viewed as SPF++ (the first plus for the crypto, the second for the sponsor). > SPF, for a given domain, prevents rogue SMTP servers, that > are unauthorized to send "from" that domain, from delivering > mails to an SPF-protected server. You as a domain owner can > even authorize 3rd party servers (like your ISP's ones) to > send mail "from" your domain. Sure. Now, explain why it isn't already being used universally? Why doesn't Yahoo simply implement it? The answer is that it doesn't authenticate the message, only the connection. If your SMTP server decides that mine is authentic (in the SPF sense), then I can shovel a message to you that appears to have been relayed from (say) a Yahoo domain. You'll add another 'Received-From:' header, and deliver it to your user. Unfortunately, in this specific case, 'I' might have been a "SPF-protected" disposable domain, and your user still complains to Yahoo... > The "you can carry a YASAF-protected mail on a floppy disk > and still verify its sender domain's authenticity" argument > is bogus. No, it's entirely valid, and covers one of the key issues. Note that SPF can only be employed during SMTP dialogs; 'YASAF' can be employed even by an MUA's during a POP3 dialog... And the old POP3 (and IMAP and SMTP) server(s)s can be entirely ignorant of the whole issue while the user gains the benefits! > Why would you actually want to perform the > verification anytime *after* the mail has been received by > your "side" in the first place? Because you are Yahoo's support department and, to borrow Sam's example, you are fed up with responding to people complaining about mail received from '[EMAIL PROTECTED]'. In this case, the forwarded message (or the message carried on a floppy) is self-contained from the standpoint of its signature, and it can be subsequently proven (say, in a court of law) that it is a forgery. This may be rather important if you are being sued for sending UCE... As may now be the case! Secondly, as suggested earlier, your 'side' may be using a old SMTP package, but your MUA is cutting edge and is smart enough to discard invalid 'YASAF' messages during the download. > For reliability's sake (from > a legitimate sender's point of view), you'd want to reject > invalid mails right in the SMTP dialog anyway instead of just > dropping mails or even generating concrete bounce messages. That's debatable. If you are sending legitimately with a signature, all is well. If you are sending *without* a signature where you 'should' have one, it can be argued that you are sending a forgery, and a rejection provides the forger with additional information -- that may be good, or not, depending on whether you choose to argue that it is better to permit forgers to hone their mailing lists, or whether it is better to allow the forgers to bloat their lists so as to increase the overall cost. Sure, from a "good citizen" standpoint you are right... But from an anti-spam standpoint the issue is slightly more complex (I personally would love for the largest ISPs to silently drop forged mail, for precisely this reason). > And even if there were a real reason to perform "late" > verification, you could do the same with SPF. Just check the > delivering IP address in the apropriate "Received:" header > (i.e. the oldest header you trust). No, because once the connection has been closed, the headers are vulnerable to being rewritten. Sure, *most* MTA's behave well, but some clearly don't, and if you are willing to forge a 'From:' line, one must acknowledge that forging a 'Received:' line is certainly possible. Forging a crypto key is rather harder... > Why can SPF only "suggest" that a sender address is forged? > What's the difference from YASAF in this regard? SPF validates that the connection came from the place it claims to have come from. It doesn't validate that the origination is is valid for an address. Further processing is required to discover if the validated connection is associated with a problematic source (e.g. checks against blacklists). > Further, the YASAF private keys can't be handed out to users > for them to sign their messages themselves (and use whatever > SMTP relay they want), or to other untrusted 3rd parties. > This means that users are required to use SMTP servers that > have access to the private key, which will usually be the > domain owner's trusted servers only. This in turn means that > YASAF prevents domain owners from authorizing (untrusted) 3rd > party servers to send mail from their domain, while SPF does > support this. I wrote extensively about this precise issue, and how it can be solved. However, I think Roger did a *much* better job! Basically, you acknowledge that there may be two signatures: one that 'signs' as the originating SMTP server, and one that might optionally be added by the originating MUA. If the SMTP signature fails, check for the second signature and see if that works. And then, of course, you'll have to decide if the second signature matches a domain that you're prepared to believe is not a disposable one... > SPF's concept is most natural, as it basically represents the > reverse of the DNS MX record type, plus it brings some > extensions. I don't see why this is not enough to > effectively prevent sender address forgery. Consider the logs you'll have to retain to prove that when someone sues you for sending them UCE. Yahoo's scheme is self-contained: if the purported spam has an invalid SMTP signature, it didn't come from Yahoo, and vice versa, and that's the end of it. Malc. ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
