On Jan 17, 2008, at 5:04 AM, John L wrote:
[ corrected example ]
From: visa(_at_)visasecurity(_dot_)net (Visa Security), security(_at_)paypal(_dot_)com
(Paypal Security)
Sender: anyone(_at_)anywhere(_dot_)org
Subject: An Urgent Message from Your Friends at Paypal and Visa
But yes, if it is registered as a throwaway and doesn't publish
SSP, it will be SSP compliant (not Suspicious), presuming some DNS
record for the domain exists (at least an NS record or something).
Hopefully Visa has engaged the use of a domain registration
monitoring service to protect against this.
As I think has been hashed out before, it's utterly impossible to
keep people from creating lookalike domains. A couple of days ago,
I made the lists below of several thousand .COM domains that do and
do not belong to the Bank of America. These are just in .COM; I
didn't bother to look in .NET or .ORG or .BIZ or .INFO or any of the
hundreds of ccTLDs.
We all knew already that SSP doesn't do anything about phishing from
lookalike domains. But the first From: address rule means that SSP
is also trivially defeated for mail with the exact domain in the
From: line.
John's concern is that people will pay attention to _any_ recognizable
From email address, rather than just the first email address. This
concern should be weighed against the how multiple addresses might be
used, and what a recipient would be able conclude from a DKIM signed
indication. Multiple addresses might become legitimately more common
due to Email Address Internationalization (EAI). So allowing policy
to be established by a list of From email-addresses means the overhead
related to discovering policy needs to be multiplied by some factor of
2 or 3. SSP must avoid the mistake made by SPF expanding macros
embedded within the RR. Macros would mean subsequent transactions
permit an attack without expending resources of the attacker. Such a
scheme would be fundamentally flawed. Make a statement that an MX
record must be published by a domain wishing to establish policy.
Eventually this needs to happen when SLDs start getting hammered.
Adding more DNS overhead to processing of DKIM might cause fewer
receivers to implement DKIM. A good trade-off would be to educate
recipients that only the first email-address seen within the From
header is protected by DKIM SSP policy. The "first-author" convention
makes it easier for recipients to understand which domain governs DKIM
signature compliance. Of course, DKIM is not about identifying any
specific author of the message. Adding another From email-address to
the mix does not represent a concern about muddling the identity of
the author.
Checking SSP policies of all domains within the From header would be a
possible approach.
Cautions that might be added would be:
- Don't use macros
- Require publication of MX records (get the ball rolling to protect
SLDs)
- Allow unrestricted keys to sign any identity (allow domains to
decide what identity they wish to sign on-behalf-of)
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html