Subject: draft-ietf-sieve-refuse-reject approved by IESG

From: Matthew Elvey <[email-masked]>
Date: Fri, 21 Nov 2008 01:28:39 -0800

On 11/19/08 11:07 AM, Alexey Melnikov wrote:
> Lisa Dusseault wrote (Re: Fwd: SIEVE bounced SIEVE bounce message):
>
>> Oh the irony.  I send a message saying that the SIEVE document 
>> refuse-reject has been approved, and it gets bounced by Elvey's SIEVE 
>> filter.
>
> Yes. Messages from Cyrus, Aaron and myself all bounced as well.
Sorry about that.  Perhaps you were using the [email-masked] 
address that I retired long ago.  I did not want that address in 
refuse-reject either.  I asked that it be replaced with 
matthew@elvey...., to no avail.  Too late, no?  I wrote to the list on 
9/10/08: "I believe ... issues that have been raised need to be 
addressed; a WGLC and LC are also needed. " I don't see that -09 had 
either a WGLC or LC.

-09 is a big improvement on RFC 3028, but fails to address some of the 
issues I raised on on 9/10/08, primarily the inappropriateness of 
allowing a system "B" to be considered compliant with "ereject".

(BTW, the MAY in
"   However implementations MAY refuse delivery over SMTP/LMTP 
protocol    " (line 318)
should be a SHOULD; I don't see what holds it back. The last-minute 
removals of the word "purported" also makes the spec misleading; they 
hide a hurdle that contributed to its deficiencies.)

I am still strongly opposed to to a situation where, if a system implementing the spec works on a store-and-forward basis, it can claim to support ereject, as defined in an RFC.

We've got Cyrus Daboo, TS Glassy, John Kleinsin, and Kristin Hubner 
using a ridiculous straw man argument as the excuse to push through this 
flawed I-D to RFC status, instead of making the small limited changes I 
have pushed for.  (Perhaps some of them led the others to be confused.)  
Specifically, they act as if I haven't made it extremely clear, on 
multiple occasions, that I know that there are plenty of key use cases 
where only doing SMTP protocol rejection is not possible.   I had, but 
nonetheless, claiming that I hadn't and that they existed was the 
primary straw man argument used.  I'm the primary author of the first 
half dozen versions of this draft, all of which, as I'd recently pointed 
out, went into great detail to make exceptions (including MDNs and DSNs) 
for the key use cases where SMTP protocol rejection is not possible.  So 
once again, for the record, I'd like to point out that I never made 
light of those exceptions.
Amazingly, that straw man argument was in response to my post in which I 
said, among other things:

Ned acts like [I'm] saying that I'm against allowing Japanese users to fall
back to out-of-transaction rejects when non-ASCII reject strings need to
be used.  I'm not.  Look at the drafts I wrote!  They don't do that!

I'm not upset that people disagree with me.  I'd be fine if the 
consensus in the WG (despite my opposition) was that the spam the draft 
unnecessarily permits wasn't important, and if the IESG voted to make it 
an RFC on that basis, following IETF procedure.  I would be unhappy, 
sure. but I wouldn't be pissed off.
But violating process, avoiding debates on the merits, and resorting to 
straw man attacks?  That was not cool, and not professional.
Ned's nasty insults and smearing of me was particularly galling - Ned 
provided no specifics, but claimed I made many inaccurate references to 
him and Sun.  I on the other hand, responded to Ned's (and others') 
debate points. I pointed out where Ned had misread what I'd said, or I 
had misspoken, or was wrong, or disagreed.  If we don't have debates on 
the merits, and honest dialogue, but instead give political speeches, or 
worse, attack each other, (both of which remind me of typical US 
political debates) we end up with lousy specifications.

Well, I guess on the bright side, at least the debate is over.  The 
horse is dead, the sausage stuffed, as far as I'm concerned.  DNR, I say.
>
>> Lisa
>>
>> Begin forwarded message:
>>
>>> *From: *Mail Sieve Subsystem <[email-masked] 
>>> <mailto:[email-masked]>>
>>> *Date: *November 19, 2008 12:07:21 PM CST
>>> *To: *<[email-masked] <mailto:[email-masked]>>
>>> *Subject: **Automatically rejected mail*
>>>
>>> Your message was automatically rejected by Sieve, a mail
>>> filtering language.
>>> ...
>>
>>
>>>
>>>
>>> Hi,
>>>
>>> There are no remaining DISCUSS positions on this document, and it  
>>> looks like it has enough ballot positions filled to approve. There 
>>> are  no RFC Editor notes.
>>>
>>> Thanks,
>>> Lisa
>>>
>>>
>>>
>>>
>>
>

---

From: Aaron Stone <[email-masked]>
Date: Fri, 21 Nov 2008 10:05:04 -0800

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.

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.

Best,
Aaron

---

From: Matthew Elvey <[email-masked]>
Date: Fri, 21 Nov 2008 14:29:23 -0800

> 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
> ([email-masked]) with [email-masked]; 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.
>    
> consensus on this document as it now stands and really, really wants to
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.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 22 Nov 2008 01:11:09 +0100

Matthew Elvey writes:
> I'm sorry if I didn't make clear the main change I wanted made (undone).

And since someone needs to say why this didn't sway the WG rough 
consensus, I'll say why I'm not persuaded.

My code is able, or not, to carry out an ereject in a manner different 
from reject. It depends on this and that, including factors beyond 
control of my code. The code may even be able to do it when the sieve 
script is uploaded, but unable to when it's executed.

Making a script invalid between upload and execution is not at all 
desirable. Not having ereject at all is not desirable either. And so 
on. Aaron's solution is the best compromise I can think of, in the 
sense that it minimises the sum of undesirable aspects.

Arnt

---

From: Matthew Elvey <[email-masked]>
Date: Mon, 24 Nov 2008 00:37:36 -0800

> script is uploaded, but unable to when it's executed.
Sorry, I don't have ESP, so I don't know what you're talking about.   I 
came up with a contrived example, but haven't come up with a realistic 
one.  Have you one you can provide?
> desirable. Not having ereject at all is not desirable either. 
You've not presented a case (real world or otherwise) fixed by Aaron's 
change I wanted undone.