Subject: Re: [apps-discuss] SMTP extension Re: I-D Action: draft-ietf-appsawg-rrvs-header-field-01.txt

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 12 Nov 2013 16:13:46 -0800

So to you two guys in particular, does the new draft, which dropped the
header field, satisfy your concerns?  I saw John's editorial nits, so let's
assume those are resolved... anything else we need to do here?

-MSK

On Tue, Oct 29, 2013 at 12:02 PM, John Levine <[email-masked]> wrote:

> >I have to say I'm not wild about the notion of downgrading the RRVS
> extension
> >to the header mechanism on the fly, because it grots up code that
> otherwise is
> >able to do things like BDAT in a single, simple operation. But it is
> >implementable.
>
> I don't think anyone is, but considering the number of relay servers
> that exist, we need to say something.
>
> I'm pretty much with Murray, note it and don't try to solve the
> problem.
>
> If a relay is able to remember the RRVS envelope info, it can pass it
> along in the next SMTP session.  Or it could stick it in the message
> as an RRVS header, although since RRVS isn't a trace header that runs the
> risk of breaking signatures and other confusion.
>
> R's,
> John
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: John R Levine <[email-masked]>
Date: Tue, 12 Nov 2013 20:41:09 -0500 (EST)

> assume those are resolved... anything else we need to do here?

Technically it's OK, although if there's no RRVS header I'd want to add an 
Authentication-Results: clause, e.g.:

  rrvs=2013-12-31T23:59:59 smtp.mailfrom=[email-masked] ;

Have you asked your co-author whether Yahoo is planning to implement this 
as an SMTP extension?  If not and there aren't any other large mail 
systems planning to do so, my advice would be to abandon the draft and 
spend your limited time on something that's likely to get some traction.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Bill Mills <[email-masked]>
Date: Tue, 12 Nov 2013 17:47:46 -0800

So, abandon the SMTP extension and the running code with major interop both?  That doesn't sound like a win.

I don't know how quickly we'd implement an SMTP extension.

-bill

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

Regards,

---

From: John R Levine <[email-masked]>
Date: Tue, 12 Nov 2013 21:16:50 -0500 (EST)

> I don't know how quickly we'd implement an SMTP extension.

The current draft just describes the SMTP extension.  If Yahoo isn't 
planning to implement it, I'm not aware of anyone else who is, so I don't 
see any point in spending effort on shepherd write up, last call, and so 
forth for an RFC that nobody will use.

On the other hand, if you've implemented the RRVS header and particularly 
if you know of other people who've done so and they interoperate, we 
should document that even if it is inferior in principle to the SMTP 
version.

Regards,

---

From: Bill Mills <[email-masked]>
Date: Tue, 12 Nov 2013 18:20:09 -0800

The previous drafts documented the header usage that Yahoo and Facebook are already using.  I believe Google is implementing currently, I don't know offhand what other sources are sending it.

-bill

 

Regards,

---

From: "John R. Levine" <[email-masked]>
Date: Tue, 12 Nov 2013 21:25:56 -0500 (EST)

> The previous drafts documented the header usage that Yahoo and Facebook 
> are already using.  I believe Google is implementing currently, I don't 
> know offhand what other sources are sending it.

Then despite Ned's reservations, we should go back and document 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: Ned Freed <[email-masked]>
Date: Wed, 13 Nov 2013 08:49:59 -0800 (PST)

> Then despite Ned's reservations, we should go back and document that.

First of all, I never said the header should be abandoned. In fact I was quite
careful not to say that.

What I did say is that the header mechanism was a lot more difficult to
implement than I anticipated. As such, if this moves forward it needs to
include the much simpler SMTP extension, and if something is to be dropped it
should be the header mechanism.

And if the header mechanism has already deployed, that's certainly an argument
for keeping it, despite the issues it clearly has. A header mechanism was
defined for MT-PRIORITY, so there is precedent for doing this.

Now, as to who is going to implement this. I already have, and assuming
it makes it to an RFC, our plan is to make it part of our implementation
in due course.

And not to put too fine a point on it, but quite a few large MSPs and ISPs use
our stuff. Of course this doesn't mean they will choose to use this facility.
I've only spoken to a couple so far, and their response was that they don't
care about it since they don't recycle addresses. (They had a lot more to say
about this particular practice, but I'll spare everyone the repitition of
that.) But assuming there are some that do want to recycle, I see no reason why
they wouldn't deploy this.

				Ned

---

From: Hector Santos <[email-masked]>
Date: Wed, 13 Nov 2013 16:18:33 -0500

> assume those are resolved... anything else we need to do here?

I was surprised you pulled the header. I think this is a dual solution 
for the widest coverage. The alternative is to discuss the passage of 
meta information in relays.   We had to do the same thing with adding 
support for Return-Path when we moved from old 822/2822 "From " UUCP 
methods of getting bounce path information.  In fact, our MDA will 
pull the Return-Path once its logic and need has been satisfied for 
final MUA pick up.  Again, different software parts.

Overall, I could add support for this, but I have having trouble with 
the safe automated logistics. I think you need more use case examples 
and also discuss or at least understand all boundary conditions.

Consider what is being asked of the server (receiver) system in 
dealing with accounts, in particular those that have "expired" either 
for lack of usage and/or some subscription model is in play.

   - Deleted Accounts ---> Yields 55x responses
   - Demoted Accounts (No network mail) --> Yields 55x responses.

That is today. Ultimately,  this proposal is about asking a hosting 
server when it should issue a 55x for what is otherwise a 250 action 
for active accounts:

   - Active Accounts normally yields 250 responses:

     - Non-RRVS compliant           --> 250
     - RRVS compliant (Time Pass)   --> 250
     - RRVS compliant (Time Failed) --> 550 5.7.15

What TIME fields are we comparing among those only known to the server?

Is this proposal asking Servers to add a new "RRVS" field to user 
records with opaque meaning?

When does it get set?  By the first instance of the RRVS client?

Anyway, I guess the only real change in the final results is reaching 
a 550 response for normally 250 active accounts.   Would this be a 
near understanding of this proposal?

I understand the long time problem. All of our BBS operators since the 
80s had the problem of expired accounts but the odds of name 
collisions were low. Today, the potential for name collisions are very 
high especially at popular centralize service sites where multiple 
people with the same names can gather.  But I wonder if this the right 
solution in order to reclaim old "expired/demoted" account names for 
new users?

What happens when an account with RRVS information is demoted? Should 
a client get the 550 when the RRVS TIME is still valid?

For example, a yahoo account is used to create a facebook account. 
Facebook sends automated messages and it uses the RRVS with the TIME 
reflecting I suppose, some "creation" or "last confirmation" time. 
How does the server know what time is this?  So I suppose YAHOO will 
save the RRVS value that was passed by the first time RRVS client and 
then use this value as a "Key" in theory for validity in future 
transactions.   I guess, facebook will get some benefit (sure feels 
like its playing with fire here), but what about Yahoo?  What if the 
user goes away, gets sick, for a long time and comes back 1+ year 
later, and Yahoo either deletes or demote the account?  550 happens 
now or does it?

Because its quite possible that the Facebook user may be active there 
but never at yahoo.com.

There has to be other integration considerations. Yahoo.com may be 
able to use these RRVS transactions as a way to re-activate or better 
"Keep Alive" accounts at the host system.  This will prevent it from 
expiring for example.  I think if this is left only for 550 responses, 
then there is less potential harm.

Anyway, I think the proposal needs more generic examples of how this 
can used and integrated, what times are compared and whether or not 
ultimately, this about adding a new RRVS field to user accounts, 
something that is not currently there.

The time fields we have our Wildcat! user record are:

   // history and accounting
   FILETIME CreateTime;
   FILETIME LastCall;
   FILETIME LastNewFiles;
   FILETIME ExpireDate;
   FILETIME FirstCall;
   FILETIME BirthDate;
   FILETIME LastUpdate;
   FILETIME PasswordChangeDate;

What this proposal seems to be asking that we add:

   FILETIME RRVS;

But how/when it is set or cleared?  By whom?

-- 
HLS

---

From: Dave Cridland <[email-masked]>
Date: Wed, 13 Nov 2013 22:34:33 +0000

On Wed, Nov 13, 2013 at 9:18 PM, Hector Santos <[email-masked]> wrote:

> I was surprised you pulled the header.
>

FWIW, me too. I understood the logic behind having a header as fallback,
just wanted it as a fallback to an extension that would be used in
preference.

Dave.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 13 Nov 2013 16:05:05 -0800

> just wanted it as a fallback to an extension that would be used in

I guess I misunderstood the sentiment then.  Sorry about that.  I'll go
back a version and then apply the nits that have otherwise been posted, and
do an update.

Ned, if you go back one version to the draft that had both, was there any
specific text you would suggest we add based on your experience with
implementation?

-MSK

---

From: Kurt Andersen <[email-masked]>
Date: Wed, 13 Nov 2013 18:49:45 +0000

We would find it difficult to implement an extension any time soon as well. We are quite happy sending with the header.

--Kurt Andersen
  LinkedIn

On 2013-11-12 18:20 , "Bill Mills" <[email-masked]<mailto:[email-masked]>> wrote:

-bill

Regards,
John Levine, [email-masked]<mailto:[email-masked]>, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.