Subject: [apps-discuss] Erratum #404, RFC 2645 (ODMR)

From: Barry Leiba <[email-masked]>
Date: Tue, 15 May 2012 11:03:48 -0400

As I'm clearing out reported errata:

What is the current state of deployment of On-Demand Mail Relay
(ODMR), SMTP with Dynamic IP Addresses (RFC 2645)?
   http://tools.ietf.org/html/rfc2645

Does anyone have a comment on this ancient erratum on it?:
   http://www.rfc-editor.org/errata_search.php?eid=404

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 15 May 2012 16:40:41 +0100

>     http://www.rfc-editor.org/errata_search.php?eid=404
This looks reasonable to me.

---

From: Ned Freed <[email-masked]>
Date: Tue, 15 May 2012 10:15:07 -0700 (PDT)

>    http://tools.ietf.org/html/rfc2645

We've supported both server-side ODMR as well as old-style TURN (with
authentication restrictions) for a long time. I haven't seen a problem report
recently; that may indicate that people are using it without any trouble or
that it isn't being used.

>    http://www.rfc-editor.org/errata_search.php?eid=404

The erratum appears correct to me. That said, we've never really supported the
ODMR model of grouping retrievals by domain. The customers who initially
requested support for ODMR wanted more flexibility than that. So we support
granularity down to the address level, and I suppose if you wanted to you could
select based on content.

Because of that, we originally rejected any ATRN that specified a domain as
invalid, and if memory serves we used a 550 code for that. But I believe
someone had an implementation that always included a parameter, so we changed
it so that parameters were simply ignored.

I don't believe we've ever had a request to support client-side ODMR.

				Ned

---

From: SM <[email-masked]>
Date: Tue, 15 May 2012 10:20:13 -0700

>    http://www.rfc-editor.org/errata_search.php?eid=404

 From Section 5.2.1 (quoted in erratum #404):

   "If the authentication used by the customer does not provide access to
    all of the domains specified in ATRN, the provider MUST NOT send mail
    for any domains to the customer; the provider MUST reject the ATRN
    command with a 450 code."

The error code is incorrect for a rejection.  The author (of the RFC) 
generally has a good reason for the text in his documents.  I would 
defer to him as I may be missing some subtlety in the text.

In Section 7:

   "450  ATRN request refused"

That may explain why the 450 code was chosen for Section 5.2.1.  The 
notes from the erratum mentions that:

   "If the ODMR client repeats the ATRN request in this situation, it will
    be rejected again."

That seems to make sense.  However, the temporary error may have been 
chosen in this case to signal to the customer that a retry is possible.

Regards,
-sm

---

From: Barry Leiba <[email-masked]>
Date: Tue, 15 May 2012 13:54:21 -0400

> generally has a good reason for the text in his documents.  I would defer to
> him as I may be missing some subtlety in the text.

He's not responding, which is why I posted here.

> That may explain
...
> That seems to
...
> However, [...] may have

Thanks, but I'm not looking for speculation.  Speculation won't help
me correctly classify the erratum.

So far, the sense I get is that this should be "Verified".
Does anyone have a good reason to think it should be "Rejected"?  I
can't imagine that "Held for Document Update" would be right, but I'll
entertain arguments, if any are there.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Thu, 17 May 2012 11:21:14 -0400

> entertain arguments, if any are there.

I have marked this erratum as "Verified".

Barry