Matthew Elvey wrote:
You're not supposed to see any forged (= SPF FAIL) Return-Path in a
post-SMTP scenario.
Perhaps.... This is the case for folks who are under the illusion
that SPF FAIL is a reliable indicator that the mail is forged, and
hence are willing to bit-bucket it. It's also the case for folks
who think it's reliable ENOUGH.
It's no illusion, it's the definition, and senders know that it can't
work reliably (if at all) if SPF is checked behind the border-MX. In
that case it results in a "551 user not local" emulation, good enough.
An illusion would be any attempt to do something else than "reject",
any "annotations" or scoring in already invalid constellations could
cause losses of legit mails.
The sender can't control how is mail is forwarded
Yes, it's up to the receiver to get this right. Either using a pure
STD 10 network with working reverse paths, or rewriting the MAIL FROM
in other appropriate ways, as done for mailing lists. Or white list
the forwarder. Or accept this odd 551-emulation, like the sender did:
It would be stupid to publish a FAIL policy without accepting this
consequence...
legit mail can be marked SPF FAIL.
...not if it's recjeted. With SMTP any "annotation" or "marking" is
the dangerous choice, rejecting is much cleaner. I thought that your
article here was about this difference.
But, I said email authentication, not SPF, intentionally.
With an SPF PASS you got the plea to procede as specified, reporting
errors "to the originator as indicated in the reverse path", a later
bounce cannot hit innocent bystanders. And after a FAIL it will hit
innocent bystanders. There are no other ways to figure that out.
After all RFC 1123 5.3.6(a) is an ordinary bug, even if it's the
most expensive bug in technical standards I've heard of. And its
latency (more than a decade) is also impressive.
[SIEVE not used for spam filtering]
It was said at the meeting, IIRC, which is archived. I don't have
a timestamp; sometime after 2:46:50
http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf67/ietf67ch2-mon-pm.mp3
No sound card on my box, tough. IMO a statement in that direction
would be weird, unless there was a qualifier like "not solely".
Most SC NG activists (excl. me) insist on a concept where "reject"
behind the border is _always_ wrong. IMO that's a delusion, many
late rejects are avoidable, but not all.
The more serious delusion is that reject behind the border is just
fine.
Yes, unfortunately the 2821 proposal isn't clear enough about that
for many readers. Its "originator as indicated by the reverse path"
blurb fails miserably when the default state of this "indicator"
today is "forged". Naive interpretations only work after something
like an SPF PASS at the border. Also true for RFC 3834 and MDNs.
I'm here trying to enlist help to make that illusion disappear
among Sieve implementers.
You've posted a link to a recent thread here: With folks like Alexey,
Arnt, Ned, and Ken I'm confident that they won't blindly believe in
any dubious "originator as indicated by the reverse path" illusions.
http://thread.gmane.org/gmane.ietf.mta-filters/3328/focus=3328
Of course MDNs are bad, Arnt answered that in this thread.
Well, that's nice and all, but the folks on the ietf-mta-filters
list still think it's dandy; they didn't hear his arguments, or
yours.
About 10% of all mail traffic are misdirected bounces. Some links
to statistics created by Ironport and/or MesageLabs in 2006 were
posted here. Systematic auto-replies to innocent bystanders are by
definition UBE, that's ordinary net abuse, spam.
Cheap solutions like "let others publish FAIL policies", "let others
reject SPF", "let's pretend that 1123 5.3.6(a) was no bug", "let's
pretend the reverse path is normally okay", "let's just trash all
mails with empty reverse paths", etc. cannot work. Unlike spam it's
a design flaw, a technical problem in SMTP.
It took some years until folks accepted that open relays don't work,
Some still don't accept it. For crying out loud section 6.1 in 4409
is only an option, it should be a SHOULD.
Frank
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg