Re: Mandatory From field, anonymity, and hacks

Bruce Lilly <blilly@erols.com> Fri, 28 January 2005 22:45 UTC

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0SMjNAR097681; Fri, 28 Jan 2005 14:45:23 -0800 (PST) (envelope-from owner-ietf-822@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0SMjNkJ097680; Fri, 28 Jan 2005 14:45:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-822@mail.imc.org using -f
Received: from smtp01.mrf.mail.rcn.net (smtp01.mrf.mail.rcn.net [207.172.4.60]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0SMjM7i097674 for <ietf-822@imc.org>; Fri, 28 Jan 2005 14:45:23 -0800 (PST) (envelope-from blilly@erols.com)
X-Info: This message was accepted for relay by smtp01.mrf.mail.rcn.net as the sender used SMTP authentication
X-Trace: VC1WfoFM4GATKH7EKoz2FgsuCc5c0GesaBQODFpe9Cc=
Received: from 65.105.220.34.ptr.us.xo.net ([65.105.220.34] helo=mail.blilly.com) by smtp01.mrf.mail.rcn.net with asmtp (Exim 3.35 #7) id 1Cuerh-00039V-00; Fri, 28 Jan 2005 17:45:21 -0500
Received: from marty.blilly.com (localhost [127.0.0.1]) by mail.blilly.com with ESMTP id j0SMijmV013844(8.13.1/8.13.1/mail.blilly.com sendmail.mc.mail 1.18 2004/05/15 07:23:45) ; Fri, 28 Jan 2005 17:45:00 -0500
Received: from localhost (localhost [127.0.0.1]) by marty.blilly.com with ESMTP id j0SMiiRk013843(8.13.1/8.13.1/blilly.com submit.mc 1.1 2003/08/26 22:21:33) ; Fri, 28 Jan 2005 17:44:45 -0500
From: Bruce Lilly <blilly@erols.com>
Reply-To: ietf-822 <ietf-822@imc.org>
Organization: Bruce Lilly
To: ietf-822 <ietf-822@imc.org>
Subject: Re: Mandatory From field, anonymity, and hacks
Date: Fri, 28 Jan 2005 17:44:42 -0500
User-Agent: KMail/1.7.2
Cc: Charles Lindsey <chl@clerew.man.ac.uk>
References: <40F6919A.7010607@erols.com> <200501271357.34152.blilly@erols.com> <IB1BGp.6pJ@clerew.man.ac.uk>
In-Reply-To: <IB1BGp.6pJ@clerew.man.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200501281744.43383.blilly@erols.com>
Sender: owner-ietf-822@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-822/mail-archive/>
List-ID: <ietf-822.imc.org>
List-Unsubscribe: <mailto:ietf-822-request@imc.org?body=unsubscribe>

On Fri January 28 2005 11:07, Charles Lindsey wrote:
> 
> In <200501271357.34152.blilly@erols.com> Bruce Lilly <blilly@erols.com> writes:
> 
> >As a result of our discussion starting July 15, 2004, I
> >have prepared an Internet Draft; draft-lilly-from-optional-00.txt
> >should be available from the usual places [*].  Public comments
> >may be posted to the ietf-822 list; private comments to the
> >author are also welcome.
> 
> >* E.g. ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-lilly-from-optional-00.txt
> 
> I have several problems with this.
> 
> 1. Is it really necessary to modify RFC 822 and well as RFC 2822?

Yes.

> 2. 
>    This memo (if approved) updates the Internet Message Format
>    specification [N1.STD11], [N2.RFC2822] as used by various
>    applications (electronic mail [I3.STD10], [I1.RFC2821], Usenet news
>    [I4.RFC1036], Internet fax [I5.RFC2305], VPIM [I6.RFC3801], EDI
>    [I7.RFC1767], [I8.RFC1865], etc.).  It applies across the board to
>    applications using the Internet Message Format.  However it does not
>    discuss similarly named fields in unrelated formats and protocols
>    such as [I9.HTTP] or [I10.SIP].
> 
> I think it is most unwise to attempt to impose this change on
> protocols/applications other them electronic mail without first consulting
> the working groups of other bodies responsible for those protocols.

It imposes no changes on protocols/applications other than those
that use the Internet Message Format. The quoted text above clearly
and specifically says so.  As for WGs and "other bodies", there
is certainly opportunity for comment now, as well as at the
time of a Last Call prior to submission for publication.

> In the case of Netnews, in particular, I would regard this proposal as
> totally unacceptable, since it is clearly desirable and widely expected
> that it will be possible to identify the (claimed) poster of any Usenet
> article, even if only by the pseudonym that poster chooses to be known by.

That is certainly possible via a number of existing mechanisms
(From field with an "effective and useful for replies" [RFC 2821
section 3.8.4] mailbox, a standard Comments or Organization (for
Usenet specifically) field w/o a  mailbox, or indication in the
body of the message), or an extension field which is not an
address field could be defined.  Making the From field optional
for the purpose of permitting anonymity and to appropriately
handle the case of an author with no Internet mailbox any of
those mechanisms which do not require an effective and useful
Internet mailbox.

> I would sugges that, for Usenet, at least the display name should be
> provided when no email address is available. That would leave the
> following possibilities:
> 
> 	Allow the <mailbox> to be omitted when <display-name> is present.
> 	Allow some form of dummy <mailbox>, such as '<>'.

No, in the From field that would be incompatible with long-standing
field syntax specifications, as specifically discussed in the draft
and as discussed here (specifically including "<>" and syntactically
legal but semantically empty alternatives) this past Summer.

> 	Encourage the use of clearly unresolvable domains, such as those
> 	ending in '.invalid'.

Unresolvable domain names present problems for DNS, as discussed here
in July, where that (".invalid") proposal was called a "showstopper".
In light of the "SiteFinder" debacle (see the reference in the draft),
that's a serious matter, since it's not always possible -- on the
Internet -- to distinguish a non-existent domain; it certainly might
be impossible off the Internet, such as on the non-Internet side of
a gateway.

> It is, in
> any case, not clear that some existing user agents will not barf at the
> proposed total absence of the From header.

Well, they certainly won't be able to compose responses to the
author, but (as discussed in the draft) that is not something
that one could do for the case of an anonymous author or an
author with no Internet mailbox, which are the cases covered
by the draft.

> 4. 
>    Some documents have suggested use of the reserved ".invalid" TLD
>    (top-level domain name) [I18.BCP32] to provide some degree of
>    anonymity.  With relaxation of the requirement for a From field in
>    the Internet Message Format, such hacks and their negative impact on
>    the root name service are unnecessary, at least within the scope of
>    Internet Messages.
> 
> That reference to "hacks" and "negative impact" is hardly fair.

It is based on the discussions here in July.  At the moment,
the two RFCs that do so are SIP documents, which is specifically
outside of the scope of the draft; however making the From field
optional would obviate any tendency to repeat such a mistake in
the messaging area.

> I have 
> been assured by people who understand the DNS system better than I do
> that it is a common and recommended practice for DNS failures to be
> cached,

If it were a common practice, there wouldn't be an RFC (2308)
lamenting the lack of such optional caching of negative responses
in practice.  Moreover, if that practice were in fact widespread
on the Internet, it would not help in the case of inappropriate
positive responses (as in the SiteFinder debacle), nor would it
help systems not directly connected to the Internet (as in
offline message composition, and non-Internet and/or non-mail
systems which make use of a gateway for sending to Internet
mailboxes). 

> Moreover, '.invalid' can, and should be,
> built into agents so that they do not waste time even trying.

Absolutely not; RFC 3696 specifically discusses such nonsense --
the only way to determine if a hypothetical domain name is
valid is to query DNS.  Building special hardwired cases into
code has caused, and can be expected to continue to cause,
problems.