RE: [Asrg] 0. General - anti-harvesting (was Inquiry about CallerID Verification)

["Chris" <rebel@rebel.com.au>]

Doesn't all this discussion prove that the interpretation of a protocol can
vary?

Therefore any attempts to use a "feature" that is disputed will probably end
up breaking some software

Regards
Chris



> -----Original Message-----
> From: asrg-admin@ietf.org [mailto:asrg-admin@ietf.org]On Behalf Of Eric
> S. Raymond
> Sent: Monday, December 01, 2003 2:42 PM
> To: Yakov Shafranovich
> Cc: ASRG; Dave Crocker
> Subject: Re: [Asrg] 0. General - anti-harvesting (was Inquiry about
> CallerID Verification)
>
>
> Yakov Shafranovich <research@solidmatrix.com>:
> > Whether the RFCs require a valid return address, or not, in
> spirit or in
> > letter of the law, is something Dave Crocker and Eric Raymond, and
> > others, who worked on the original 821 and 2821 RFCs can tell us. But
> > the fact today is that no one is expected to provide a valid address,
> > and any system relying on this, will fail in some cases unless the
> > existing RFCs are changed.
>
> The spirit of the law, at least at the time I was involved with
> RFC2822, was certainly that the return address was required to be
> valid.  As for the letter...
>
> Section 3.6.7 of RFC2822 says:
>
>    The trace fields are a group of header fields consisting of an
>    optional "Return-Path:" field, and one or more "Received:" fields.
>    The "Return-Path:" header field contains a pair of angle brackets
>    that enclose an optional addr-spec. [...]
>
> The addr-spec is optional because it maty be omitted, as in daemon
> bounces.  RFC2822 continues:
>
>    A full discussion of the Internet mail use of trace fields is
>    contained in [RFC2821].  For the purposes of this standard, the trace
>    fields are strictly informational, and any formal interpretation of
>    them is outside of the scope of this document.
>
> Thus, RFC2822 does not mandate that the address be valid.  We are
> referred to RFC 2821.  Section 4.1.1.4 reads:
>
>    When the delivery SMTP server makes the "final delivery" of a
>    message, it inserts a return-path line at the beginning of the mail
>    data.  This use of return-path is required; mail systems MUST support
>    it.  The return-path line preserves the information in the <reverse-
>    path> from the MAIL command.  Here, final delivery means the message
>    has left the SMTP environment.  Normally, this would mean it had been
>    delivered to the destination user or an associated mail drop, but in
>    some cases it may be further processed and transmitted by another
>    mail system.
>
>    It is possible for the mailbox in the return path to be different
>    from the actual sender's mailbox, for example, if error responses are
>    to be delivered to a special error handling mailbox rather than to
>    the message sender.  When mailing lists are involved, this
>    arrangement is common and useful as a means of directing errors to
>    the list maintainer rather than the message originator.
>
> I read this to mean that the Return-Path must, if present, be a
> valid mailbox for a responsible person (note the MUST).
> --
> 		<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
>
> _______________________________________________
> Asrg mailing list
> Asrg@ietf.org
> https://www1.ietf.org/mailman/listinfo/asrg


_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg