.invalid (was Re: Internal LAST CALL)

New Message Reply About this list Date view Thread view Subject view Author view

From: Henry Spencer (henry@spsystems.net)
Date: Tue Jun 04 2002 - 17:36:29 CDT


On Tue, 4 Jun 2002, John Stanley wrote:
> >Nobody is proposing that spam avoidance be done by simply appending
> >".invalid" to a valid domain name.
>
> Please read the draft.

I have. Moreover, I actually paid attention to Charles's last-call
deadline for comments.

> It says:
> the From-content SHOULD then be an address which ends in the top
> level domain of ".invalid" [RFC 2606].
> If it ends in .invalid, it isn't an address...

How so? The draft does not define "address", but the very same paragraph
you are quoting from (and the ones around it) clearly make a distinction
between an "address" and a "valid address". In fact, only a few lines
down we have the note:

        ...Whether or not
        a valid address can subsequently be extracted from such an
        address falls outside the scope of this standard (though it
        would be pointless to use a disguise so easily penetrable).

I see nothing here that specifically requires changing, although the
chance of other careless readers making the same mistake might perhaps be
reduced with small wording improvements.

> If you want to redefine the Sender header to be inserted anytime the
> injecting agent "cannot determine sameness", then be honest and do so in
> that section. Don't hide it as a sub-thought somewhere else.

I think you are reading too much into an unintentional quirk of wording,
but this could probably do with fixing up (presumably by inserting some
"to the best of the implementation's ability" wording into Sender).

> We explicitely tell users they are permitted to avoid using their "real"
> email address in an article, and then do not prohibit servers from simply
> inserting a guess at the "real" address without that user's permission.
> That's two-faced and hypocritical.

The standard is primarily addressed to implementors, not users. It is
normal that a standard has to be understood as a whole, not as isolated
sound bites taken out of context. The standard is written properly here:
it specifies how an invalid address might be included, but then -- in an
annotation for that very same section -- warns that the intent might be
defeated by a feature which is sometimes desirable for other reasons.

> >This fully conforms to RFC 2606's definition of ".invalid": "for use in
> >online construction of domain names that are sure to be invalid and which
> >it is obvious at a glance are invalid".
>
> 1. If you cannot tell at a glance that "joe@bite.me.you.damn.spammers" is
> invalid...

How is my *software* supposed to determine that? Remember that address
mangling is often a trifle more subtle than this example. One can attempt
to legislate that only "obvious" mangling be used, but this ends up being
a great deal more complex than a simple requirement that ".invalid" be
appended. Which is harmless and potentially helpful; what exactly is your
complaint about it?

For that matter, how is (say) a native Chinese speaker, who doesn't know
much colloquial English, supposed to determine that?

No, hoping that the mail will bounce is not satisfactory. For one thing,
I don't want to waste my time composing a reply to some jerk who didn't
provide a valid reply address, so I want to know about it beforehand.

And what about the terser jerk who writes it "joe@bite.me", without
considering that .me may be a valid TLD?

> 2. If a server cannot determine that stanley@skyking.oce.orst.edu is the
> same entity as stanley@peak.org, that is not my problem and should not
> become such by permitting an injecting agent to insert a spammable
> address...

This depends very much on circumstances. Some organizations (e.g.
universities) may wish to require that the poster's actual address appear
in at least one place in the message, for practical or legal reasons. A
blanket prohibition is inappropriate.

You are, of course, free to post only with news software of your choice.
Do speak to the implementors of your news software about this. Writing
suitable code for them would be even more helpful.

> 3. News has no need at all for a means of constructing domain names that
> are "obvious at a glance" invalid, since news has no business doing
> anything with the content of the From header and cannot "glance" at the
> content even if it did.

Followup agents often include facilities to send private replies by mail,
rather than posted followups, and hence news software can quite
legitimately wish to examine, and assess the validity of, the address in
the From header. "Mail-Copies-To: poster" may make this a requirement
even when the response is meant as a posted followup.

> The summary is this: if we are going to tell people how to formulate an
> entry for the From header that isn't an address, then we should continue
> that support and prohibit second-guessing by the news system.

We are not telling naive users anything; we are telling implementors what
they may and may not do. The way for a user to determine such things is
by reading a suitable tutorial, not a standard. Such tutorials may well
have to be software-specific or even site-specific, explaining what is and
is not allowed and how (if at all) to get desired effects.

                                                          Henry Spencer
                                                       henry@spsystems.net


New Message Reply About this list Date view Thread view Subject view Author view


This archive was generated by hypermail 2b29.