Re: Last Call: draft-ietf-usefor-usepro (Netnews Architecture and Protocols) to Proposed Standard

[Russ Allbery <[e-mail]>]

(I am not a subscriber to the ietf list and would appreciate copies of
replies.)

SM <[e-mail]> writes:

> Section 3.4 of this I-D states that:
>
>   "Contrary to [RFC2822], which implies that the mailbox or mailboxes in
>    the From header field should be that of the poster or posters, a
>    poster who does not, for whatever reason, wish to use his own mailbox
>    MAY use any mailbox ending in the top level domain ".invalid"
>    [RFC2606]."
>
> The use of an invalid email address for the author can be a problem if the
> message goes through a news-to-mail gateway.  Section 3.10.1 (Duties of an
> Outgoing Gateway) doesn't mention what should be done in such a case.
> Section 3.6.2 of RFC 2822 mentions that:
>
>   "In all cases, the "From:" field SHOULD NOT contain any mailbox that
>    does not belong to the author(s) of the message."
>
> Should such messages be discarded by a news-to-mail gateway as they are
> not meaningful in that medium?

The message is still meaningful; however, it violates a SHOULD in RFC 2822
(well, sort of, depending on how you interpret "belong" in the case of an
address that by definition doesn't belong to anyone).

I think a gateway has two acceptable choices: preserve the From header and
violate the SHOULD, or replace the From header with some contact address
for the gateway (a copy of the Sender header, for example).  From a
quality of implementation perspective, as a consumer of a gateway, I'd
much prefer the former behavior.

Regardless, however, news-to-mail gateways are not standardized by this
draft, so I don't think this is an issue for this document.  See 3.10.1:

   From the perspective of Netnews, an outgoing gateway is just a
   special type of reading agent.  The exact nature of what the outgoing
   gateway will need to do to articles depends on the medium to which
   the articles are being gated.

I think work on a best-practices guide for gateways would be great, but I
think the e-mail side of the gateway is outside the scope of this
document.

> That could be avoided by encapsulating the message in a new message and
> sending it with Content-Type application/news-transmission.

This wouldn't be a gateway; it would be transmission of a news article
through e-mail.  See 3.10:

   A gateway transforms an article into the native message format of
   another medium, or translates the messages of another medium into
   news articles, or transforms articles into proto-articles for
   injection into a separate Netnews network.  Encapsulation of a news
   article into a message of MIME type application/news-transmission, or
   the subsequent undoing of that encapsulation, is not gatewaying,
   since it involves no transformation of the article.

> In Section 3.5.1:
>
>   "The proto-article is sent as an email with the addition of any
>    header fields (such as a To header field) required for an email."
>
> The To header field is not required; the From header is.  I suggest:
>
>    The proto-article is sent as an email with the addition of any
>    header fields required for an email as defined in RFC2822.

Yes, thank you.  I now have:

   2.  The proto-article is sent as an email with the addition of any
       header fields required for an email as defined in [RFC2822], and
       possibly with the addition of other header fields conventional in
       email such as To and Received.  The existing Message-ID header
       field SHOULD be retained.

> Section 3.10.2 recommends the following for an incoming gateway:
>
>  "If the original message already had a Sender header field, it SHOULD be
>   renamed so that its contents can be preserved."
>
> The draft doesn't specify to what the header should be renamed.  I
> suggest creating a new header field for it.
>
>   If the original message already had a Sender header field, it SHOULD be
>   renamed to original-sender so that its contents can be preserved.
>
>     original-sender          =   "Original-Sender:" mailbox CRLF
>
> A request to IANA to update the the Permanent Message Header Field
> Repository with the following is required:
>
>    Header field name:  Original-Sender
>    Applicable protocol:  Netnews
>    Status:  standard
>    Author/Change controller:  IETF
>    Specification document(s):  This document (section 3.10.2)

Hm.  Well, if we were to add a new header field, it really needs to go
into USEFOR and not here, since USEFOR is the canonical document for
header fields for netnews articles.  USEFOR has already gone through Last
Call, however.

I can see your point here, but I'm not sure the lack is particularly
important.  I'd really rather not see us make further changes to USEFOR;
generally an X-* header is used for this and is adequate in practice.

> In Section 3.10.3, it is mentioned that:
>
>  "The news-to-mail gateway adds an X-Gateway header field to all
>   messages it generates."
>
> It may be better to depreciate the use of X- headers.

Well, this is very explicitly an example based on a specific
implementation, which happens to use an X-* header.  But I can see where
this would be less than ideal.  However, as above, I'm hesitant to invent
a new header for this purpose and add the necessary machinery for
registering it when there is no standardized existing practice and it's
not clear what issues are involved in picking a header field,
standardizing its format, and so forth.

One of the problems is that the working group is very low on resources for
taking on much more work at this point.

-- 
Russ Allbery ([e-mail])             <http://www.eyrie.org/~eagle/>
_______________________________________________
Ietf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf