ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] DKIM on envelope level

2009-10-30 14:53:20
Ian Eiloart wrote:

There's no opportunity to do anything other than drop the connection  
there, is there? Not without modifying the SMTP spec. 


Right. Its really a non-starter unless an integrated solution is 
endorsed with an SMTP extension perhaps changing the SMTP 451 reply 
code semantics for a dropped connection or at least offers a way for 
the client to interpret a drop differently.

The only benefit  
is that you don't have to read the body into memory, but bodies are  
limited in size...


How so? You mean the socket stack buffer?  Under the Windows socket 
stack, the default is 8K.

A DKIM sig that only signed message headers would have a better chance  
of surviving mailing lists redistribution. It'd be available for re- 
use though, wouldn't it?


At different sites yes.  At the same site, you might have dupe 
checkers like a NONCE concept.

This whole idea of "patching" broken mail integrity during transports 
conflicting against the very nature of what an inherent mail integrity 
protocol provides is so odd to me.

The victims of this are remote receivers outside the "Good" protected 
channel and no protection for the #1 problem - abusive unsolicited 
public anonymous transactions.

Its would be all good if while we are looking for the golden needle in 
a haystack would be also filtering the bad or fake golden needles 
found. I simply don't see how we can cover one side and not the other. 
  This only keeps a status quo - no incentive for legacy bad goods to 
adapt. There is no need to change. Failure is ignored so why would 
anyone bother.

In the past week, we began to collect and analysis incoming DKIM mail.

So far, as expected, a large percentage is spammers and virus messages 
signed are leverage DKIM.  I saw one interesting group of signers:

   d=siouxfallsblog.net;
   d=simivalleymicroblog.com;
   d=shreveportblog.net;
   d=shreveportmicroblog.com;
   d=savannahmicroblog.com;
   d=santaclaritamicroblog.com;

all with slightly changed content blasting a "click me" virus.

No keys, domains don't exist anymore.

That is why I call it a waste if this calculation overheads offer no 
payoff.

--

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