On 9/20/10 6:35 PM, Michael Deutschmann wrote:
On Mon, 20 Sep 2010, Douglas Otis wrote:
It seems this is making two assumptions that are likely incorrect:
1) receiving domains know which mailing-lists their users have
subscribed.
Most don't. But such sites are also incapable of deploying TPA as a
sender. So that's just as good an argument for the impracticality
of TPA, as for the impracticality of except-mlist.
Domains heavily phished are in a different situation. For these
domains, there would be a strong incentive for offering third-party
information, and they are more likely to know which third-party services
are being used. An except-mlist would likely cause phishing attempts to
have List-ID headers included. With these headers not being displayed,
such an assertion would provide recipients little, if any, benefit.
2) receiving domains reliably recognize mailing-list messages.
This also hurts TPA just as much. The only defense against forgery
of lists that can only be recognized weakly (by accepting unsigned
messages from any IP that display the correct List-Id:), is not to
subscribe to such lists.
Disagree. A message not signed by DKIM therefore depends upon other
authentication methods. Within a single transaction, the TPA-Label
scheme indicates whether an authentication method should be attempted
for a domain, and whether the domain should be rejected outright without
authentication attempted.
"except-mlist" comes out slightly ahead here. Since the subscription
whitelist is consumed where it is compiled, and thus doesn't need to
be converted into a standard "language" such as TPA, it can include
ad-hoc measures such as "fake SPF records" to limit forgery of
troublesome lists.
Sorry, but I am unable to follow this. Are you suggesting receiving
domains should compile a white-list for all mailing-lists? How will
fake SPF record be helpful?
Disagree. While there are many domains offering third-party email
services, this still represents a finite dataset. In contrast,
the domains used by bad actors represent an infinite dataset.
You seem to be hinting a global whitelist of mailing lists would be
feasable -- so the domains in question could just salute one and be
done with it.
If they are happy with the results, why not?
That doesn't sound practical to me. Especially since users at such
ISPs will likely subscribe to lists that are too insecure to be put
on the GW.
Are ISPs normally phishing targets?
Insecure mailing lists in private whitelist are at least
obscure, but a global whitelist cannot tolerate a single one.
For sensitive domains, third-party services will need to be closely
monitored. A requirement to include List-ID headers, for example,
better ensures the messages will be unlikely considered something
directed to a specific person. Of course, nothing is absolute, but most
mailing-lists are normally quick to respond to abuse.
Basically, the problem is that users at such ISPs do not want
protection from forgeries *of themselves directed at others* badly
enough to make the sacrifices needed to stop that cold. Such as
dropping a non-DKIM, non-SPF mailinglist where all their best
friends hang out.
The need for the scheme is to protect domains being phished. When ISPs
find their domain is being used to phish others, there might be some
interest. IMHO, this is not an immediate problem. In addition, some
third-party services might offer extremely strong authentication methods
stipulated by the TPA-Label.
But, I want protection from forgeries *of other people directed at
me*, and the use of "dkim=unknown" or no-ADSP by those other people
hampers my ability to achieve that. I don't need them to go
whole-hog TPA, I just need help squelching the
supposedly-first-person forgeries, and I can take care of the
supposedly-via-list forgeries myself.
Preventing phishing requires comprehensive policy. Gaps in this policy
will provide little tangible benefit. Again, you are assuming you can
recognize all valid first-person and third-party exchanges? BTW, the
TPA-Label scheme is also able to secure first-person exchanges as well.
Your strategy places additional burdens on the receiver, but when they
fail in some manner, the sender is likely harmed. On the other hand,
the TPA-Label ensures those who benefit make the added effort.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html