ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] DKIM on envelope level

2009-10-29 13:32:18


--On 29 October 2009 12:18:07 -0400 hector 
<gmail(_dot_)sant9442(_at_)winserver(_dot_)com> 
wrote:
Problem #1

Only DKIM=DISCARDABLE has an explicit handling mandate.  DKIM=ALL does
not.  So as in SPF=SOFTFAIL, DKIM=ALL leaves receivers in wasteful
limbo.

No, they don't. They both provide useful information. For example, we
provide very limited whitelisting which requires that senders get an SPF
pass - to get on our whitelist, senders have to publish SPF records. The
skip some of our checks when they send mail from the right sender to the
right recipient through an SPF protected channel, but not otherwise.

DKIM=all gives me useful information, too. If I seem mail from such a
domain, without a signature, and can't see that it's taken a path that
might have broken a signature, then I know to treat the mail with
suspicion. I won't discard it, but I might reject it at SMTP time.



How do you handle the anonymous domain (NOT IN YOUR WHITELIST) DKIM=ALL
mail sender with:

    A) No signature
    B) invalid signature

w/o SPF records?

Well, you don't apply any positive reputation scores that you may have for 
the domain. Good senders will want you to do that, so they'll be encouraged 
to use the protected channels. Some day, all mail will be sent through 
protected channels...

Better question, how do OTHER SITES handle the same domain you have 
protected?

DKIM=ALL is very much like RFC 4871 t=y problem where we took note of its
potential abuse and stated:

    t=y

    This domain is testing DKIM.  Verifiers MUST NOT treat
    messages from signers in testing mode differently from
    unsigned email, even should the signature fail to verify.
    Verifiers MAY wish to track testing mode results to assist
    the signer.

In general, DKIM=ALL, in the same way SPF=SOFTFAIL has proven, is a waste
for general wide adoption.

It's not a waste. However, the value will increase with (a) increased 
uptake, and (b) domain based reputation infrastructure. My own whitelists 
are an example of that, but a shared reputation infrastructure (either open 
or commercial) will be more useful.

It does have to be coupled with other things, but perpetual failures
remains to be a problem for MOST receivers who are not privy to such
special whitelist information.  The end result is to ignore it because
you don't have information about the anonymous sender.

Heuristics (Content Analysis) has to be applied to such things. Was it a
spam? Was it a virus? etc, and then you begin to couple it with some
tolerance factor.

Are you saying?

    If SPF is softfail and DKIM=ALL also a failure and I
    don't know who is it is, but I see it is really
    a spam/virus, then we reject it and optimize future
    SPF/DKIM failure detections by rejecting it immediately
    and hopefully by not requiring to accept it.

Maybe if the suggestion that we do this and couple it with a "neural
network" where we teach participating nodes of the neural net to learn
from each other, then maybe we have something to work with.

Until that happens, DKIM=ALL is a public gateway for anonymous abuse at a
huge market of random sites that has all the same markings of a Cry Wolf
syndrome - people will begin ignore the failures just like they do now.

--
HLS

Iane(_at_)sussex(_dot_)ac(_dot_)uk wrote:

--On 29 October 2009 08:53:36 -0400 hector
<gmail(_dot_)sant9442(_at_)winserver(_dot_)com>  wrote:





-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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