Julian Mehnle wrote:
To be a good spam trap, a spam trap needs to look just like
any other e-mail address in every regard
[...]
Well, they didn't accept my proposal to add a FAIL policy. And
without FAIL if somebody (ab)uses its allegedly secret address
in a forged MAIL FROM it will get bogus bounces.
It's a chicken and egg problem: If you think that absolutely
no bogus bounce is ever necessary, then the 11% misdirected
bounces in reality are a configuration error, and among other
things implementing SPF is pointless, just never bounce and
be done with it.
But I think that SPF is necessary to get this right for some
corner cases, many recipients with one of them over quota etc.
Or the infamous outsourced backup MX unable to do call forward
verification while the primary is down: The best it can do is
block aggressively. For new spam sources it will accept some
mails, and later find that this was a dubious idea. Drop is
wrong, delivery is wrong, bounce is wrong, and "net suicide"
is not published as RFC, but draft-church-dnsbl-harmful-01.txt
in the RFC editor queue goes in that direction. </joke>
IMHO spam traps should have a FAIL policy, otherwise they will
just force some senders to reserve an IP for dubious bounces,
where it doesn't matter if that IP is blacklisted.
Ball back in play at the sender's side: If this was a legit
mail with only a typo in the local part of the receiver, or
the mailbox of the receiver over quota, it will be bounced as
it should, but the bounce comes from the blocked IP, and so it
will never make it to the legit sender, and we have precisely
the situation SMTP as specified in (2)821 tries to avoid at all
costs: Legit mails vanishing without notice in black holes.
SMTP is IMHO far too simple to survive without error messages,
it just needs SPF to work as designed.
"v=spf1 -all" may be an _indication_ for a spam trap address,
though, but nothing more.
Apparently that's what they fear. The problem is that they
don't publish a FAIL policy, catching (dubious) bounces from
(otherwise) well-behaved servers. Stuart's customer rejects
FAIL as explained here, to some degree they're a part of the
solution.
The spamtrap without FAIL policy on the other hand is a part
of the problem. It can't work if everybody follows a complex
ritual, which in essence boils down to "dev-nulling" bounces...
Never ever send DSNs to unauthenticated return-path
...I certainly hope that we get to this point using SPF PASS
or FAIL. But we're not yet there, it's a transitional phase,
and good actors are confronted with NONE / NEUTRAL mails from
unknown strangers.
If what you have in mind is "dropping NONE / NEUTRAL is okay",
then I'm not sure how that will end.
Frank
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com