Michael Thomas wrote:
Can anybody describe what benefit SSP would give if it chose some
other address? Other than supposedly genuflecting to RFC2822?
I thought I've done this often enough, but maybe it wasn't clear:
From: strictly(_dot_)you(_at_)an(_dot_)example
Sender: you(_at_)elsewhere(_dot_)example
This is a valid scenario, where you used your favourite address
strictly(_dot_)you(_at_)an(_dot_)example as From, protected by a strict SSP in
the
an.example domain. For reasons that are nobody's business but
your own you submitted the mail at an MSA of elsewhere.example,
and this MSA added your Sender address, implementing RFC 4409 8.1.
The unsigned (or at least not signed by an.example) mail arrives
at Alice's ssp.checker.example MTA, and for some reasons of its
own it accepts your strictly failing mail as "suspicious", ending
up in Alice's "suspicious" folder. She's used to ignore mails in
this folder because it's almost always spam, and after some days
your mail is purged => legit mail lost. Neither your nor Alice's
fault, also not the fault of 2822upd or 4409. It's SSP's fault.
Scott's argument that Alice's MUA would display From: strictly.you
for the same scenario with a malicious sender doesn't convince me:
She'd be in serious trouble if she trusts that a From header means
what it says in 2008, SSP can't rescue her from this bad idea.
MUAs trying to be smart will anyway have to learn new tricks, they
are not forced to display only the From and nothing else, they can
add a smiley for some Authentication-Results "PASS" or whatever.
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html