ietf-smtp
[Top] [All Lists]

rfc2821bis-03 Issue 35: remove source routes from example D.3

2007-04-30 08:10:03

Issue 35 assigned, note below.

--On Monday, 30 April, 2007 15:31 +0200 Arnt Gulbrandsen
<arnt(_at_)oryx(_dot_)com> wrote:

I like the text about source routes, however I think example
D.3 is too much of a good thing. I would like to have it
replaced by a simpler "Secondary MX" example.

Just to clarify what you are looking for, you would have me
change D.3 so it reads something like (ignoring the 2606 issue)

  Step 1 -- Source Host to Relay Host

        The source host performs a DNS lookup on XYZ.COM (the
        destination address) and finds DNS MX records specifying
        xyz.com as the best preference and foo.com as a lower
        preference.  It attempts to open a connection to xyz.com
        and fails.  It then opens a connection to foo.com, with
        the following dialogue:

    S: 220 foo.com Simple Mail Transfer Service Ready
    C: EHLO bar.com
        [...]
    C: RCPT TO:<Jones(_at_)XYZ(_dot_)COM>
    S: 250 OK
        [...]
    C: .
    S: 250 OK
    C: QUIT
    S: 221 foo.com Service closing transmission channel

 Step 2 -- Relay Host to Destination Host

        foo.com, having received the message, now does a DNS
        lookup on xyz.com.  It finds the same set of MX records,
        but cannot use the one that points to it (or to any
        other host as a worse preference).  It tries to open a
        connection to xyz.com itself and succeeds. Then we have:

    S: 220 xyz.com Simple Mail Transfer Service Ready
    C: EHLO foo.com
    S: 250 xyz.com is on the air
    C: MAIL FROM:<JQP(_at_)bar(_dot_)com>
    S: 250 OK
    C: RCPT TO:<Jones(_at_)XYZ(_dot_)COM>
          [...]
  
Is that more or less what you have in mind?   If so, two
questions for the group:

(1) Is this worth doing (I think yes -- at least the 
       C: MAIL FROM:<@foo.com:JQP(_at_)bar(_dot_)com>
needs to be fixed for consistency with other changes).

(2) Note that a side-effect of the famous issue 25 (about NDN
"bounces") is that, if the relay (foo.com) cannot verify either
the forward-pointing address (Jones(_at_)XYZ(_dot_)COM) or the
backward-pointing one (JQP(_at_)bar(_dot_)com) prior to sending back the
250 response to the RCPT command, it is in big trouble.   If we
apply this fix (or even if we don't), does it immediately go
into the Issue 25 list?

   john

<Prev in Thread] Current Thread [Next in Thread>