At 19:44 21-09-2008, Russ Allbery wrote:
(I am not a subscriber to the ietf list and would appreciate copies of
replies.)
Cc as requested.
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.
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.
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.
In this case, it may be better to violate the "SHOULD" and provide an
valid mailbox to which replies can be sent (second choice).
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.
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.
This wouldn't be a gateway; it would be transmission of a news article
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.
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.
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.
Each implementation might use a different header field name. It's
might become a problem in future.
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.
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf