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