see that might need some discussion is the inclusion of Packet Switches in
the same category as User Mediators (section 2.2.3).
I've added some clarifying language, for the next version.
at http://www.ece.arizona.edu/~edatools/etc/Email_Authentication_01.htm ;
use of the unqualified term "sender" is usually ambiguous, at best. There are
at least 4 different interpretations of that term, and each has significantly
different semantics:
RFC2822.From
RFC2822.Sender
RFC2821.MailFrom
RFC2821.HELO/EHLO
All are nearly 100% effective in stopping the kind of forgery now prevalent
Probably not.
Validating any of those fields is going to do remarkably little to deal with
actual Phishing, because the social engineering techniques for phishing are
very clever at deceiving readers, with close approximations of correct, branded
names, and with deceptive of false content.
SPF and SenderID authenticate just the domain name.
this paragraph needs to hammer home the different identities (fields) each
scheme authenticates.
This requires more computation
1) the computation overhead appears to be insignificant or, relative to overall
mail processing costs.
2) Except in the simplest scenarios, path registration schemes, like SPF and
Sender-ID, incur significant, long-term administrative costs, by having to keep
the linkage between mta-level IP addresses, with user-level domain names.
may be necessary in high-security situations
Sorry, no. Domain Keys and Identified Internet Mail are not intended for 'high
security'. In fact they take advantage of the much lower security requirements
for transit-time domain-only authentication.
These schemes do not incur any path dependencies and they are based on the
fingerprint of the content, providing robustness against man-in-the-middle
attacks. Those are their major benefits.
SPF and SenderID work by tying a temporary IP address to a relatively
permanent and reputable domain name
Nicely written. It the transient nature of IP addresses is a major difficulty
with having to correlate them with user-level identities.
Every incoming email has an IP address that cannot be forged {1}
Actually, IP Address spoofing is already a problem. Spammers are stealling
portions of IP Address space.
It is probably ok to continue to use IP Addresses for authentication activities
that are not mission critical, such as transit-time testing, but it is not
appropriate to use it for more than that.
The methods differ in which of these names to use as the sender's domain
name.
hmmm. well, ok. but this needs to go at the beginning. i also think that
using a single term to cover all the different semantics is confusing. The MTA
is one-hop sender and the author is another kind of sender. But the
differences between them are so large as to make the single term "sender"
pretty meaningless.
what cannot be faked is a domain name held by a DNS server for that section
of the Internet {2}
Unfortunately, this is not correct. There are well known attacks on the DNS
possible. Until DNSSec is in widespread use, again the information in the DNS
must be used with limited trust.
Is there any work yet on a standard for how Mediators should handle
authentication of the sender ( SRS, Resent-From, ???) ? Seems to me a
A simple rule for any intermediary is that if is breaks the authentication
information, it is responsible for re-creating it. With rare exception, this
means that a Mediator must re-sign or re-register the message.
d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net