[ietf-dkim] "third party signing" != "mailing list problem"
dotis at mail-abuse.org
Mon Sep 20 19:49:29 PDT 2010
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
> "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.
More information about the ietf-dkim