Alex van den Bogaerdt wrote:
[MAIL FROM:<@spam.example.net:fake(_at_)innocent(_dot_)example>]
Now implement a black list for spam.example.net and you
still reject the message.
Okay, so this allows to use RHSBLs for domains supporting SPF.
But this may take years, and I wanted the useless bounces to
stop this year.
The whole idea of SPF is IMNSHO responsibility. If in this
case spam.example.net forwards my mail (or pretends to do
this), then bounces should go to spam.example.net
If I still get the bounces then SPF would be a complete waste
of time for me. The IP used by spam.example.net isn't allowed
to send any mail resulting in a direct bounce to me.
This black list works _because_ you have verified the sender.
In Seth's example it doesn't work for me, I still get bounces
despite of my SPF (let's assume that I can convince my ISP to
add the missing wildcard record for his vanity hosts).
The spammer has two options:
1) lie through teeth -> you reject, due to spoofing
2) speak the truth -> you reject, due to black listing
No, not me, I'm on the other side of it (the forged sender =
recipient of the bounces). The idea of SPF is AFAIK, that I
can define IPs allowed to send mail from xyzzy, and therefore
any recipient supporting SPF can reject mail from other IPs
abusing my address. No blocklist needed, the spammer can do
whatever he wants, I won't get bounces from these recipients.
In Seth's example I'd get again bounces, unless the recipient
uses a blocklist. But any procedure based on "the recipient
uses a blocklist" is again the pre-SPF situation, with the
minor difference that RHSBLs might work in addition to DNSBLs.
And spammers need seconds and cents to create fresh domains
like spam.example.net, and therefore RHSBLs won't help much.
They already do this today, one spamvertized domain per run.
Adding a dummy domain with "v=spf1 +all" (or something less
obvious) to forge forwarding is no problem.
Bye, Frank