Subject: [apps-discuss] Shepherding the Require-Recipient-Valid-Since Header Field

From: "J. Trent Adams" <[email-masked]>
Date: Mon, 07 Oct 2013 14:37:08 -0600

Folks -

I've been asked to help shepherd the Require-Recipient-Valid-Since
Header Field (draft-ietf-appsawg-rrvs-header-field-00) specification.

For easy reference, here's a link to the specification in the datatracker:

https://datatracker.ietf.org/doc/draft-ietf-appsawg-rrvs-header-field/

As a reminder, there was a flury of activity in early August, but the
dust seems to have settled around the initial set of comments.

As IETF 88 is just around the corner, it'd be great to see if we could
tackle any remaining issues before the moratorium on updates.  In fact,
perhaps we're close to closing out all open issues and could target
moving into last call.

Anyway, please fire off any suggestions that you'd like to see addressed.

Thanks,
Trent

-- 
J. Trent Adams

Profile: http://www.mediaslate.org/jtrentadams/
LinkedIN: http://www.linkedin.com/in/jtrentadams
Twitter: http://twitter.com/jtrentadams

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 7 Oct 2013 16:16:52 -0700

> Anyway, please fire off any suggestions that you'd like to see addressed.
Thanks, Trent.  The authors have nothing outstanding here, so any
outstanding comments or even some reviews would be great.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Mon, 14 Oct 2013 13:59:41 -0400

As a potential implementer, I have reviewed the draft and much of the 
follow up discussions.

I believe this should be a dual solution with an ESMTP Extension with 
the payload 5322 RRVS header solution.  This will resolved two issues:

1) The optimization and high rate of rejection at the RCPT TO state 
machine with 55x responses.

2) Two different scripting tools used for Envelope checking (4 
parameters;  IP, client machine name, return path and forwarding path) 
and Payload (5322 parts) filtering at DATA EOD (End of Data).

Overall the draft is promoting a shift to the higher overhead DATA 
payload rejection with very little utility and general purpose.  I 
won't repeat but I agree 100% with all the security related concerns 
mentioned.  I don't see the pros outweighing the cons here.

This solution works best in isolated proprietary or joint venture 
environments but not in a public environment.  We have sysadm (system 
administrator) scripting tools to purge accounts because on their own 
rules. I can see some value in processing inbound but don't see why 
the exporting (creation of RRVS headers) of mail should expose these 
generally very private information, not only private to the user but 
private to the vendor BI (business intelligence).

Maybe the true value of this proposal is just in the proposed reply 
status code that may help some clients. But ultimately, it is a common 
and general 55x response and behavior despite the details.

If the proposal expects ESMTP support for extended replies, then it 
should be using EHLO rather than HELO in its example.   In other 
words, the receiver processing an HELO client COULD BE disabling any 
extended responses. I have to double check, but maybe it MUST disable 
the extended responses when there is a fallback HELO support mode 
activated.

I think this proposal should be an experimental as there is really no
"standard" approach to cleaning up and reusing expired user accounts. 
Perhaps this is more of an informational status document allowing 
Yahoo and Facebook to describe how they plan to cooperate with 
automated messages and to clean up old user accounts. More of a 
problem statement. I can see better and more secured methods than this 
"proposed standard" method described.

--
Hector Santos, CTO
http://www.santronics.com

-- 
HLS

---

From: "John Levine" <[email-masked]>
Date: 14 Oct 2013 20:01:31 -0000

>outstanding comments or even some reviews would be great.

It's nearly ready to ship.  In section 3, on page 4, delete step 3,
delete the last sentence of step 5 (which will now be step 4) and
add:

5.  If the address is a role account as listed in [ROLES], deliver the
    message whether or not the address has been under continuous
    ownership.  If the address has not, alert the recipient when she
    reads the message that it was likely intended for one of her
    predecessors, if it is practical to do so.

6.  Otherwise, if the address has not been under continuous ownership,
    reject the message.

If I register foo.example, and I get mail to [email-masked], with a
RRVS header from a year ago, it's intended for the previous
registrant, which is useful to know.  (On the other hand, try sending
mail to [email-masked].)

You might put a note in 8.2 reminding people that if a domain has been
registered before, you don't know what addresses the prior owner
assigned, hence no addresses can be known not to have had a single
owner, or not to have existed at all.

Since the question has arisen again, I agree that an SMTP extension would
be a bad idea, for the reasons listed in section 5.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 17 Oct 2013 00:29:20 -0700

> mail to [email-masked].)

The current set of steps does wind up always delivering to role accounts.
The only thing different that I can see here is the insertion of an
interstitial that notifies the recipient of the likely intent.  I think
that's possibly best done in prose outside of the list of steps, so I'll
handle your suggestion that way.

> owner, or not to have existed at all.

Added.

> be a bad idea, for the reasons listed in section 5.
What do others think about this?  I feel as though there's momentum toward
adding one since it's the architecturally correct thing to do, but there
will ultimately be only a few implementations and most people will just
implement the header field.  That said, there's precedent for doing both,
and only using the header field method when the data have to be tunneled,
so we could follow that precedent.

-MSK

---

From: John R Levine <[email-masked]>
Date: Thu, 17 Oct 2013 10:06:37 -0400 (EDT)

> handle your suggestion that way.

That's fine, so long as it acknowledges the underlying issue that domains 
change owners and you don't know what previous owners do.

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

---

From: "John Levine" <[email-masked]>
Date: 17 Oct 2013 14:51:36 -0000

>so we could follow that precedent.

This promises interop problems when one end only does the header and
the other end only does the SMTP extension.  So to fix that the rule
is you have to add and interpret the header if you implement the SMTP
extension, which makes the extension pretty pointless.

For people who do body filtering in the SMTP session, they're
equivalent other than the issue of mail to multiple recipients which I
think is an edge case in this application.  For people who don't,
we're more likely to know the history of a particular address at
delivery time than at SMTP time, which means that to use the
extension, now we need some A-R: like thing to remember what it said
at SMTP time, which would look an awful lot like the header.

Just the header, please.

R's,
John
R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 17 Oct 2013 10:51:24 -0700

> extension, which makes the extension pretty pointless.

It is possible (though arguably error-prone) to say at each hop: "If you're
sending this onward and the receiving MTA does the SMTP extension, then
remove the header field and use the extension; if it doesn't, add the
header field."  For example, as I mentioned in a reply to Dave Cridland,
this same method was done in RFC 6758, corresponding to the SMTP extension
defined in RFC 6710.

Alexey, if you're listening: Has this approach been successful for
MT-Priority?

-MSK

---

From: Bill Mills <[email-masked]>
Date: Thu, 17 Oct 2013 11:21:11 -0700

+1

This expresses somehting I hadn't been able to get into coherent form to say.

-bill

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

Just the header, please.

R's,
John
R's,

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