In <200501281744(_dot_)43383(_dot_)blilly(_at_)erols(_dot_)com> Bruce Lilly
<blilly(_at_)erols(_dot_)com> writes:
On Fri January 28 2005 11:07, Charles Lindsey wrote:
In <200501271357(_dot_)34152(_dot_)blilly(_at_)erols(_dot_)com> Bruce Lilly
<blilly(_at_)erols(_dot_)com> writes:
* 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.
Why?
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.
As clearly stated in the "Scope" section on RFC 2822, the "Internet
Message Format" applies first and foremost to "electronic mail". Thus, if
you update RFC[2]822, your change is binding on email. But that does not
make it binding on the other protcols you mention, except insofar as they
define particular forms of electronic mail.
Other protocols are defined by their own standards which can, and often do
(and have good reason to so do) incorporate the Internet Message Format by
reference to RFC[2]822, and do so to whatever extent is written into them.
In particular, RFC 1036 (although technically not a standard) incorporates
the Internet Message Format, subject to its own provisions and
interpetations (which, I will grant you, are often less than clearly
expressed). In particular, it is clearly stated that the From header is
Mandatory in News, and that situation will not change even if your draft
is accepted.
By way of a further analogy, it is currently the case that the Subject
header is Mandatory in News according to RFC 1036, even though it is
optional in RFC [2]822, and acceptance of your draft would simply put the
From header into the same status as the present Subject header.
Likewise, both those headers are Mandatory in the current USEFOR draft,
and there are no plans to make it otherwise. You are of course welcome to
suggest such a change in the USEFOR draft, and you are aware of the proper
channels for doing so.
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.
Very droll. I presume those are not intended to be serious suggestions.
I assume you are well aware that News agents regularly provide for
articles to be presented sorted by the poster as indicated by the From
header, and that hiding articles from named posters is the commonest
application for Killfiles. Come to think of it, sorting by From header is
commonly provided in MUAs too.
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.
Yes, that would be a change to the existing syntax. Clearly, existing
agents (and modified ones too) would be unable to send replies to such
From fields (that is, after all, the purpose of the anonymity). But can you
point to some realistic scenario (or, better, some actual MUA) in which
something might actually break if such a modified header were to arrive at
an agent? After all, all that a user agent expects to do in that situation
is to display and/or print the header correctly.
As a matter of curiosity I tried relaying such messages (telnet to port 25
of my own machine). Sendmail was happy to accept them at face value. It
recognized the display-names in both cases. They appeared intact in my
POP3 box and the MUA I tried to read them with had no problems in
displaying them, including sorting them by From header. Of course, one
successful experiment does not prove very much.
On the other hand, when I tried the same experiment with no From field at
all, it confused sendmail utterly (note that my use of sendmail was for
relaying, and not as a submission agent). Upon finding no from header, it
promptly inserted one "From: Charles Lindsey
<chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk>"
which, fortuitously, was correct. But for that to happen to an anonymous
message received from outside would be intolerable.
And one failed epxperiment does, unfortunately, prove a lot.
(My MUA, BTW, was not particularly bothered by the missing From field, and
was happy to sort it before all others.)
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.
I have email from John Klensin, whom I take to be well versed in these
matters, to the effect that the relevant standards require negative
caching to be properly implemented.
And he also indicated that, if he were ever to revise RFC 3696, he would
consider making a special case for reserved TLDs such as those mentioned
in RFC 2606.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave,
CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5