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

From: SM <[email-masked]>
Date: Sat, 06 Sep 2008 08:36:29 -0700

At 17:06 29-08-2008, The IESG wrote:
>The IESG has received a request from the Usenet Article Standard Update
>WG (usefor) to consider the following document:
>
>- 'Netnews Architecture and Protocols '
>    <draft-ietf-usefor-usepro-12.txt> as a Proposed Standard

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?

That could be avoided by encapsulating the message in a new message 
and sending it with Content-Type application/news-transmission.  Such 
messages might show up as attachments in some MUAs though.

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.

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)

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.

Regards,
-sm 

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Russ Allbery <[email-masked]>
Date: Sun, 21 Sep 2008 19:44:51 -0700

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

SM <[email-masked]> writes:

> 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:
>
> 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.

>    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.

>    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.

> 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 ([email-masked])             <http://www.eyrie.org/~eagle/>
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: SM <[email-masked]>
Date: Tue, 23 Sep 2008 23:22:13 -0700

>(I am not a subscriber to the ietf list and would appreciate copies of

Cc as requested.

>address that by definition doesn't belong to anyone).

The message may be meaningful for a broadcast but not for two-way 
communication.  For example, if you were reading this mailing list 
and replying to this message through Netnews, I would not be able to 
send you a reply.

As obfuscated mailboxes such as example@example dot nospam dot com 
are commonly used in Netnews, proposing ".invalid" as a suffix at 
least ensures that the mailboxes is actually invalid.

>much prefer the former behavior.

In this case, it may be better to violate the "SHOULD" and provide an 
valid mailbox to which replies can be sent (second choice).

>think the e-mail side of the gateway is outside the scope of this

Section 3.10.1 mentions practices that are encouraged.  As the 
document "creates" the problem, it may be good for the document to 
address it especially given the different interpretations of 
"meaningful".  I suggest the following in Section 3.10.1:

    5.  The message should be compliant with the specifications for 
that medium.

>through e-mail.  See 3.10:

I suggested that as an alternative to work around the issue if you 
prefer not to fix the invalid address.

>        field SHOULD be retained.

I don't see the need for specifying additional headers.  You could 
keep it simple with the following:

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

>generally an X-* header is used for this and is adequate in practice.

Each implementation might use a different header field name.  It's 
might become a problem in future.

>standardizing its format, and so forth.

Implementors will likely pick X-Gateway as you mentioned that header 
name in the example.  Once people start using specific headers, it's 
difficult to depreciate them in favor of some standardized format.

Regards,
-sm

---

From: Russ Allbery <[email-masked]>
Date: Wed, 24 Sep 2008 19:35:08 -0700

SM <[email-masked]> writes:
>> 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).
>
> communication.  For example, if you were reading this mailing list and
> replying to this message through Netnews, I would not be able to send
> you a reply.

Well, the *message* may still be meaningful as part of a two-way
communication.  I get messages all the time from entities with whom I'm in
two-way communication that don't have repliable addresses (such as my
bank).  But I see your basic point.

The common gatewaying case is indeed to a mailing list.

> As obfuscated mailboxes such as example@example dot nospam dot com are
> commonly used in Netnews, proposing ".invalid" as a suffix at least
> ensures that the mailboxes is actually invalid.

Yes, that was the intent.  It's a controversial topic in Netnews.

> Section 3.10.1 mentions practices that are encouraged.  As the document
> "creates" the problem, it may be good for the document to address it
> especially given the different interpretations of "meaningful".  I suggest
> the following in Section 3.10.1:
>
>    5.  The message should be compliant with the specifications for that
> medium.

Well, I find that statement unobjectionable but essentially meaningless,
in that I don't think the document says anything substantively different
including that statement than without it.  But if it makes others feel
more comfortable, I don't object to including it.

> I don't see the need for specifying additional headers.  You could keep it
> simple with the following:
>

That provision doesn't document what happens in practice, nor would it be
possible to limit the header additions.  (For example, it's essentially
impossible to send something as an e-mail message without adding Received
headers.)  I prefer to give implementors a better idea of what to expect,
and in practice arbitrary headers will get added by the transit through
the mail system, including all sorts of X-* headers, trace headers, and
random detritus from spam filters.

It's also nearly universal current practice to add an explicit To header,
in part because of spam filtering, although there's no standards reason to
require that.

The addition of random headers, and sometimes the modification of random
headers, is why the document tries to push things towards encapsulation
instead of transformation into an e-mail message, but unfortunately most
moderation software can't cope with encapsulated articles currently.

>> 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.

> Each implementation might use a different header field name.  It's might
> become a problem in future.

Each implementation using a different header field name is perfectly fine
and doesn't pose any problems for the specific issue being addressed by
that part of the example code.

> Implementors will likely pick X-Gateway as you mentioned that header name
> in the example.

We could easily remove that specific header field name from the example
and instead just say:

    The news-to-mail gateway adds an X-* header field to all messages it
    generates.  The mail-to-news gateway discards any incoming messages
    containing this header field.

Would that be an improvement?

---

From: SM <[email-masked]>
Date: Thu, 25 Sep 2008 15:33:40 -0700

Hi Russ,

[I-D author requested Cc]

>more comfortable, I don't object to including it.

If you don't find that the addition changes anything, there is no 
point in including it.  The point was that the author address should 
be fixed if it's not according to the specifications for that 
medium.  I did not elaborate as the medium is not restricted to mail.

>random detritus from spam filters.

Okay.

>Would that be an improvement?

Yes, that's better.

Regards,
-sm

---

From: Tony Hansen <[email-masked]>
Date: Fri, 26 Sep 2008 09:42:47 -0400

I admit it: I'm not a fan of X- headers.

Why not just register a header in the header registry and be done with
it, rather than encouraging yet-another set of X-headers, all possibly
named differently? Why encourage the use of X- headers in a standards
track document?

For example, consider using Netnews-Gateway-Control in place of
X-Gateway, or some other such name,

   2.  The news-to-mail gateway adds a Netnews-Gateway-Control header
       field to all messages it generates.

and then add this to the IANA Considerations section:

   Header field name: Netnews-Gateway-Control
   Applicable protocol: mail, netnews
   Status: standard
   Author/Change controller: IETF
   Specification document(s): RFC XXXX (this document)

If you'd rather define a *set* of header names, to allow implementations
to pick their own names, then use this:

   2.  The news-to-mail gateway adds a Netnews-Gateway-Control header
       field (or a header field whose name begins with
       Netnews-Gateway-Control-) to all messages it generates.

and then add this to the IANA Considerations section:

   Header field name: Netnews-Gateway-Control
   Applicable protocol: mail, netnews
   Status: standard
   Author/Change controller: IETF
   Specification document(s): RFC XXXX (this document)

   Header field name: Netnews-Gateway-Control-* (all headers whose name
	begins with "Netnews-Gateway-Control-")
   Applicable protocol: mail, netnews
   Status: standard
   Author/Change controller: IETF
   Specification document(s): RFC XXXX (this document)

My $0.02.

	Tony Hansen
	[email-masked]