On 11/29/06 11:39 AM, Frank Ellermann wrote:
Matthew Elvey wrote:
The IETF's SIEVE Working Group
<http://www3.ietf.org/html.charters/sieve-charter.html> is
modifying/updating the way scripts written in Sieve (the mail filtering
language) can handle messages to be refused/bounced/sent to where they
purportedly came from.
I'm aware of that, e.g. the approved (?) or published (?) part about
vacation is firmly based on RFC 3834. That's a sine-qua-non, normal
auto-replies go to the Return-Path, and their own Return-Path is of
course empty. Same idea as for DSNs and MDNs. Anything else is FUBAR,
Keith expressed it more politely in 3834.
It results in tons of spam blowback/backscatter when the sender is
forged, including when Sieve scripts are part of a Challenge/Response
system, or out-of-office system, or spam-filtering system.
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.
The sender can't control how is mail is forwarded, so legit mail can be
marked SPF FAIL. Not to say that SPF is totally useless. But, I said
email authentication, not SPF, intentionally.
For the NONE/NEUTRAL folks it's up to them to
change that if they don't like the effect. After an SPF PASS mail
including DSNs, MDNs, SIEVE, C/R, vacation, and what else works as
designed (before they deprecated the reverse path routing in 1123).
<http://www.ietf.org/internet-drafts/draft-ietf-sieve-refuse-reject-04.txt>,
I shortly looked into that some time ago, it's apparently about
using SIEVE in the DATA-phase of SMTP (= not yet accepted), like
SA 3.x can be used before the mail is accepted.
Right.
It was stated that Sieve is not used as part of spam-filtering
systems
Odd, SIEVE is the theory where SA is a part of the praxis, and SA is
certainly a part of spam-filtering. Do you have a pointer for this
odd statement ?
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
and that the current behaviour was not causing problems.
...
...
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. I'm here trying to enlist help to make that illusion disappear
among Sieve implementers.
If senders don't publish
a FAIL policy receivers can get into ugly situations.
The official SC policy (since early 2005) is that blowback can be
always reported as spam. And my position was always that this is
dubious if the senders didn't try to help that the receivers have
a fair chance to get it right, by publishing a no nonsense PASS or
FAIL SPF policy.
As it is all participants can decide that it's not their problem:
- Spam reporters can say they don't need a FAIL policy, it's the
fault of the receivers
- Receivers can say they don't need to check SPF, and SC's "new"
policy is anyway bogus (or rather "not covered by RFC 2821")
- In practice they need a separate IP for DSNs, because they'll
be blacklisted permanently for their blowback
- Senders can use these blacklists, and in practice they won't
get legit DSNs (or other auto-replies) from such receivers
- SMTP dies, let's all get jabber clients, thread on the IETF
general list, film(_at_)11, what else is new ?
...
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.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg