Mark Lentczner wrote:
Yes - Sender-ID no longer directly combats bounce attacks.
[...]
when I discuss my work with anyone, bounce attacks are at
the bottom of the pile of spam concerns.
Then your situation must be very different from my situation:
More than 1,000 useless bounces to forged addresses per day
in my catch-all (vanity) domain are the main reason why I'm
interested in RMX resp. later SPF.
If Sender-Id / Submitter want to be incompatible with v=spf1
then they should use another tag v=marid or similar.
No 3rd party should be able to force a SPF PASS, where I could
get the bounce for a mail not sent by "me" (= any customer of
the same ISP in this case). Apparently a Sender-Id PASS does
not more guarantee this.
And of course I don't want to get a Sender-Id FAIL instead of
a SPF UNKNOWN only because legacy software doesn't copy the
obvious MAIL FROM address to an equivalent Sender: header.
If some MUAs really want this they could handle the MAIL FROM
address as default Sender: address.
neither Sender-ID, CSV, nor original SPF will stop phishing
directly
As soon as I know the domains of my business partners SPF can
catch phishing attempts:
amazon.de TEXT = "v=spf1 include:amazon.com -all" and SPF are
all I need to identify forged amazon mails.
[...]
only if MUAs present the information in a way that users can
understand.
At the moment that's easy, anything in the headers is forged.
Only the IP in the last Received header is reliable. SPF adds
the Return-Path. In theory Sender-Id could add its "PRA", but
in practice Sender-Id expects that senders (MUAs resp. MSAs)
replace their existing software to copy the MAIL FROM to the
(missing) Sender: header.
But it's the MUA of the _recipient_ who wants to do something
with the "PRA", so why doesn't it handle the Return-Path: as
default Sender: address ? As long as that's not the case my
v=spf1 sender policy is strictly incompatible with Sender-Id,
because it doesn't cover my usage of 2822 From: addresses.
Bye, Frank