Malcolm Weir <[EMAIL PROTECTED]> wrote: > 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.
SPF doesn't primarily use the HELO string, but the envelope from. In principle it can also be used to verify the "From:" and "Sender:" headers. > 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). For SPF to be "cracked", one would need to spoof DNS. Granted, it's some orders of magnitude harder to fake digital signatures (that are using significant key lengths) than to spoof DNS. But on the other hand, cryptography would need to be newly implemented in huge chunks of software, even in countries where digital cryptography is illegal. Sure, this might not concern us lucky ones, but given that the crypto approach is vast overkill for the problem, this seems like a very bad trade off. At least to me. I acknowledge that Yahoo is BIG and that this will give YASAF some considerable momentum. But this alone certainly doesn't make YASAF the technically superior solution against sender address forgery. But isn't that what we're arguing about here? > [...] > Sure. Now, explain why [SPF] isn't already being used universally? > Why doesn't Yahoo simply implement it? I can't. Please ask Yahoo. And please also ask them why YASAF isn't already being used universally. And why has nobody else yet implemented YASAF? > The answer is that it doesn't authenticate the message, only the > connection. This is not true. > [...] > Unfortunately, in this specific case, 'I' might have been a > "SPF-protected" disposable domain, and your user still complains to > Yahoo... http://spf.pobox.com/objections.html#throwaway > > 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! Are we debating "SPF vs. YASAF" from a "sender address forgery protection tool" point of view or from a "forensic evidence" point of view? Besides, it's technically impossible to prove anything with a copy of an alleged digital mail message. A message with an invalid digital signature can be easily forged by the suitor. Based on such bogus proof, one could sue anybody. And would hopefully fail! > > 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, Oh come on, are you talking about broken software here? What about broken software that incorrectly verifies digital signatures, or even corrupts the digital signature during transmission? Does that kind of software make YASAF technically inferior? > 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... On a trusted mail server, the oldest trusted "Received:" line cannot ever be forged. I.e. there is always at least one "Received:" line containing an unforged sender IP address which can be used for SPF verification. > > 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). Yes, blacklists may be required with SPF to avert the "disposable domain" problem. But SPF is not designed to kill spam on its own, but as a tool to protect against sender address forgery. With SPF, spammers may send from disposable domains, but they can't forge other people's domains. ------------------------------------------------------- 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_id78&alloc_id371&op=click _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
