Path: utzoo!utgpu!news-server.csri.toronto.edu!smoke.cs.toronto.edu!rayan Newsgroups: comp.mail.misc From: rayan@cs.toronto.edu (Rayan Zachariassen) Subject: Re: Interesting header/error message Message-ID: <91May18.002007edt.1255@smoke.cs.toronto.edu> Organization: Department of Computer Science, University of Toronto References: <1991May13.033329.24202@chinet.chi.il.us> <1991May13.112332.20564@oar.net> <1991May17.225350.23454@gpu.utcs.utoronto.ca> Date: 18 May 91 04:20:24 GMT Lines: 66 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 -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.