Steve Atkins wrote:
On Oct 28, 2009, at 4:19 PM, 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
You're asking the SMTP peer to prove interactively that they have access
to a DKIM private key ...
8. If the verification fails: continue as if there had been no DKIM
extension at all (just like the SMTP dialogue is done now)
... if they can't do so, you accept the entire email ...
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.
... if they can do so, you accept the entire email.
In either case you accept the entire email,
Not necessarily. Many if not most Edge ADMD MTA's perform all sorts of
actions after the MAIL FROM phase and before the DATA phase. Think of
greylisting, call back verification, use of RHSBL, use of local BL and
WL's, etc. etc. The outcome of a 'dkim=pass' result can be used to make
other decisions with respect to these actions, or to give another
'weight' to the outcome of such an action.
which gives you everything
you need to confirm that the sender has access to the DKIM private
key, just by verifying the DKIM token.
This seems to provide you with no additional information in either
case.
Please let me know if this is something to explore further, or whether
it is a complete non-starter. Looking forward to your comments.
Probably a non-starter. You'd need to come up with some benefit
for using it before looking into the details. On the surface it doesn't
appear to have any.
Also, anything that doesn't support store and forward is going to
be a hard sell.
I'm not sure about that. Look at SPF; in the real world situation it's
only useful in a one-hop situation and yet half of the Internet is
publishing SPF information. If (repeat: if) verification of the MAIL
FROM would have some added value, then it might be worth the effort even
if only part of all SMTP communications are covered. BTW: are there any
figures about (on average) the number of multi-hop SMTP sessions versus
the number of single-hop sessions? Is it 50%? 60%? 70%?
If you're just doing authentication over one hop
then you could use the existing AUTH keywords that support SASL,
That's an interesting idea!, although I see a lot of problems here...
/rolf
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html