[Top] [All Lists]

Re: rfc2821bis-03 Issue 32: "MUST take responsibility"

2007-04-30 03:11:36

Hector Santos wrote:

We can view that as a responsibility, but I see that more
like a technical requirement for the protocol itself.

As long as they don't drop mail for frivolous reasons - IIRC
a system crash is cited as an example for a frivolous reason -
I don't care if that's technical or political or both.

CBV works on the premise that SMTP mandates that the Return-
Path MUST be valid.

CBV is an odd heuristics, if both sides go to the permitted
timeout I'm not sure that it can work, in theory.  A "valid"
Return-Path doesn't imply that you can talk to the sender
while it's sending.  About 12 years ago single tasking O/S
still existed.

I'd agree that CBV is better than "odd IPs only on Tuesdays",
and it's also better than accept - spamcheck - bounce, but
it's not good enough to be mentioned in 2821bis.

The "MUST take responsibility" IMO means "I must report an
error if there's a good chance" (1 permille is a rather good
chance) "that this is legit mail".  And for obvious reasons
you cannot bounce everything, if 80% is spam with forged
return paths.

IMO the "MUST take responsibility" includes "SHOULD refuse
to take responsibility" (= reject) if something's dubious,
otherwise the receiver is trapped.  Bounces hit innocent
bystanders, dropping mail kills legit mail.  Even simple
recipes like "let's at least drop SPF FAIL silently" will
delete legit mails (e.g. from a forwarder not using SRS).

The only realistic chance is reject at the border.  What
you do later is hopeless, whatever you do, you lose.  If
you lose anyway, bounce please, maybe use a separate IP -
"MUST take responsibility" might require two IPs, one for
the bounces.