draft-ietf-sieve-refuse-reject-00 justifies the 'refuse' extension
based on a claimed ability to reduce the amount and/or likelihood
of joe-job spam. By my reading, there is only a reduction in amount
by replacing one or more MDNs (one per recipient using 'reject')
with one DSN and no reduction in likelihood. While a message that
is refused by all recipients can indeed be refused at the SMTP-level
at the final dot, a DSN will still be generated unless the message
was received directly from the submitting software by the SMTP-based
sieve implementation. That doesn't apply when open relays ("open
proxies" in the draft) are involved or if the sieve implementation
is behind any MTAs that don't synchronously pass-through messages.
I therefore suggest that the introduction and abstract limit
themselves to claims that can then be justified in the body of the
draft.
Editorial:
- shouldn't "open proxies" be "open relays"? This is a reference
to MTAs that relay without limits, right?
- there are many sentences that contain too many commas. Most
simply need one or more commas removed; some should be split
into two sentences
- abstracts may not contain references
- the second paragraph of section 3 should be rephrased to state
that it applies only to SMTP and not LMTP from the start, ala
"If the implmentation receives a message via SMTP that
has multiple valid recipients and at least...
Philip Guenther