[Top] [All Lists]

Re: Mandatory From field, anonymity, and hacks

2004-07-26 19:40:15

Keith Moore wrote:

we don't expect native MUAs to go to great lengths to prevent invalid or
unusable addresses from appearing messages. why should we impose this
burden on gateways?

In the case of an MUA, an invalid address will result in a notification
or bounce, which can be handled by the sender (for example, see RFC 2476
section 3.2).  In the case of a gateway in general, the same applies only
if both of the following conditions are met:
1. the non-Internet-mail side of the gateway has the equivalent of a
   sender envelope address
2. the gateway is able to translate that sender envelope address into
   one which is valid and usable from the Internet mail environment

Neither condition applies in the case of a Usenet news-to-mail gateway.

when gateways have to translate addresses from one format to another (as
they do between X.400 and internet mail), they should make sure that the
resulting addresses are valid syntax.  this is just sanity checking. 
the reason it's necessary is that there are usually some addresses that
cannot be translated. but that's not the same thing as ensuring that the
address is valid.

As noted above, the most important thing is that the sender envelope
address be usable. Then if there's a problem with delivery, the sender
can be informed of that fact. Next in importance would probably be
Disposition-Notification-To address if the field is present and if the
gateway and non-Internet-mail environment both support the equivalent
of disposition notifications.  Following that would be recipient
envelope address; if the message cannot be delivered to the recipient(s),
nothing that follows below matters much.  Next would be Reply-To
addresses if the non-Internet-mail side supports the equivalent and if
it is present.  The From field would be of lower importance still. To,
Cc, and Bcc header fields are of lowest importance, but they are
optional (unlike From).

[...] creating a new TLD to indicate an invalid address is probably a bad
idea even within Usenet.

Agreed. [that is a separate issue from having a known invalid TLD for
the purpose of being able to test DNS application software's handling
of nonexistent domains. Indeed, there may be justification for having
a reserved second-level, guaranteed-invalid domain name component for
the purpose of being able to test DNS implementations (not to mention
certain registrars' behavior) w.r.t. nonexistent domain names under
TLSs such as, oh I don't know,  maybe "com" or "net".  But I digress.]

rather than trying to fix internet mail to
accommodate a bad idea in Usenet, maybe the Usenet people need to come
up with a better idea.

Usenet news is an application of the RFC [2]822 Internet Message Format.
As of this time, that format requires a From field.  There exist news-to-
mail gateways, and as of this time RFC 2821 places certain requirements
on such gateways.  The combination makes standardization of use of the
.invalid TLD hack in addresses via a proposed Standards Track RFC worse
that a"a bad idea"; it's a non-starter.  So what are the alternatives?
I have proposed making the From header field optional.  That permits a
sender -- not only in Usenet news, but in general -- to omit that field
for whatever purpose suits the sender (anonymity to avoid fascist
repression, to avoid address harvesting by spammers, etc.).  According
to my reading of RFC 2821, it does not require any changes to RFC 2821 [*].
But it does provide an option for gateway implementors who care about
RFC 2821 conformance in the event of an invalid From field mailbox in
cases (such as Usenet news) where there is no equivalent of a sender
envelope address for the purpose of punting the problem back to the
sender.  As noted above, the proposal has application apart from the
Usenet news and/or gateway issues.  I believe that making From optional
is "a better idea".  If somebody foresees a problem with it, I'd like
to hear about it.  Likewise, if somebody has an equally good or better
idea, I'm open to it.

* However if the RFC 2821 requirement is relaxed, it does not adversely
affect the proposal.