[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Strong Opposition due to spam backscatter. Re: Last Call: draft-ietf-sieve-refuse-reject-07 and -08 (Sieve Email Filtering: Reject and Extended Reject Extensions) to Proposed Standard
Matthew Elvey writes:
If a system implementing the specs we're working on works on a
store-and-forward basis, then it MUST NOT MISLEAD, i.e. LIE TO ITS
USERS by claiming to support the enhanced standard we are writing.
-07 allows an implementation to mislead its users by claiming to
support enhanced functionality when it does no such thing.
Why not? My code (I implemented -07 a few weeks ago) advertises support
for the standard even if it may or may not provide enhanced
functionality. I think that's fine. It does provide in-protocol
rejection when possible, and the rules have very pleasant consequences.
Most importantly, it's possible to make system configuration changes
that affect system's ability to to in-protocol rejection without
invalidating anyone's sieve script.
That would simply be dishonest.
It's just another RFC about best-effort something something. There are
many others already, so most implementers are familiar with the
concept. And AFAICT, implementers generally implement a best effort,
not behave dishonestly.
(I read some more of this monster mail, but IMHO it degenerates into a
pure rant around the point where Aaron Stone is first called «the
author of -07». Not worth answering.)