Murray.pa@XEROX.ARPA (12/20/84)
We are in the final stages of bringing up a mail gateway between Grapevine, our research mail system, with names like "Murray.PA" and our product mail system with names like "Hallam G. Murray:OSBU North". Note the nasty things like periods and spaces in the new names. Does anybody out there have a system that will get in serious trouble if we send you a message with a return-path containing spaces? By "serious" I mean crash your system or break your mail server rather than generating obscure error messages when somebody tries to reply to a message with an unparsable header. Do I need to drop everything and hack our mail gateway to prevent names with spaces from escaping into the internet? A few people have been testing things for the past month. So far, nobody has complained to me that their new name was causing unreasonable problems, like preventing them from exchanging mail with somebody else. I am expecting to encounter some rough edges. I won't get upset if a few users can't exchange mail with a few obscure sites, but I will have to do something if too many sites can't live with our new names. Assuming that our names contain spaces, will you be able to send mail to us? Assuming that we get the quotes right and such, will you be able to receive mail from us? Will the corner of your mail processing software that automatically generates headers to help you answer a message still work? Should I send a test case? Anybody want a summary of the answers I get back? Do you know of any other pitfalls in this area that I might have overlooked?
Murray.pa@XEROX.ARPA (05/22/85)
A month or so ago, Bruce sent an innocent msg to INFO-NETS that caused a lot of confusion. It seems as though lots of systems out there crashed every half-hour or so whenever MC tried to (re)transmit Bruces' msg on to them. The error message was something like "no closing quote". I think some systems can't tolerate mismatched quotes in the From field of the header, and MC managed to drop one. I think the From line looked like this when it left here: From: "Bruce A. Hamilton.OsbuSouth"@Xerox.ARPA The line that was killing CIT-VAX was: From: <Hamilton.OsbuSouth"@Xerox.ARPA> Can anybody fill me in on the fine print? Is there something special about the From line, or will any header line containing mismatched quotes cause the same problem? Any reason why it crashes the system instead of logging a message and blundering on? The only victim I've been in contact with is CIT-VAX. I think they are running a vanilla 4.2BSD. How many other systems got cought by the same bug? Did your system crash? Is there a reasonable bug fix? Any hope of fixing MC? ... Sending mail that crashes systems is high on my list of things not to do, especially when you can kill many systems with only one message. Currently, I have a filter installed that rejects any outgoing msg if the From field needs quoting. Is that good enough? (If you want a test case, just let me know.) ----- Part of our mail system makes heavy use of spaces in names. I'm getting a lot of flak about rejecting all these messages. We started seriously using quoted names with spaces early this year. There were various bugs that had to be fixed, both here and at other sites nearby where we exchange lots of mail. Things calmed down after a while. Then Brian Reid started complaining. He is the postmaster at a site that was relaying some of our mail on to the UUCP world. Several of the next layer of machines didn't know about quotes, and the rejections were landing in Brian's mailbox. I "solved" that one by translating all the spaces to underbars in the return-path in the envelope. I did that because I "knew" that none of our names contained any underbars so I could make the reverse translation without fear of breaking anything. Is the space/underbar substitution universal enough that I can do it to the whole header without fear of mangling some address that really should have a space in it? I haven't yet managed to convince myself that I won't provoke a really obscure problem if I just blindly "fix" all the quoted spaces to/from underbars. Have all the (flakey) Unix systems out there established a de-facto addendum to RFCs 821/822 that prohibits quoted strings? ----- Does/will the X400 world have spaces in names, or will there be spaces in names by the time they get mapped/translated into RFC 821/822 format?
Geoff@SRI-CSL.ARPA (the tty of Geoffrey S. Goodfellow) (05/23/85)
Hal Implementing "solutions" like changing spaces to underbars just to keep people's mailers which can't grok legal protocol from crashing seems inappropriate to me, at least in the long term. If quoted spaces are indeed legal to send, well send them for heavens sakes. If they crash people's mailers, then those mailers should be fixed -- plain and simple. All it takes is one wizard to discern the fix, post it, and everyone else should follow suit. Thank goodness its a solid bug you've found, and not one that would cause peoples mailer's to crash on every 3rd message to come by with a quoted space when there's a full moon out or something like that. g
greep@rand-unix.ARPA (Steve Tepper) (05/23/85)
I will seize the current fracas about spaces in names as an opportunity to give vent to a long-standing gripe, which has to to with network protocols in general but is a particularly sore point when it comes to mail. My complaint is that, given the lack of any network police, the decision as to who has to change what to make it work with something else is often more of a political question than a technical one. Typically the scenario is something like this: User Foo@FooHost wants to send mail to Bar@BarHost. Now it turns out that the person who maintains the software used at BarHost (who likely doesn't even work there, unless BarHost is a one-of-a-kind operating system) has decided to "improve" the mail system in some way which is uncontestably at variance with the standard, with the result that some mail breaks. A cleanliness freak would, justifiedly, state flatly that the burden is on either BarHost or their software maintainer to get it fixed. The reality is unfortunately different. It may be that Bar@Barhost is Foo's project sponsor, or someone else of sufficient stature that Foo considers the ability to communicate electronically with Bar a high-priority matter. Complaining that the problem is at BarHost may be morally satisfying but does not get the message delivered, especially if the person who made the offending change is obstinate and claims that his "improved" version is so obviously superior that it is incumbent on the rest of the world to mimic his changes until they become a de facto standard. The outcome: some poor soul at FooHost has to figure out what BarHost's mail server is now willing to accept and hack up FooHost's mailer to accomodate it, without disrupting other mail services from FooHost in the process. I am exerting considerable restraint here by refraining from mentioning the names of any guilty parties (and all the cases I dealt with were too far in the past to be of any immediate concern), but I'm sure other people have also found themselves in the unpleasant situation of being the person who had to "fix" something to accomodate someone else's non-standard "improvements".
Margolin@MIT-MULTICS.ARPA (Barry Margolin) (05/23/85)
To answer the question that appeared at the end of the original message,
X.400 should not have any problems in this respect. X.400 messages are
binary data structures, and the protocols between mailer processes are
also binary messages. There is no text parsing involved. For instance,
rather than having a mailer daemon transmit Character strings are
encoded as a type word followed by a length byte followed by the
specified number of characters (I am purposely simplifying, leaving out
things like the character set identifier). No ambiguity is possible
within the protocol (of course, user interfaces are another problem, as
they must translate between this form and printed form).
barmarzben@umd5.UUCP (05/23/85)
Quoted spaces in headers broke my mail program too, but I *think* I have it
patched up now. I agree that to fix the problem (you listening Brian?) is far
better than to kluge around it...
I am just patching in code to add a "Message-Id:" line to outgoing messages
from my system (this is homebrew from the bottom up, Univac 1100 assembly).
I have two questions on whether this is going to break anybody's mailers.
Here is an example message I just sent up:
--------------------------------------------
From ZBEN@UMD2.ARPA Thu May 23 09:14:19 1985
Received: from UMD2.ARPA by UMD5.ARPA (4.9/a/4.7)
id AA09744; Thu, 23 May 85 09:14:13 EDT
Date: Thu, 23 May 85 09:14:24 EDT
From: Ben Cranston <ZBEN@UMD2.ARPA>
To: LOUIE@UMD5
Cc: ZBEN@UMD5
Subject: Message-ID line
Message-Id: <M1985$001009.016118BEN.ZBEN@UMD2.ARPA>
Status: RO
Does it look reasonable?
-zben
--------------------------------------------
Question one: Is the length of the data in the "Message-Id:" going to give
anybody problems? The M198x$xxxxxx is a unique sequence number. The
016118BEN is a unique per-user identifier I can use to "Witch-Hunt" anyone
sending obscene or objectionable mail. The "ZBEN" is just the name of the
mailbox, and is limited to 12 characters.
Question two: I have seen problems with dollar signs ($) in mail names
before. Advisories from our VM/CMS system come from a virtual machine
named "$MAILER@UMDA" and I have seen at least one system pass that on to
the user as "AILER@UMDA" - presumably because "$M" looked like a beast
called a "MACRO NAME" to SENDMAIL. I shudder to think what might have
happened if there actually HAD been a $M macro defined. So, the question
is, will the dollar sign in M198x$xxxxxx give anybody any problems?
Theoretically it may be followed by any digit, practically unless there is
a huge increase in usage of mail the digit will always be a zero.
--
Ben Cranston ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben zben@umd2.ARPAron@BRL.ARPA (Ron Natalie) (05/24/85)
AHEM. Can we please get this discussion down to only one group please.
honey@down.FUN (Peter Honeyman) (05/28/85)
geoff, oh just ducky. let's define a protocol that's incompatible with about 10,000 systems with whom we want to exchange mail, then arrogantly blast them for not following our protocol. and if innocent postmasters at gateways end up taking all the flak, well the hell with them too! perhaps you might reconsider hal's suggestion that gateways take passing notice of the requirements of non-arpa mailers. peter