From: John Stanley (stanley@peak.org)
Date: Tue Jun 04 2002 - 15:32:42 CDT
Thu May 09 2002 - 04:07:07 CDT, Charles Lindsey (chl@clw.cs.man.ac.uk):
>I believe that the broad consensus of this group is in favour of the
>current draft, with yourself and Andrew as the only dissenters who have
>declared their position.
Hello, Charles. How quickly you forget.
Henry Spencer (henry@spsystems.net, Mon Jun 03 2002 - 09:17:27 CDT:
>On Mon, 3 Jun 2002, Frank Ellermann wrote:
>> Most participants don't like invalid addresses, but accept the
>> idea of (ab)using TLD .invalid as smallest damage in comparison
>> with me@privacy.net, "modified" addresses, or other constructs
>> to avoid spam.
>
>Then they've completely misunderstood the issue.
That's right. Anyone who wants to claim that properly munged addresses
cause any damage at all to the news system as a whole, or to specific news
servers, has had plenty of time to speak up. Claiming that ".invalid as
smallest damage" [sic] is incorrect, since "smallest" implies that there
is some difference. Zero is zero.
The only news server which properly-munged addresses caused ANY problems
for was an ancient version of First Class; a server which thought it
correct to send email to the address in the From header when the server
ran out of disk space. I think that's pretty clearly agreed upon as a
flaw, not a feature, and even then, the only "damage" was that the email
bounced. Any mail system that cannot handle a bounce is severly broken.
>Nobody is proposing that spam avoidance be done by simply appending
>".invalid" to a valid domain name.
Please read the draft. 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, but the From content SHOULD
be an address ending in .invalid. I think many people are going to read
this as "take your address and append .invalid", since that is the only
way there will be an "address" involved. However, this is still not the
serious problem. We still see:
Be warned, however, that some injecting agents which are unable
to detect that the address belongs to the poster may choose to
insert a Sender-header (6.2) or some entry in an Injector-Info-
header (6.19) which discloses some valid address for the poster.
This is still unacceptable. "...agents which are unable to detect that the
address belongs to the poster..." do not meet the criteria necessary for
insertion of the Sender header. The Sender definition says that that
header specifies the mailbox IF that entity is different than that in the
From header. "Unable to detect sameness" is not "able to detect
difference". Any injecting agent which acts this way is BROKEN and should
be explicitely prohibited, not explicitely allowed.
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.
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.
>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, that's your problem.
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 in my articles, especially without my explicit permission. No,
seeing that it has done so after the article has been distributed around
the world is not sufficient notice that it is being done. At WORST, it
should be required to present to me the ACTUAL article that will be
posted, including headers, before it is injected.
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.
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. The USER has
made his choice clear by following our instructions, the news system
should accept that choice or simply reject the article. "Fixing it" is not
an option.
I'm sure this discussion is not new, but since Charles seems to have
forgotten it, I bring it up again.