'Sieve Email Filtering: Reject and Extended Reject Extensions '
<draft-ietf-sieve-refuse-reject-07.txt> as a Proposed Standard
IMO this draft is _not_ ready for publication on standards track.
I disagree.
The "Joe Job" in the abstract is a deviation from current usage:
Forging "plausible" return-paths (to survive call back and SPF
FAIL checks) is the norm in spam. Today most mails are spam
with forged return-paths, this is not a "Joe Job". The goal of
a "Joe Job" is to harm the reputation of the (alleged) sender.
This is the original meaning of the term - you can find the history behind the
term in the Wikipedia entry. You are correct to say that current usage has
drifed somewhat from the original, but if there's general consensus that the
old usage is now incorrect I haven't seen it. Accordinngly, as long as the term
is well defined and used consistently within the document I see no
justification for changing anything here.
In section 2.1 step 2 says:
| Discard the message if a return-path verification clearly
| indicates that the message has a forged return-path.
Step 1 before 2 is *very* important when "clearly" turns out to
be not as clear as expected. IMO the draft should stress that
rejecting a "clearly" forged return-path directly at the border
MTA avoids potential issues in step 2.
Well, the draft currently states that these actions (they are not steps in the
sense I understand the term) are listed in order of preference. As for
stressing this even more, the problem with that is that there sre cases, such
as when operating on a relay MTA that's past the ingress point to an
administrative domain, where taking action 1 will in fact generate blowback and
is therefore NOT preferable to 2. So yes, there is a general preference order
here, but overstressing it is IMO not a good idea.
For better or worse, the present-day reality for high-end mail systems is for
their functions to be distributed over multiple hosts arranged in complex ways.
These sorts of attempts to overspecify behavior are at best silly, at worst
quite dangerous, in the context of such setups.
In section 2.1.2 maybe say how <UTF8-non-ascii> reasons are
handled in an ordinary DSN or in a legacy NDR. Likely the fine
print in the DSN RFCs already covers this, I didn't check it.
AFAIK it does not, but given that we're talking about create a plain
text message part with a charset of utf-8, how hard is this really?
Section 2.2 "reject" *claims* to be about MDNs. I fear I miss
at least one clue, are these *unsolicited* MDNs in violation of
RFC 3798 ?
First, let's keep in mind that if reject is used, it is within the context of a
user-supplied script. This means that the recipient of the message has given
explicit instructions for an MDN to be generated.
RFC 3798 has a bunch of rules for when a user agent should or should not send
an MDN without being explicitly instructed to do so by its user, but is
basically silent on the issue of recipients explicitly deciding to send such
messages. And this is intentional - the RECEIPT WG (which I chaired) wanted to
allow the explicit use of MDNs by ysers (in fact at one point the group almost
went with this sort of explicit usage as the only possible use. That was before
Keith Moore came up with the Disposition-notification-to: header idea.)
I also note that tthe only time the term "unsolicited" is mentioned in RFC 3798
is in a discussion of MDN forgery.
I therefore see no issue with the use of MDNs in this context.
That said, one thing does occur to me that might make sense to add: A
discussion of how this usage of MDNs interacts with a
Disposition-notification-to: field if one is present. I think a pointer to the
discussion of this in RFC 3987 would suffice.
Without some good justification (like an SPF PASS),
is this an instruction to send *spam* in a prposed standard ?
It is nothing of the sort.
Section 2.3 apparently says "for 'reject' *spam* as specified
in 2.2, do not 'ereject' as specified 2.1". What's the idea ?
Consistency with earlier, widely-deployed implementations. Implementations
which, I note, have not come to be associated with the generation of blow-back
spam.
Section 2.5 could reference RFC 5248 in addition to RFC 2034.
Seems like a reasonable editorial change.
The example in section 2.5 explains how to 'ereject' a likely
virus. But if steps 1+2 in section 2.1 for some reason don't
handle the 'ereject' step 3 sends a DSN for the likely virus.
RFC 2821bis section 6.2 states:
| if a message is rejected because it is found to contain hostile
| content (a decision that is outside the scope of an SMTP server
| as defined in this document), rejection ("bounce") messages
| SHOULD NOT be sent unless the receiving site is confident that
| those messages will be usefully delivered
In other words, the example in 2.5 in conjunction with step 3
in 2.1 would violate a SHOULD NOT in the ESMTP draft standard.
Sure, and that's exactly why it's a SHOULD NOT in 2821bis, not a MUST NOT.
That needs an explanation. E.g., limit step 3 in the case of
"hostile content" to SPF PASS, where it cannot hit an innocent
bystander (roughly that's "confident" ... "usefully delivered").
I will strongly object to the addition of any references to SPF here. SPF is an
expermental specification.
I would not object to adding a sentence or two to this section discussing the
potential issues with the return of harmful content in an MDN or DSN, but it
needs to be a generic discussion that doesn't depend on SPF.
There are no "security considerations" about sending hostile
content embedded in a DSN, NDR, or MDN back to alleged senders.
I have no problem with adding some discussion of this, but really, to the
extent this is a problem, discussion of it needs to be in the specifications
people actually look to for DSN or MDN specifics: The specifications for DSNs
and MDNs themselves.
Please don't change this example, the virus case is important.
Agreed.
The last paragraph in section 2.5 sounds like "grey listing",
what has this to do with SIEVE, 'reject', and 'ereject' ?
Well, irrespective of Sieve, the greylisting technique of returning
temporary failures is in fact widely used in many places to try and
avoid information disclosure. It is in no way a stretch to extend this
to Sieve.
That said, I think this particular usage is fairly silly. But others
disagree and this is what the group reached consensus on.
Finally, while I'm seeing some suggestions for some minor editorial changes
here that I would support, I'm not seeing any technical issues that would
warrant holding this document.
Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf