Re: draft-lilly-from-optional-01.txt
ned+ietf-822@mrochek.com Thu, 24 February 2005 19:20 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 j1OJKabT059254; Thu, 24 Feb 2005 11:20:36 -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 j1OJKaSL059253; Thu, 24 Feb 2005 11:20:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-822@mail.imc.org using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1OJKRFs059228 for <ietf-822@imc.org>; Thu, 24 Feb 2005 11:20:27 -0800 (PST) (envelope-from ned+ietf-822@mrochek.com)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: TEXT/PLAIN; CHARSET="us-ascii"
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LL6EC6YYKW00005Q@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf-822@imc.org; Thu, 24 Feb 2005 11:20:20 -0800 (PST)
From: ned+ietf-822@mrochek.com
Cc: ietf-822@imc.org
Date: Thu, 24 Feb 2005 10:14:04 -0800
In-reply-to: "Your message dated Thu, 24 Feb 2005 15:06:51 +0000 (GMT)" <ICF8nF.10s@clerew.man.ac.uk>
Message-id: <01LL6IT7FRKQ00005Q@mauve.mrochek.com>
References: <ICD72M.F7B@clerew.man.ac.uk> <200502231343.10444.blilly@erols.com> <ICF8nF.10s@clerew.man.ac.uk>
Subject: Re: draft-lilly-from-optional-01.txt
To: Charles Lindsey <chl@clerew.man.ac.uk>
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>
> In <200502231343.10444.blilly@erols.com> Bruce Lilly <blilly@erols.com> writes: > > On Wed February 23 2005 07:37, Charles Lindsey wrote: > > > This latest draft fails to address the problem I reaised earlier, namely > > > that omitting the From field altogether breaks a widely deployed MTA, > > > namely sendmail (and maybe others too) which is regularly configured to > > > insert a From field of its own choosing if it finds none present already. > > MTAs do not alter content; they are forbidden to do so. RFC 2821 does distinguish between SMTP systems that don't modify messages (relays) and ones that do (gateways). But not only are gateways not prohibited, there are plenty of cases where content is supposed to be modified during transit. An obvious example of this is 8bit to 7bit downgrading of MIME messages. Another example is: http://www.ietf.org/internet-drafts/draft-ietf-fax-esmtp-conneg-13.txt which has been approved as a proposed standard. And then there's http://www.ietf.org/internet-drafts/draft-ietf-opes-smtp-use-cases-00.txt which I believe allows for modification of both envelope and content. > > MSAs can be > > configured to do so, but are recommended to tread lightly. > You fail to distinguish between what MTAs "do" and what they are > "supposed" to do (or not do). Sadly, in the real world, the perfect and > ideal MTA does not exist. It appears that one widely deployed MTA does the > "wrong thing". There may be others. We need to know. We already do know: Alteration of message content between submission and delivery is done routinely for all sorts of reasons, some good and some not so good. Pretending otherwise is simply not realistic. I will also add that blaming sendmail for this or getting wrappped up in terminology (e.g., a gateway can do blah blah but an MTA cannot) is pointless and silly. However, it isn't clear to me that the reality that messages are routinely modified by the transport infrastructure in and of itself poses a unsuperable obstacle for the draft being discussed here. To the extent that message modification impinges on missing From fields, I believe they do so by filling in the field with "something". Common choices for "something" include: (0) The envelope from address (if present). (1) An address derived from available authentication information. (The information can come from SASL AUTH, TLS, or even some entirely external mechanism like RADIUS.) (2) A known-bogus address (e.g., missing-address@missing-domain) (3) A mail administrator address of some sort. The only one of these that poses a significant problem is (1) since it can have the effect of revealing exactly the information the sender needed to have hidden. The others mostly have nuisance value and nothing else. (1) is a real risk and needs to be called out in the draft, but I don't think the practice is so common that by itself it will preclude deploying this change. However, I worry that this draft isn't viable for a different reason: At present a message without a From: field is syntactically illegal. Ten years ago the governing principle in handling syntactically illegal email was to "be liberal in what you accept". But that was before spam became such a problem. These days one of the things spam filters commonly do is to check various aspects of message syntax, including but not limited to the message having all the mandatory header fields. Failure to comply with the syntax rules increasingly tends to get your message labelled as spam. (As a side note, an out-of-the-box SpamAssassin setup doesn't appear to care about missing From: fields, but SpamAssassin is hardly the only spam filter out there.) This issue is exacerbated by the fact that the spam landscape changes constantly and so do the countermeasures undertaken to stop it. Even if you assume SpamAssassin is the norm and that using the absence of a From: field as a check for possible spam doesn't happen at all currently, all it would take would be a major influx of spam without From: fields to change this. And I somehow doubt that arguments that this breaks the ability to send mail anonymously will impress the folks that build anti-spam software much if at all. Another major problem is that the draft as written deals with the technical issue of making From: optional but doesn't discuss the myriad security issues that surround the idea of anonymous email. IMO it is borderline irresponsible (*) to publish a document that discusses this one small aspect of email anonymity while not providing any guidance about the more general set of issues here. If this is to move forward this material needs to be provided - possibly by a companion document. Ned (*) It is precisely because the potential consequences of breach of anonymity are so grave that this omission is of such great concern.
- Re: MTS transparency and anonymity Keith Moore
- Re: MTS transparency and anonymity Keith Moore
- Re: MTS transparency and anonymity Hector Santos
- Re: MTS transparency and anonymity Frank Ellermann
- Re: MTS transparency and anonymity Frank Ellermann
- Re: MTS transparency and anonymity Frank Ellermann
- Re: MTS transparency and anonymity Frank Ellermann
- Re: MTS transparency and anonymity Tony Finch
- Re: MTS transparency and anonymity Frank Ellermann
- Re: MTS transparency and anonymity Tony Finch
- Re: MTS transparency and anonymity Keith Moore
- Re: MTS transparency and anonymity Tony Finch
- Re: MTS transparency and anonymity Keith Moore
- Re: MTS transparency and anonymity Keith Moore
- Re: MTS transparency and anonymity Tony Finch
- Re: MTS transparency and anonymity Keith Moore
- Re: MTS transparency and anonymity Tony Finch
- Re: MTS transparency and anonymity Tony Finch
- Re: MTS transparency and anonymity Charles Lindsey
- Re: MTS transparency and anonymity Keith Moore
- Re: MTS transparency and anonymity Tony Finch
- Re: MTS transparency and anonymity Bruce Lilly
- Re: MTS transparency and anonymity Bruce Lilly
- Re: MTS transparency and anonymity Bruce Lilly
- Re: MTS transparency and anonymity Tony Finch
- Re: MTS transparency and anonymity Tony Finch
- Re: MTS transparency and anonymity Bruce Lilly
- Re: MTS transparency and anonymity Keith Moore
- Re: MTS transparency and anonymity Keith Moore
- Re: MTS transparency and anonymity Tony Finch
- Re: MTS transparency and anonymity Bruce Lilly
- Re: [0.0.0.0] Keith Moore
- Re: MTS transparency and anonymity Keith Moore
- Re: MTS transparency and anonymity Keith Moore
- Re: MTS transparency and anonymity Tony Finch
- Re: MTS transparency and anonymity Bruce Lilly
- Re: [0.0.0.0] Russ Allbery
- Re: draft-lilly-from-optional-01.txt Laird Breyer
- Re: [0.0.0.0] (was: MTS transparency and anonymit… Claus Assmann
- Re: MTS transparency and anonymity Bruce Lilly
- Re: MTS transparency and anonymity Keith Moore
- Re: MTS transparency and anonymity Frank Ellermann
- Re: draft-lilly-from-optional-01.txt Bruce Lilly
- Re: draft-lilly-from-optional-01.txt Bruce Lilly
- Re: MTS transparency and anonymity Bruce Lilly
- Re: MTS transparency and anonymity Frank Ellermann
- Re: MTS transparency and anonymity Laird Breyer
- Re: MTS transparency and anonymity Keith Moore
- Re: MTS transparency and anonymity Bruce Lilly
- Re: MTS transparency and anonymity Keith Moore
- Re: MTS transparency and anonymity Arnt Gulbrandsen
- Re: MTS transparency and anonymity Keith Moore
- Re: MTS transparency and anonymity Keith Moore
- Re: MTS transparency and anonymity Bruce Lilly
- Re: MTS transparency and anonymity Arnt Gulbrandsen
- Re: MTS transparency and anonymity Keith Moore
- Re: MTS transparency and anonymity Bruce Lilly
- Re: MTS transparency and anonymity Arnt Gulbrandsen
- Re: MTS transparency and anonymity Frank Ellermann
- Re: MTS transparency and anonymity Keith Moore
- Re: MTS transparency and anonymity Frank Ellermann
- Re: Use of Sender in authentication considered un… Keith Moore
- Re: Use of Sender in authentication considered un… SM
- Use of Sender in authentication considered unacce… Keith Moore
- MTS transparency and anonymity (was Re: draft-lil… Keith Moore
- Re: draft-lilly-from-optional-01.txt Charles Lindsey
- Re: draft-lilly-from-optional-01.txt SM
- Re: draft-lilly-from-optional-01.txt Charles Lindsey
- Re: draft-lilly-from-optional-01.txt Frank Ellermann
- Re: draft-lilly-from-optional-01.txt Laird Breyer
- Re: draft-lilly-from-optional-01.txt Bruce Lilly
- Re: draft-lilly-from-optional-01.txt ned+ietf-822
- Re: draft-lilly-from-optional-01.txt Bruce Lilly
- Re: draft-lilly-from-optional-01.txt ned+ietf-822
- Re: draft-lilly-from-optional-01.txt Russ Allbery
- Re: draft-lilly-from-optional-01.txt Charles Lindsey
- Re: draft-lilly-from-optional-01.txt Charles Lindsey
- Re: draft-lilly-from-optional-01.txt Russ Allbery
- Re: draft-lilly-from-optional-01.txt Bruce Lilly
- Re: draft-lilly-from-optional-01.txt Charles Lindsey
- Re: draft-lilly-from-optional-01.txt Bruce Lilly
- draft-lilly-from-optional-01.txt SM
- Re: MTS transparency and anonymity Tony Finch
- Re: MTS transparency and anonymity Bruce Lilly
- Re: MTS transparency and anonymity Keith Moore
- Re: MTS transparency and anonymity Tony Finch
- Re: MTS transparency and anonymity Bruce Lilly
- Re: MTS transparency and anonymity Bruce Lilly
- Re: MTS transparency and anonymity Charles Lindsey
- Re: MTS transparency and anonymity Keith Moore
- Re: MTS transparency and anonymity Bruce Lilly
- Re: MTS transparency and anonymity Frank Ellermann