[ietf-dkim] DKIM on envelope level
dotis at mail-abuse.org
Wed Oct 28 17:18:50 PDT 2009
On 10/28/09 4:19 PM, Rolf E. Sonneveld wrote:
> 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.
> 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
> 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
> * 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.
Review the draft:
This draft describes a mechanism that is able to relate various message
elements, such as Mail-From, SMTP client, DKIM signatures, and Author
domain with different domains. It was intended to be used to authorize
third-party signing domains, but could also affirm Mail From addresses
As outbound mail servers become more widely shared among various
interests, being able to affirm mail by names used in various
originating elements could offer greater assurance of message
acceptance. Provided of course the name is associated with good
stewardship. In other words, this could establish an alternative to
reputations based upon IP addresses.
More information about the ietf-dkim