Why not just make it simple with across the board DKIM/ADSP protocol
consistency?
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.
Test #1 DKIM=DISCARD|ALL, NO SIGNATURE
--> REJECT, REPLY CODE 550
Test #2 DKIM=DISCARD|ALL, INVALID SIGNATURE
--> REJECT, REPLY CODE 550
Test #3 DKIM=UNKNOWN, NO SIGNATURE
--> DATA ACCEPT, REPLY CODE 250
Test #4 DKIM=UNKNOWN, INVALID SIGNATURE
--> 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
rejects.
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.
--
Sincerely
Hector Santos
http://www.santronics.com
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 pass) RETURN ACCEPT
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
ELSE RETURN REJECT
ENDIF
CASE fail) RETURN REJECT
CASE discard) RETURN REJECT
ENDIF
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 FOUND
IF _bwtype='white' RETURN ACCEPT
ELSE IF _bwtype='black RETURN REJECT
ENDIF
# 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(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-dev
_______________________________________________
dkim-dev mailing list
dkim-dev(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-dev