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
