> '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.
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.
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.
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.
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 ? Without some good justification (like an SPF PASS),
is this an instruction to send *spam* in a prposed standard ?
Section 2.3 apparently says "for 'reject' *spam* as specified
in 2.2, do not 'ereject' as specified 2.1". What's the idea ?
Section 2.5 could reference RFC 5248 in addition to RFC 2034.
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.
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").
There are no "security considerations" about sending hostile
content embedded in a DSN, NDR, or MDN back to alleged senders.
Please don't change this example, the virus case is important.
The last paragraph in section 2.5 sounds like "grey listing",
what has this to do with SIEVE, 'reject', and 'ereject' ?
Frank
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf