Subject: [apps-discuss] call for adoption: draft-wmills-rrvs-header-field

From: Salvatore Loreto <[email-masked]>
Date: Fri, 2 Aug 2013 11:47:27 +0200

This is a call for adoption for draft-wmills-rrvs-header-field [1]

There is a pretty good thread going on apps-discuss [2]
that shows an interest within this working group about this work,
and it appears to be material that falls within our charter.

Accordingly, we'll adopt this as a working group item within the next 
couple
of weeks unless there's objection to such processing.

/Salvatore

[1] http://www.ietf.org/id/draft-wmills-rrvs-header-field-00.txt
[2] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10013.html

---

From: Dave Crocker <[email-masked]>
Date: Tue, 06 Aug 2013 00:56:44 +0200

> This is a call for adoption for draft-wmills-rrvs-header-field [1]

+1

I've assorted editorial comments, but the technical approach looks 
reasonable to me.

I think the only technical wrinkle that's significant is the restriction 
to a single addressee, but I'm told that's been relaxed for the latest 
version of the spec.  (Admittedly, permitting multiple addressees does 
introduce privacy and probably other concerns.)

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Kurt Andersen <[email-masked]>
Date: Mon, 5 Aug 2013 16:04:00 -0700

On 8/2/2013 11:47 AM, Salvatore Loreto wrote:
>
>
> This is a call for adoption for draft-wmills-rrvs-header-field
>

+1

Would be nice to get this stabilized before we start implementing it
too widely (being driven by Yahoo!'s email recycling which starts on
15 August).

--Kurt Andersen

---

From: "John Levine" <[email-masked]>
Date: 6 Aug 2013 01:55:12 -0000

>introduce privacy and probably other concerns.)

I don't understand how multiple addresses would work, given the
combinatorial explosion of various addresses that do or don't appear
in the rrvs header, the To: header, and the envelope, but I guess I
should wait and see what the next draft says.

---

From: Bill Mills <[email-masked]>
Date: Mon, 5 Aug 2013 20:32:35 -0700

An RRVS header applies only for the recipient specified in the header, and affects delivery only to that recipient.   So the way this will workis you need an RVS header for each recipient the sender wants to affect with RRVS.

-bill

--------------------------------
William J. Mills
"Paranoid" Yahoo!

________________________________
 From: John Levine <[email-masked]>
To: [email-masked] 
Cc: [email-masked] 
Sent: Monday, August 5, 2013 6:55 PM
Subject: Re: [apps-discuss] call for adoption: draft-wmills-rrvs-header-field

_______________________________________________
apps-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Dave Crocker <[email-masked]>
Date: Tue, 06 Aug 2013 05:48:37 +0200

On 8/6/2013 5:32 AM, Bill Mills wrote:
> An RRVS header applies only for the recipient specified in the header,
> and affects delivery only to that recipient.   So the way this will
> workis you need an RVS header for each recipient the sender wants to
> affect with RRVS.

I suspect that a failure for one needs to be a failure for all, at the 
end of the SMTP DATA command.

d/

---

From: Bill Mills <[email-masked]>
Date: Mon, 5 Aug 2013 21:00:07 -0700

Yeah, that's gonna make it more interesting.  Is there any other case where you might deliver to one recipient after the DATA command but not another for the same message?  Can't fit the message in the user's remaining quota perhaps?

-bill

________________________________
 From: Dave Crocker <[email-masked]>
To: Bill Mills <[email-masked]> 
Cc: John Levine <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Monday, August 5, 2013 8:48 PM
Subject: Re: [apps-discuss] call for adoption: draft-wmills-rrvs-header-field

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 5 Aug 2013 22:47:20 -0700

On Mon, Aug 5, 2013 at 8:48 PM, Dave Crocker <[email-masked]> wrote:

>
> I suspect that a failure for one needs to be a failure for all, at the end
> of the SMTP DATA command.
>
>
Right.  Once upon a time there was an SMTP extension proposed that would
allow different status to be returned for each recipient in reply to the
DATA command, but it never made it to publication.  I think there were a
few trial implementations, however.

-MSK

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 06 Aug 2013 10:53:50 +0100

> of weeks unless there's objection to such processing.

I am not entirely convinced how useful this end up being (in particular 
if deployments of this are not widespread), but if this work is to be 
done, I prefer if it is done in the AppsaWG. So "+1".

> [2] 
> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10013.html
>

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 06 Aug 2013 14:53:33 +0200

On Tue 06/Aug/2013 06:00:07 +0200 Bill Mills wrote:
> *From:* Dave Crocker <[email-masked]>
>> 
> Yeah, that's gonna make it more interesting.  Is there any other
> case where you might deliver to one recipient after the DATA
> command but not another for the same message?  Can't fit the
> message in the user's remaining quota perhaps?

I think it is quite common, to avoid backscatter, to split recipients
so as to insulate those who are likely to reject after data from those
who will accept.  That has to be done in advance, by replying 4xx to
the recipients of the second group.

Just like LMTP, that technique is based on the envelop.  Ned's
comments will have to be addressed if the I-D is adopted, so +1 for
adoption from me as well.

---

From: "John Levine" <[email-masked]>
Date: 6 Aug 2013 14:59:54 -0000

>end of the SMTP DATA command.

This is the swamp I was alluding to.

If a sender puts two rrvs headers on a message, and the recipient
system rejects at the end of data, there's no way to tell which of
them was the problem, short of implementing SMTP extensions that
people have considered and declined to implement before.  I suppose
you could then split the message and send it separately to each and
see what happens, but that seems like more complication than it's
worth.

The main application for this hack is transaction messages which by
their nature rarely go to more than one address, so it's perfectly
reasonable to say that the results of using more than one rrvs header
are indeterminate, so don't do that.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: Bill Mills <[email-masked]>
Date: Tue, 6 Aug 2013 08:13:16 -0700

Does this properly capture what you're saying, "The results of using more than one RRVS header are indeterminate since there is no way to return mailbox specific delivery results after the DATA command, for that reason use of multiple RRVS is NOT RECOMMENDED."?

-bill

Sent: Tuesday, August 6, 2013 7:59 AM

Regards,

---

From: "John R Levine" <[email-masked]>
Date: 6 Aug 2013 11:16:30 -0400

> Does this properly capture what you're saying, "The results of using 
> more than one RRVS header are indeterminate since there is no way to 
> return mailbox specific delivery results after the DATA command, for 
> that reason use of multiple RRVS is NOT RECOMMENDED."?

Close enough.

R's,
John

> Please consider the environment before reading this e-mail. http://jl.ly

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Ned Freed <[email-masked]>
Date: Tue, 06 Aug 2013 09:53:44 -0700 (PDT)

> done, I prefer if it is done in the AppsaWG. So "+1".

Indeed. I've already noted the cost-benefit asymmetry in a previous note.
Unfortunately the biggst cost is likely going to be making the necessary
account information available to the email system.

But I'm willing to code it and see if anyone uses it.

And appsawg seems a good a place as any to do the work.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Tue, 06 Aug 2013 10:06:58 -0700 (PDT)

> >end of the SMTP DATA command.

Nonsense. This would be fundamentally changing the semantics of email - 
you're essentially saying that the presence of this field changes the envelope
to an all-or-nothing deal.

We went through this in tedious detail back in the days of Sieve ereject;
let's please not repeat that discussion. SMTP servers are *required* 
to be able to handle a mixture of recipient address states at the end of
DATA; if this includes partial-accept and partial-reject you have to generate
DSNs. 

This is reality; suck it up and move on.

> are indeterminate, so don't do that.

On the contrary, it isn't reasonable at all. A mechanism like this that causes
delivery failures requires a crisp and complete specification. Failure to do
that should disqualify this from the standards track.

You can say that having more than one means all of them MUST be ignored, or you 
can specify how multiple headers can be handled.

I'll also note that the multiplicity of this field has zero effect on the
need to generate DSNs. A single field could apply to one recipient and not
another.

				Ned

---

From: Bill Mills <[email-masked]>
Date: Tue, 6 Aug 2013 10:33:57 -0700

We were hoping for immediate feedback, sounds like we may need to discuss DSNs in the draft then.  Can we give any guidance that direct feedback is preferred?

-bill

________________________________
 From: Ned Freed <[email-masked]>
To: John Levine <[email-masked]> 
Cc: [email-masked]; [email-masked] 
Sent: Tuesday, August 6, 2013 10:06 AM
Subject: Re: [apps-discuss] call for adoption: draft-wmills-rrvs-header-field

                Ned

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 6 Aug 2013 10:43:16 -0700

Seems to me that's always the case anyway, is it not?  If it is, I don't
think we need to say it explicitly.

On Tue, Aug 6, 2013 at 10:33 AM, Bill Mills <[email-masked]> wrote:

> We were hoping for immediate feedback, sounds like we may need to discuss
> DSNs in the draft then.  Can we give any guidance that direct feedback is
> preferred?
>
>
>
> -bill
>
>
>   ------------------------------
>  *From:* Ned Freed <[email-masked]>
> *To:* John Levine <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Sent:* Tuesday, August 6, 2013 10:06 AM
>
> *Subject:* Re: [apps-discuss] call for adoption:
> draft-wmills-rrvs-header-field
>

---

From: "John R. Levine" <[email-masked]>
Date: 6 Aug 2013 14:10:50 -0400

> can specify how multiple headers can be handled.

The former seems fine to me.  The practical advantages of a more complex 
spec seem minimal.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Tue, 06 Aug 2013 13:38:08 -0700

On 8/6/2013 10:06 AM, Ned Freed wrote:
> let's please not repeat that discussion. SMTP servers are*required*

ack.

So...

When the text is modified to cover the multiple header field (addressee) 
case, it will be worth citing the spec details that cover established 
practice for handling errors...

d/

---

From: Ned Freed <[email-masked]>
Date: Tue, 06 Aug 2013 15:18:24 -0700 (PDT)

> case,

That's already been done, and posted. I have essentially no issues with the
current version.

> it will be worth citing the spec details that cover established

That would be RFC 5429 section 2.1.2. It's done in a fairly Sieve-specific
way, however.

Again the case arises irrespective of whether or not you allow the field
to be repeated. All it takes is multiple envelope recipients.

Really, I don't see why this is generating such concern. As others have noted,
the primary use-case here is one involving a single recipient. We have
to cover the other cases not because they're incredibly useful, but rather
because mechanisms that cause mail to be rejected need to be completely
and fully specified.

A check against the envelope is necessary for multiple reasons. Given that's
the case, all this does is join the long, long, long list of mixed result
situations that cannot be detected at RCPT TO time.

If there's any real cause for concern, it should be for implementations that
find it difficult to perform an SMTP-level rejection after the DATA even in the
single-recipient case. Those implementations will be generating a DSN every
time.

I don't know the state of play on this currently, but there used to be
implementations with this issue. Which would argue for making this a RCPT TO
parameter instead of a header field.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Tue, 06 Aug 2013 19:27:32 -0700

On 8/6/2013 3:18 PM, Ned Freed wrote:
> Really, I don't see why this is generating such concern.

My only concern is with making the documentation be careful for this. 
As the thread has demonstrated, it concerns a failure scenario about 
which there obviously is an, ummmm, varying level of community 
understanding.

I think the new mechanism is better for being able to handle multiple 
header-fields (ie, addressees).

But the best documentation for handling it appears to be buried in a 
specific, secondary protocol.

In terms of the new mechanism, I'm fine with that, but it highlights the 
need for a bit more documentation than otherwise might be warranted 
(say, if the handling behavior were built into SMTP documentation...)

d/