les@chinet.chi.il.us (Leslie Mikesell) (05/13/91)
I noticed this header on an inbound message: ------- Illegal-Object: Syntax error in From: address found on relay.cs.toronto.edu: From: Bruce D.Becker <bdb@becker.UUCP> ^ ^-illegal period in phrase \-phrases containing '.' must be quoted ------- Is this really an error? Does anyone else add headers like this? Les Mikesell les@chinet.chi.il.us
karl.kleinpaste@osc.edu (05/13/91)
les@chinet.chi.il.us writes:
From: Bruce D.Becker <bdb@becker.UUCP>
^ ^-illegal period in phrase
\-phrases containing '.' must be quoted
Is this really an error? Does anyone else add headers like this?
See a related thread in comp.mail.sendmail, "Free Standing Periods."
Yes, it's technically invalid; the derivation of the header ends in
"<phrase> <route-addr>" where a <phrase> is a sequence of <words>,
which in turn must be either a <quoted-string> or a sequence of
<atoms>. <Atoms> may not contain <specials>. You can derive it in a
minute or three's consideration of the alphabetic grammar listing at
the end of 822.
Rayan's mailer is unquestionably to be awarded Most Picky Mailer Ever
Devised, but it has the good taste to deliver anyhow, in view of the
wide disregard for this particular bit of syntactic pedanticism.
--karlfrotz@dri.com (Frotz) (05/16/91)
karl.kleinpaste@osc.edu writes: ]les@chinet.chi.il.us writes: ] From: Bruce D.Becker <bdb@becker.UUCP> ] ^ ^-illegal period in phrase ] \-phrases containing '.' must be quoted ] Is this really an error? Does anyone else add headers like this? ]Rayan's mailer is unquestionably to be awarded Most Picky Mailer Ever ]Devised, but it has the good taste to deliver anyhow, in view of the ]wide disregard for this particular bit of syntactic pedanticism. Illegal-Object: Syntax error in To: address found on relay.cs.toronto.edu: To: John D.Fa'atuai <lsuc!utai!uunet!dri.com!frotz> ^ ^-missing end of address \-extraneous tokens in address So, is this a problem with me, or with the address sent to me? -- John "Frotz" Fa'atuai frotz@dri.com (email@domain) Digital Research, Inc. uunet!drivax!frotz (bang!email) c/o MIS Dept. 408/647-6570 or 408/646-6287 (vmail) 80 Garden Court, CompRm 408/649-3896 (phone) Monterey, CA 93940 408/646-6248 (fax)
lear@turbo.bio.net (Eliot) (05/18/91)
karl.kleinpaste@osc.edu writes: >Rayan's mailer is unquestionably to be awarded Most Picky Mailer Ever >Devised, but it has the good taste to deliver anyhow, in view of the >wide disregard for this particular bit of syntactic pedanticism. The above situation is a recipe for disaster. Imagine, if you will, a message sent to a very large international mailing list with a completely trashed To: header, but with the envelope intact. What is a mailer to do? [a] Bounce the message as undeliverable. [b] Continue to process the message, possibly logging an error. [c] Continue to process the message AND send an error to the sender. If you said [c], that's what sendmail does; and it's wrong. There was an excellent example of this exact problem last week (see Erik Fair's note to a bunch 'o lists including tcpip and risks). The message caused every sendmail that touched it to send an error message back to the sender, in some cases multiple times. Distributed systems are funny that way. If you said [a], I'd argue that you're still wrong, so long as the message will remain in an environment where an envelope exists, as you would be violating the robustness principle. That leaves [b] (preferably logging an error message). -- Eliot Lear [lear@turbo.bio.net]
dennis@gpu.utcs.utoronto.ca (Dennis Ferguson) (05/18/91)
lear@turbo.bio.net (Eliot) writes: > >karl.kleinpaste@osc.edu writes: > >>Rayan's mailer is unquestionably to be awarded Most Picky Mailer Ever >>Devised, but it has the good taste to deliver anyhow, in view of the >>wide disregard for this particular bit of syntactic pedanticism. > >The above situation is a recipe for disaster. > >Imagine, if you will, a message sent to a very large international >mailing list with a completely trashed To: header, but with the >envelope intact. What is a mailer to do? > > [a] Bounce the message as undeliverable. > [b] Continue to process the message, possibly logging an > error. > [c] Continue to process the message AND send an error to > the sender. > [...] > >That leaves [b] (preferably logging an error message). Actually I think [b] is what the mailer in question does. In addition to this it appears to remove the offending header, whatever it was, replacing it with a fancy error message (which must have taken a week of coding to get to come out right) in a dreaded Illegal-Object: header and synthesizing a (syntactically correct) replacement from the envelope if the header is one which really needs to be there. This, of course, means only the recipient finds out about the error, which I always thought was odd since the recipient is far less likely to be able to do anything about it. It appears the implementor was smarter than I. Passing on a message which you know contains an error is at least as bad as sending back an error (I'd argue that sendmail has both these bugs, and both were equally important in causing the trouble you mentioned). If "Continue to process the message" doesn't include fixing it up so that downstream mailers won't see an error as well I think you are violating the robustness principle even more seriously than you would be by bouncing it. Zmailer may be obnoxiously picky, but I think this is all in the cause of robustness and is probably appropriate. Dennis Ferguson
rayan@cs.toronto.edu (Rayan Zachariassen) (05/18/91)
Eliot et al, the ZMailer action in the case of the recent Sendmail flap would have been essentially as Dennis described: completely nuke the bad address header and replace it with a correct synthesized one and an opaque header complaining about the error. This action corresponds to none of the choices presented but it is, I think, robust. Of course, if a badly-formed message had been submitted to a ZM in the first place, it would have been spit back right there with a graphic admonition (literally, and no, it only took a day :-). Dennis says: >This, of course, means only the recipient finds out about the error, >which I always thought was odd since the recipient is far less likely >to be able to do anything about it. It appears the implementor was >smarter than I. Scared, actually. I briefly considered sending an error message back to the postmaster at the originating site (which still would not give the Sendmail scenario, btw). For about 2 seconds. There is an incidental problem of what to do when such a message bounces (SMTP "Mail from:<>" being irrelevant since no other transfer protocol has the concept of `absense of sender') and I didn't want to think up some magic loop-avoidance scheme. What really convinced me to NOT do this was that I don't have a particular desire to be hated by all the world's users and postmasters. [begin slight exaggeration for emphasis] 90% of broken hosts don't have a postmaster. 90% of the remainder have postmasters that don't want to know and don't care. 90% of those that do, don't know what to do to fix it, or cannot due to site policies ("We'll run whatever the vendor provides, period."). That leaves about 1 per thousand of hosts out there that will be able to fix problems due to such a notification. Lets see, that makes around 500 hosts on the internet. They're probably just fine already and no-one needs to tell them... so what's the point. I'm resigned to hoping that recipients seeing flagged syntax errors will get curious and ask their own postmasters, or their correspondents, and that very slowly the general level of awareness may be raised. Karl, as for the rather draconian enforcement of the rules: I think of a protocol spec as an obligation agreed to by the MTA implementation of the protocol. Namely: "If I receive a <specification>-conforming message, then it will be understood properly and processed." If there is some kind of protocol error, all bets are off. This general description is the only assumption you can make about a remote MTA's behavior. Therefore you *really* want to eliminate the "all bets are off" possibility. You do that by making very sure that messages sent out are as spec-conformant as possible. In the case of RFC822 the major part of the protocol spec is the syntax. It is also the only part that is universally applicable to '822-like environments. Hence the pendantic syntax checking. The RFCs also define Internet semantics which fall on their face when dealing with non-Internet environments. Therefore address semantics are generally left to the graces of a mail guru who one hopes has a deep hatred for all things mailish. Otherwise they not be guru yet. rayan -- "It's 11pm, does *your* Sendmail deal properly with mail groups?" Novice: What's "Sendmail"? Beginner: What's a "mail group"? User: What do you mean "properly"? Expert: Hmm, never thought of that. Wizard: YES! Guru: Like, who cares... Honeyman's corollary: It's only mail.
lear@turbo.bio.net (Eliot) (05/19/91)
Rayan: Thanks for the entertaining reply (particularly the .signature!). As you say, it's the "all bets are off" area that you want to avoid. Would ZMailer reconstruct the To: line by placing some bogus address? BTW, I'm I misunderstood which direction the error was going. <> can be replaced with an alias to an address linked to /dev/null, if need be. The goal of <> was to keep error messages from looping. If a message is bounced back to your site, and you throw it away, it may be the best you can do (for example converting <> to bionet!nobody would be fair for a UUCP gateway). -- Eliot Lear [lear@turbo.bio.net]
karl.kleinpaste@osc.edu (05/20/91)
rayan@cs.toronto.edu writes:
Karl, as for the rather draconian enforcement of the rules: I think of
a protocol spec as an obligation agreed to by the MTA implementation of
the protocol.
Oh, no argument from me, I agree entirely. I'm quite pleased that
ZMailer did what appears to be the penultimate Right Thing by fixing
it and passing it. What shocks me is that you (an admitted header
hacker) and Henry (vocal header anti-hacker) can co-exist in the same
universe, much less the same university -- matter/anti-matter
reactions come to mind.
:-),
--karlrayan@cs.toronto.edu (Rayan Zachariassen) (05/21/91)
Eliot, # Would ZMailer reconstruct the To: line by placing some bogus address? No, the replacement address is exactly the corresponding envelope address in all its gloryness. If that too is bad, an earlier stage of processing has already detected and rejected the message or compensated for the bogosity, depending on the situation. # <> can be replaced with an alias to an address linked to /dev/null, ... Yes, however that means the code *requires* cooperation from the mail administrator (to, say, put an appropriate nobody alias in place). This is not something I'd do without very very good reasons, since the required cooperation is guaranteed to cause confusion and problems. I think it is bad enough that the various error messages needed by the code are kept in external files, though in that case cleanliness won out. As usual it comes down to (personal) priorities and philosophy. Karl, Reminds me of my reaction when someone in passing told me "Oh, Henry got his Sun", and the image that came and stuck to my mind was a little baby with a Deep Authoritative Voice. Sigh. You can't know what it is like to be surrounded by anti-matter... there is a vocal minimalist contingent at UofT, notably Geoff, Henry, Mark Bartelt, and occasionally Norman Wilson. You know the old story about never discussing politics or religion with friends? Well, header hacking comes in heavy in those categories... I think we all think it is a vile (tm Collyer) thing but they seem to feel it is very rarely necessary whereas my experience convinces me it is a necessary evil. Then there was the time when I had made some changes to rmail... I introduced a bug which caused messages longer than the stdio buffer size to lose their second stdio buffer block. I didn't realize there really was a bug until I got a message IN SCREAMING UPPERCASE, from Henry, complaining about his mail getting mangled. It turns out that of all the UUCP mail coming through the new rmail, mail from utzoo!henry was the only stuff running into a problem. You see, Henry's messages are usually > BUFSIZ long. I don't think Henry is quite convinced yet that I wasn't purposely and personally targeting him (I wasn't Henry, *honest*!). Still makes me blush. We've since thought of some interesting variations on this scheme: Henry-filters in the news system. We could give him a signature of *our* choice for a change... rayan -- Spencerisms: The first line always seems to make | Henry Spencer @ U of Toronto Zoology a funny combination when read aloud. | henry@zoo.toronto.edu utzoo!henry This has been a test message of the | Henry Spencer @ U of Toronto Zoology constant broadcast system. | henry@zoo.toronto.edu utzoo!henry Anyone for a Usenix contest about | Henry Spencer @ U of Toronto Zoology signature quotes? | henry@zoo.toronto.edu utzoo!henry This could go on forever, but a certain | Henry Spencer @ U of Toronto Zoology daemon is going to get very grouchy. | henry@zoo.toronto.edu utzoo!henry ;-))