On 11/21/08 10:05 AM, Aaron Stone wrote:
Hi Matthew,
We can definitely get the author information fixed before publication,
at least during AUTH48 if not sooner by request to the RFC Editor.
Thanks. FYI:
On 7/20/08 6:51 AM, Matthew Elvey wrote to webtools@ and ietf-action@:
Hello, and thanks for your surely often thankless work.
https://datatracker.ietf.org/drafts/draft-ietf-sieve-refuse-reject/ has
my name misspelled in two places.
Please
s/Mathew Elley/Matthew Elvey/ (you can check the draft:
http://ietfreport.isoc.org/ids/draft-ietf-sieve-refuse-reject-07.txt to
verify the correct spelling. Please also replace the email address
(sieve3(_at_)matthew(_dot_)elvey(_dot_)com) with
sievedraft4(_at_)matthew(_dot_)elvey(_dot_)com; the
former is no longer valid.
The spelling errors have started to spread;
http://www.google.com/search?&q="Mathew Elley" shows this.
On 7/28/08 3:14 PM, Matthew Elvey wrote:
On Mon, 21 Jul 2008 11:28:52 -0700, "Cindy Morgan via RT"
<iesg-secretary@> said:
According to our records, your request has been resolved. If you have any
further questions or concerns, please respond to this message.
Thanks.
It seems the spelling was corrected, but my email was removed instead of
replaced.
Since I'm strongly opposed to the draft, I'd like to remain reachable...
Thanks.
Aaron Stone continues:
I didn't respond to your earlier objections because I couldn't figure
out where the substantive changes were, and even so, none had any WG
consensus. I apologize for basically ignoring you, but the WG has strong
consensus on this document as it now stands and really, really wants to
see it published.
I'm sorry if I didn't make clear the main change I wanted made
(undone). Let me try, 3 more times, to make it as understandable as I
can, for the record. Unfortunately, every explanation seems to require
several qualifiers.
You changed the specification so that a compliant implementation could
allow a "require" of the enhanced reject action (i.e. "refuse" or
"ereject") to succeed on a system that had no capability to perform
protocol level message rejection of messages from the outside world
because of an intervening store-and-forward MTA within the ADMD of the
implementation. I never saw significant support expressed for that change.
I have no reason to think the change was intentional and harbor no grudge.
If I could make the explanation simpler, I would. Let me state it as a
question:
Can the ereject action be available in environments that DO NOT support
protocol level rejection of messages as they come in from untrusted
third parties but DO support protocol level rejection as messages arrive
at an MDA from an MTA within the ADMD of the MDA?
Or here's a graphical version. In the implementation below, can x be
store-and-forward or not?
(If it is, the MTA cannot perform protocol level rejection of
messages from the MSA in response to a signal from the MDA, because it
will have already accepted the message from the MSA.
If it is not, then the MTA can perform protocol level rejection of
messages from the MSA in response to a signal from the MDA, because it
will have not yet accepted the message from the MSA.)
ADMD
+--------------------------------+
| |
+----------+ Internet connection | +----------+ x +----------+ |
| MSA |--------------------------->|-->| MTA |-->| MDA | |
+----------+ | +----------+ +----------+ |
| |
+--------------------------------+
It can be reverted with a simple insertion of a single sentence, e.g.:
The ereject action MUST NOT be available in environments that do not
support protocol level rejection of messages as they come in from third
parties in response to an ereject action, e.g. an MUA or an MDA
receiving messages on a store-and-forward basis from an MTA.
The current spec actually has almost identical language already:
"The ereject action MUST NOT be available in environments that do not
support protocol level rejection, e.g. an MUA"
but the details at the end of the sentence are critical.
Best,
Aaron