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

[Ned Freed <[e-mail]>]

> On Sat 26/Oct/2013 01:03:55 +0200 Ned Freed wrote:
> >
> > The SMTP extension turns out to be very easy to implement. The RRVS value
> > is directly attached to the address, so there only two cases:
> >
> > (1) The address is local, in which case you check the information against
> >     the account if you have it. And throw the information away no matter
> >     what.
> >
> > (2) The address is nonlocal, in which case you attach the information to
> >     the address so it can be relayed.

> I agree the extension looks easier than the header field.  However,
> the concept of "local" is not thoroughly clear.  An MTA can have both
> some sort of alias database and dot-forward recipes.  The latter can
> be scripts or other artifacts dealt with by the local MDA only.  So a
> message can be relayed even if it looked local when it was accepted.

But in both of the cases you cite, you have effectively validated the incoming
address in terms of RRVS, breaking the RRVS chain. The entire point of having
aliases and dot-forward files is to have a stable address that can be
redirected in various ways.

Of course nothing says that the forwarding address can't start a new RRVS
chain by recording when forwarding to that particular was first set up. The
only problem with that is going to be error reporting: Who do you report
the problem to so whoever owns the forwarding address can update it?

In any case, unless there's some sort of special relationship between the
forwarder and where it forwards to, the RRVS information should not carry
through an alias, redirection, whatever. And if such a relationship exists,
then I don't see much point in regarding this as anything other than a local
matter.

> I rise this in order to check how this extension would work for email
> address portability.  I client can learn a forwarding address from a
> 251/551 reply, or sending a test message with NOTIFY=SUCCESS and
> waiting for the DSN, or some other to-be-devised mechanism.  I'd call
> _email address portability_ the possibility that an MTA reliably
> stores and uses addresses learned that way.  In such scenario, RRVS
> would add the ability to tell it "go back and relearn, because
> something changed."  Does that make sense?

First of all, I don't see this RRVS into forwarding entry as having anything to
do with email address portability. Use of RRVS to insure the forwarder itself
doesn't end up forwarding to the wrong might make sense, but that doesn't
really impact the portability issue per se.

Second, the 251/551 mechanism is *very* different than a success DSN. Anyone
who updates addresses on their list in any way other than deleting it on the
basis of a DSN response is way out in the weeds - there is no DSN-based
mechanism defined for updating addresses. The x.1.6 status code for "mailbox
has moved" explicitly says "no forwarding address". 

As for 251/551, I'm afraid I regard the whole approach as obsolete. The main
problem is security: As noted in section 7.2 of RFC 5321, a MITM attack on such
mechanisms can be used to redirect not only the current but all future
messages. Absent far more ubiquitous use of security on relay connections, this
whole approach is just too risky.

All that said, if someone was, let's call it "bold" enough to enable use of
251/551, and there was a server that actually sent such replies often enough to
matter, then I fail to see much semantic difference between this and having a
user update their email address on some account using a web form or whatever.
Updating the address associated with an account obviously has to wipe out any
RRVS information on file and so should a 251/551 update.

The only wrinkle I see is that the old address does need to be notified of the
change, and that notification has to operate using the old RRVS info.

				Ned