"Jim Lyon" commented:
This thread has devolved into a fascinating discussion of arcane points
of British law, but it misses the fundamental point:
A reasonable use of SenderID is to use it at SMTP time, and to refuse to
accept forged mail. If you refuse to accept it (by giving an error at
end of DATA), you won't generate a bounce. The MTA that was sending the
mail might or might not generate a bounce, but that's his problem, not
yours.
I beg to differ.
I am the one who has discovered that I am being offered a forgery. If I reject
at SMTP time and a bounce is generated it is my responsibility, my karma. I
knew full well that his machine may send a bounce, and include the malicious
content.
It is my decision, my responsibility, regardless of how the technology works.
If we had on offer a Mail-From test (with HELO/EHLO where needed) and new SMTP
semantics that said we MAY/SHOULD/MUST discard the message (with no bounce) if
the Mail-From test fails, then I would be satisfied.
In fact, most of the forged mail is sent by specialized spam engines or
virus propagation engines. These engines won't generate bounces,
they'll just give up and go on to the next victim.
That may be true, but I'm concerned about everything that may happen, not just
'most'.
So, deploying SenderID should result in fewer bounces, not more.
And incorporating the tests & semantics developed in SPF would result in even
fewer bounces - and totally eliminate the situations which concern me.
-- Jim Lyon
Chris Haynes