[dkim-dev] dkim validation software and mail lists

Hector Santos hsantos at santronics.com
Tue Sep 29 00:36:57 PDT 2009

Why not just make it simple with across the board DKIM/ADSP protocol 

     All DKIM/ADSP compliant receivers (including hops, routers, list
     servers) who see a failed ADSP condition honor the author
     domain wishes and reject/discard/etc (not deliver) it.

To begin adding subjective non-standard ideas, software change 
requirements just complicates it and reduces the confidences level for 
false/true positives.

In addition, the list server should help the process by adding to 
their respective subscription procedure a ADSP check for restrictive 
policies (DKIM=DISCARD|ALL).  Why bother allowing these restrictive 
ADSP domains to subscribe when the DKIM/ADSP compliant down links 
(MDAs) are going to reject/discard (or SHOULD) any failure from the 
mailing list?    If anything falls in place, it just going to be 
overhead for all nodes.

   - The MLS blindly allows a ADSP domain to subscribe,
   - The MLS gets a DKIM signed messages from the domain,
   - The MLS strips/destroys and resigns as a 3rd party.
   - The MLS distributes (lets assume 1000 endpoints)

You have two types of receivers:

   A) SMTP level filtering at the DATA level
   B) POST SMTP filtering (the one ADSP was designed for)

For A, the DATA is received allowing for RFC5322 header analysis, 
specifically a ADSP domain check.

           --> REJECT, REPLY CODE 550
           --> REJECT, REPLY CODE 550
           --> DATA ACCEPT, REPLY CODE 250
           --> Add Authentication-Results header header
           --> DATA ACCEPT, REJECT, REPLY CODE 250

This is a RFC 2821 compliant, socially acceptable, included US EPCA 
satisfying SMTP level mail rejection that includes a notification per 
the reply code.

For B, the DATA is always ACCEPTED and per RFC 2821 and by 30 years of 
tradition a bounce notification is par for the course for failed 
delivered.  However, RFC 5381 "cracked open" the door to allow for 
POST SMTP reception to silently "discard" mail deemed suspicious. 
Hence why ADSP has DKIM=DISCARD (not REJECT) although at the SMTP 
level DKIM=DISCARD will be interpreted at a REJECT. The difference is 
the lost of notification - conflictive with US EPCA "User 
Expectations" provisions.

In anycase, imagine the above 1000 downlinks. X amount is SMTP Level 
Rejections, Y amount is POST SMTP discards.

With the X groups, the LIST SERVER will get distribution feedback, 
allow it to eventually expire continued failures to this RCPT member - 
bad for the recipient who had nothing to do with the failed DKIM ADSP 
message, bad for list server overhead with the X number of redundant 

With the Y groups, the LIST SERVER will get no feedback and will 
continue to send bad mail to POST SMTP systems who discard the mail.
Who is the loser here?

All would of been resolved if the LIST SERVER preempted the situation 
by honoring ADSP and not accepting ADSP domain members.


Hector Santos

Daniel Black wrote:

> I've presented my thoughts on how mail list software can become DKIM friendly 
> in the previous post however for the interim the email list / ADSP 
> incompatibility still remains[1].
> A more detailed paper in progress also talks about verification associated with 
> this problem[2].
> So the problem for the verifier is that you've received an email with a invalid 
> DKIM signature and a ADSP record saying there should be one. The email is 
> either spoofed or its come through one of those mailing list programs that 
> breaks signatures. What do we do?
> As I haven't though of an automated way to do this that doesn't add a big 
> loophole for every email spoofer here's a summary of what I think could be 
> done. Simplistic checking of unsuccessful DKIM validation and deciding to 
> drop/reject a message isn't going to work so these emails need to be referred 
> to a mail filtering policy process. Successful DKIM validation can pass through 
> without this policy process.
> Generic Mail Filtering Policy Process:
> The way that I would allow users to have free control over what to do with a 
> DKIM failed message to to pass them through to a policy daemon process like 
> postfix's[3] with the Authenticated-Results[4] headers also included in the 
> interface.
> This would allow users and other programmers to quickly write a the decision 
> logic in a few lines of code. The most useful of the policy process return 
> status[5] include HOLD (for sysadmin intervention), REDIRECT (sysadmin 
> analysis in own mailbox or to user+folder as an indication of DKIM failure), 
> WARN (if testing policy), FILTER (to put "warning DKIM failure" in the message 
> before delivery) and REJECT/DISCARD (if there is a blacklist for what has been 
> presented).
> Policy WhiteBlack list:
> The policy filtering process that I would choose is:
> Extract the folllowing information from the email:
> * client_address
> * sender (note this is the envelope sender which is the list email address in 
> a form)
> * authenticated-results headers[4] especially from dkim-adsp[6]
> # We'd rather lists DKIM verified the results so we can use this as a third
> # party trust. SpamAssassin has a similar config though they allow third party
> # signatures for specified author domain signatures[7]
> FOR authenticated-header(method=dkim-adsp,from=domain(Header['From'])) AS ah
>   # database of trusted list of (ip,authserv) who's dkim-adsp/dkim
>   # Authenticated-headers we trust. Use DKIM validation of list domain as
>   # alternate to IP
>   SELECT _ip,_authserv FROM dkimahtrust WHERE _authserv=ah->authserv-id
>   IF _ip=client_address OR authenticated-
> header(method=dkim,d=domain(sender),result=pass,authservid=us)
>      SWITCH ah->results
>      CASE nxdomain)
>         # assume since no DKIM-ADSP result we'll base our accept on DKIM-
> Signature
>         IF (authenticated-header(authserv-
> id=_authsev,method=dkim,result=pass,i=Header['From'],subdomain(domain(i),d))
>              RETURN ACCEPT
>         ENDIF
>      CASE discard) RETURN REJECT
> NEXT  
> # here we have a (sender,ip) whitelist and blacklist
> SELECT _ip,_sender,_bwtype FROM dkimdb WHERE _ip=client_address AND 
> sender=_sender
> # hope its not in both
>   IF _bwtype='white' RETURN ACCEPT
>   ELSE IF _bwtype='black RETURN REJECT
> # no rules match - 
> now present admin with easy email/web interface to whitelist, blacklist this 
> entry based on the headers present and release/drop this email to its original 
> recipient.
> For list owners:
> DKIM validate email in and add a authenticated header
> optionally reject DKIM failed messages
> Add a DKIM-Signature of email you pass out
> This makes it easier for the receiving domain to filter bad messages based on 
> your assertions.
> [1] http://mipassoc.org/pipermail/dkim-dev/2009-September/000202.html
> [2] https://community.cacert.org/dkim/
> [3] http://www.postfix.org/SMTPD_POLICY_README.html
> [4] http://tools.ietf.org/html/rfc5451
> [5] http://www.postfix.org/access.5.html
> [6] http://tools.ietf.org/html/rfc5617#section-5.4
> [7] 
> http://spamassassin.apache.org/full/3.2.x/doc/Mail_SpamAssassin_Plugin_DKIM.html
> ------------------------------------------------------------------------
> _______________________________________________
> dkim-dev mailing list
> dkim-dev at mipassoc.org
> http://mipassoc.org/mailman/listinfo/dkim-dev

More information about the dkim-dev mailing list