Subject: Re: [apps-discuss] Back to draft-ietf-appsawg-rrvs-header-field-05 (was Re: Scope of protocol authority)

From: Eric Burger <[email-masked]>
Date: Wed, 1 Jan 2014 10:27:38 -0500

I would offer we “say what we mean.” What Murray wrote here is a concise explanation of why there are two mechanisms, one sort of broken, one harder to get deployed. I am guessing non-Apps AD’s and other reviewers will have similar issues with the appearance of a half-hearted attempt at a mechanism (headers) embedded with the right mechanism (SMTP extension).

Putting the one sentence you have below about the SMTP extension being easier to implement and that the extension does the right thing under what today looks like all circumstances but will be quite a while before it will be ubiquitous will help on many fronts:
	1. It makes it very clear (if up front, like in the Abstract) this document talks about two distinct mechanisms for achieving the goal of RRVS and how to make these two, distinct mechanisms interoperate if all goes well.
	2. People like me at review time will not freak out about having two distinct mechanisms for achieving the goal of RRVS, one of which is very complicated and likely to be very brittle (headers) and the other which is solid, but hard to deploy (SMTP extension).
	3. People implementing the specification will have clear guidance that if they are to implement one thing, it should be the SMTP extension. It also lets them know that if they implement the header, they need to pay particular attention to getting all of the subtleties right (like when to strip out the header, when to ignore it, when to put it in, etc.).

Happy New Year.
- Eric

On Dec 31, 2013, at 8:25 PM, Murray S. Kucherawy <[email-masked]> wrote:

> On Tue, Dec 31, 2013 at 11:55 AM, Eric Burger <[email-masked]> wrote:
> 
> No veto here, just pointing out that we are in a circular loop of shifting requirements and a realization and ignoring of the reality of the network topology this draft is supposed to be addressing.
> 
> 
> I don't understand why there's a perception of shifting requirements.  Rather, the two approaches have different capabilities and attempt to address different parts of the ecosystem.  The SMTP extension route is architecturally speaking more correct for reasons identified in the draft -- and according to Ned at least, easier to implement -- while the header field has a much lower barrier to entry and actually is in production use.
> 
> There isn't a single true topology to address here.  The sender can decide which method is most practical given its own operational and security concerns.
> 
> -MSK

---

From: Hector Santos <[email-masked]>
Date: Thu, 02 Jan 2014 13:16:10 -0500

At this point as the proposal is written, due to what appears to have 
a high design change complexity in integrated Gateway, MSA, MDA and 
MTA components (keeping the MUA out for the moment), with the many 
unknowns of what are the necessary, shared and minimum process model 
parameters on both ends, I can only feasibly consider this proposal at 
the 5322.RRVS header  exploratory and testing level. For authorized 
relays (direct vs indirect is a moot point, since it all paths must be 
considered), it will be a transparent passthru operation.  So I agree 
with the idea that 5322.RRVS should be the main focus for all 
compliant systems to follow.  At ESMTP there are still other 
considerations such as VRFY.

Even for 5321, while we won't advertise a ESMTP RRVS service until 
RRVS an be fully tested and understood, for local user reception 
(MSA/MDA behavior), this will allow sysop level programmable 5322 
filtering scripts to be available at the 5321.DATA level before the 
EOD (End of Data) server response is provided.  While there is higher 
payload overhead, this does avoids accept/bounce attack potentials.

Currently, I see no interop sites to test with.  I was under the 
impression Yahoo/Facebook are currently in 5322.RRVS production mode. 
I don't see this with testing new signups at these services using our 
domains. So it must be a domain by domain consideration if this is in 
production and currently only between Yahoo/Facebook and perhaps 
others we are not privy too.  It would nice to see interop sites and 
interop reports of what is needed and what new problems were created.

We must keep in mind what the proposed idea would be advocating to all 
in the application hosting service bureau world that it is now 
relatively secure and safe to begin a practice offering reusable email 
addresses.

Even for our own support site, we still get tons of emails (most 
likely spam) for long forgotten, expired and deleted users.  All 
immediately rejected at SMTP and our stats since 2003 consistently 
show a high 60% rejection rate at the RCPT level.  They come from all 
over.  So the idea of now allowing all or some of these addresses to 
be potentially reused comes with the high potential of getting new 
legacy spam.

   Operations may need to inform new owners of ids that their has been
   a continued history of rejects to the transferred id.  In fact, perhaps
   RRVS should recommend that ESPs consider not transferring an id until
   a Quiet Time period has been reached (1 year?).

By promoting a new RRVS feature in our package, while our own 
installation and deployment might disable it for own usages, we need 
to be careful on making any claims to customers that they COULD enable 
it with some degree of secured confidence for success.  Currently I 
don't see that yet.

-- 
HLS

On 1/1/2014 10:27 AM, Eric Burger wrote:
> I would offer we �say what we mean.� What Murray wrote here is a concise explanation of why there are two mechanisms, one sort of broken, one harder to get deployed. I am guessing non-Apps AD�s and other reviewers will have similar issues with the appearance of a half-hearted attempt at a mechanism (headers) embedded with the right mechanism (SMTP extension).
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>