Hi,
excuse me if this has been discussed before; I was wondering whether
there has ever been discussion about the usefulness, possibilities,
caveats etc. of applying DKIM on the SMTP envelope level. I could not
find an exact reference in the archives of the list; the closest I could
find is a thread with subject "Signalling DKIM support before DATA" back
in August 2006. The idea I had in mind is somewhat different from what
was discussed in that thread: in August 2006 the discussion was about
signalling during the SMTP dialogue that the header of the
message-to-be-transmitted will carry a DKIM signature. What I'd like to
discuss (if this has not been done before) is about using DKIM to
authenticate the MAIL FROM address/domain.
Idea:
1. SMTP client connects to SMTP server
2. SMTP server sends banner
3. SMTP client starts with EHLO
4. SMTP server answers with list of EHLO keywords
New: EHLO keyword DKIM, which consists of the word DKIM followed
by a unique random sequence generated by SMTP server, e.g.
250-DKIM 1F64GH996u3YzzXp
5. If the SMTP client (Edge ADMD MTA) is owner of the MAIL FROM
domain and detects DKIM SMTP extension support:
SMTP client uses private DKIM key + MAIL FROM domain (or MAIL FROM
complete address) + unique random sequence generated by the SMTP
server and advertised with the DKIM EHLO keyword to generate a
hash / signature
6. SMTP client then sends 'MAIL FROM' with envelope From address +
the above generated hash / signature
This will require an extension to the MAIL FROM definition.
Something like:
MAIL FROM:<user(_at_)domainname> DKIM=some_hash_value
7. SMTP server will use sender's public DKIM key + Envelope From
information + unique random sequence to verify this hash / signature
8. If the verification fails: continue as if there had been no DKIM
extension at all (just like the SMTP dialogue is done now)
9. If the verification is succesful, the SMTP server can use the
result for additional actions, along the lines of paragraphs 6.2
and 6.3 of RFC4871. The advantage here is that we've not yet
entered the DATA phase.
There are some variants possible like:
a) use MAIL FROM domain or MAIL FROM entire envelope From address
b) make it a per-recipient service, by applying this DKIM extension to
the RCPT TO, so selectively apply it for some RCPT TO addresses and do
not apply it to other RCPT TO addresses. Compute the hash / signature
over MAIL FROM + RCPT TO + Unique random sequence. This might introduce
some serious complications, not to speak of the extra CPU power required
to compute all those hashes (if there are many recipients in the SMTP
session)
c) as an alternative to the the unique random sequence, have the SMTP
server side publish a DKIM public key in DNS. Use public/private pair to
sign (SMTP client) and verify (SMTP server)
Is there a use case for b)?
Replay is not possible?
Has c) never been considered before?
I'm pretty sure these things must have been discussed before many times
and I don't want to go round in circles, so please tell me if this has
been discusses before.
I see quite clear a number of limitations to the above proposal:
* the above will (if it works) only work for single-hop SMTP
connections from one Edge ADMD MTA to another Edge ADMD MTA.
* hence, the net result of the above is somewhat equivalent to what
can be achieved by SPF. So is it worth the effort?
Yet I'm curious to see what the differences with SPF are (there
are some differences, as SPF is 'validating' IP addresses and DKIM
in the above scenario is validating MAIL FROM) and whether the
above has any advantages over SPF or not at all
* when messages transfer multiple hops and/or are redistributed by a
mailing list or forwarded (alumni), DKIM on the envelope level as
described above will not work/help. Are there any figures about
the percentage of all SMTP connections which are 'direct' versus
'multi-hop'?
* the above will require a new SMTP extension. This means it may
take a long time before a significant part of all Edge MTA's will
have implemented it, it they will ever implement it.
Please let me know if this is something to explore further, or whether
it is a complete non-starter. Looking forward to your comments.
/rolf
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html