ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] "third party signing" != "mailing list problem"

2010-09-20 22:48:44
On Mon, 20 Sep 2010, Douglas Otis wrote:
Domains heavily phished are in a different situation.  For these
And nothing stops them from using full TPA, if they are willing to pay the
price.  But for most other domains, it's either except-mlist or unknown.

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.

TPA doesn't create authentication methods -- it documents whatever the
list already has.  If a list does not sign, and does not have a
predictable and SPF-protected MAIL FROM:, TPA cannot help.

If the list is "TPA-able", and the receiver site knows enough about it to
construct the TPA records, they can do just as strong verification.

Sorry, but I am unable to follow this.  Are you suggesting receiving
domains should compile a white-list for all mailing-lists?
Only in the same way that TPA constitutes the sender compiling a
white-list.

How will fake SPF record be helpful?
I'm referring to the technique of, faced with an entity one wishes to
whitelist with no SPF record, constructing a best guess (based on past
behavior) as to what its correct SPF record would have been.  Then pointing
one's SPF validator at the fake record so long as the official result remains
"none".

Unacceptable false positive risk in my view, but it's hard for a forger
to beat.

 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?
If they don't cover every list their clients use, recipients will disable
incoming DKIM filtering to avoid false positives.  Everyone loses.

Are ISPs normally phishing targets?
They aren't, but that doesn't mean I want to see messages forged to be
from their users.

---- Michael Deutschmann <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>