ietf
[Top] [All Lists]

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

2008-09-25 12:33:11
(I am not a subscriber to the ietf list and would appreciate copies of
replies.)

SM <sm(_at_)resistor(_dot_)net> 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(_at_)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 (rra(_at_)stanford(_dot_)edu)             
<http://www.eyrie.org/~eagle/>
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf