[ietf-dkim] DKIM on envelope level
gmail.sant9442 at winserver.com
Thu Oct 29 05:53:36 PDT 2009
Overall, beside the issues with the technical merits and higher
complexity and C/S code dependency of your proposal, you are
attempting to address something that is already addressed. The
problem isn't really single hop direct mail transactions.
The problematic issue is multi-hop operations. Thats the problem.
There is no acceptable solution on the table to protect against DKIM
ready multi-hop, forwarders and/or mailing list servers interfering
with 1st party DKIM signature protection and the proposed solution,
RFC 5617 POLICY, is intentional ignored because to follow it, breaks
the multi-hops operations.
In short. SPF has policies like the following that are similar to DKIM
HARDFAIL --> DKIM=DISCARDABLE
SOFTFAIL --> DKIM=ALL
NEUTRAL --> DKIM=UNKNOWN or No Record
Only DKIM=DISCARDABLE has an explicit handling mandate. DKIM=ALL does
not. So as in SPF=SOFTFAIL, DKIM=ALL leaves receivers in wasteful limbo.
Currently, the list server implementations are ignoring RFC 5617 some
before of legacy issues, others intentionally, like gmail.com and
mipassoc.org (this list). So even if checked at the edge MSA, the
internal forwarders and remailers are ignoring the possibility of ADSP
protected domain, breaking the integrity, resigning, removing any 1st
party signature and forwarding the mail. This will conflict with the
So even if your proposal attempts to address this multi-hop issue,
which it does not, it won't work unless remailers and forwarders also
This is the somewhat the same issue with SPF forwarders. However SPF
does have a optional solution - EHLO/HELO domain SPF checking.
Something similar is needed for DKIM.
But again, if the integrated software logic doesn't fit, and the
remailers continue to not support the initial submission checking and
filter ADSP domains, then we will continue to have the same multi-hop
issues until another solution is proposed.
Keep in mind even a reputation proposals doesn't work if remailers are
exempt from checking the initial submissions as well.
In fact Super Idea XYZ will not work if remailers are exempt.
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.
> Please let me know if this is something to explore further, or whether
> it is a complete non-starter. Looking forward to your comments.
More information about the ietf-dkim