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
POLICY:
HARDFAIL --> DKIM=DISCARDABLE
SOFTFAIL --> DKIM=ALL
NEUTRAL --> DKIM=UNKNOWN or No Record
Problem #1
Only DKIM=DISCARDABLE has an explicit handling mandate. DKIM=ALL does
not. So as in SPF=SOFTFAIL, DKIM=ALL leaves receivers in wasteful limbo.
Problem #2
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
final MDA.
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
support it.
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.
--
HLS
Rolf E. Sonneveld wrote:
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