ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] DKIM on envelope level

2009-11-02 14:08:27
On 11/2/09 4:45 AM, Eliot Lear wrote:
On 11/2/09 12:20 PM, Ian Eiloart wrote:
--On 30 October 2009 19:52:54 +0100 Eliot Lear<lear(_at_)cisco(_dot_)com>  
wrote:

I can't say, but I do know that many of us toss a whole lot of mail at
EHLO, some at MAIL FROM:<>  and some at DATA.  The idea I was thinking
about was whether it provides any value whatsoever to at least know that
you are authentically dealing with a legitimate source sooner, without
having to send even a whole header.

Yes it would help, but probably not more than an SPF pass would help.
What do you get from that? Well, you can check the reputation of the
MAIL FROM address.

Well now we're quibbling about how to check the MAIL FROM address.  I'm
still interested in an end-to-end approach.  SPF doesn't give you
end-to-end.  A legitimate intermediate could have been compromised, for
instance.  MAIL FROM *does* change for mailing lists, of course, but
then they should re-sign anyway.  Of course, I'm still not sure this is
worth the effort to fix because SPF could be Just Good Enough for the
1st pass, and then DKIM can be used on the body.  Same argument seems to
apply to STARTTLS, although I would imagine that the latter has more of
a hit on the CPU.

Agreed. SPF is not end-to-end. IMHO, hostname assessments should occur 
independently, where post processing of logs is used to create a history 
for every hostname received.  A hostname IP address tuple should be 
tracked upon receipt of valid messages (such as DKIM) from trusted 
domains.  When pruned to trusted domains, the data is kept rather small. 
  It would be beneficial to have a simple scheme with low overhead that 
allowed the extension of a trusted domain list, where one domain 
signifies trust in another domain.  Gaming of the system would need to 
be monitored and reported, of course.

This approach would enable rejection of abusive email early within the 
exchange without any modification to SMTP or DKIM, which would also help 
those with smaller networks.  By employing aggressive, and perhaps 
longish term rate limiting, this approach can be effective against 
bot-net generated traffic and against providers who setup junk outbound 
servers to avoiding being the entity rejecting traffic, and thereby 
avoid some of the related support calls.  An extensive trust list 
together with SMTP hostname assessment can provide better information 
than that from IP address reputation alone, and provide a way forward 
for IPv6.

-Doug
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>