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:
> At 19:44 21-09-2008, Russ Allbery wrote:
>
>> 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).
>
> 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.

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.

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

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.

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

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

-- 
Russ Allbery ([e-mail])             <http://www.eyrie.org/~eagle/>