Xref: utzoo comp.mail.sendmail:408 comp.mail.uucp:2647 comp.unix.questions:11158 Path: utzoo!attcan!uunet!mcvax!hp4nl!ace!henk From: henk@ace.nl (Henk Hesselink) Newsgroups: comp.mail.sendmail,comp.mail.uucp,comp.unix.questions Subject: Re: smail vs. sendmail Message-ID: <581@ace.nl> Date: 18 Jan 89 00:32:33 GMT References: <398@atcmpe.UUCP> <2754@mhres.mh.nl> Sender: henk@ace.nl Reply-To: henk@ace.nl (Henk Hesselink) Organization: ACE Associated Computer Experts bv, Amsterdam Lines: 115 In article <2754@mhres.mh.nl> jv@mhres.mh.nl (Johan Vromans) writes: >From article <398@atcmpe.UUCP>, by gertjan@atcmpe.UUCP (Gertjan Vinkesteyn): >> In this version I am missing support for Cc: fields and Reply-To: and >> In-Reply-To: fields. Especially the absence of a Cc: field scanner can cause >> mail to bounce between major backbones like in the following example: >> >> From: gertjan@atcmpe >> Cc: gertjan >> To: user@hp4nl >> results in >> From: gertjan@atcmpe >> Cc: gertjan@hp4nl.nluug.nl >> To: user@hp4nl >> at the target site. > >This is not caused by smail2.5, but by the backbone which doesn't >handle cc's properly. This is not caused by improper handling of Cc's by the backbone, but by improper handling of same by the MTA at "atcmpe". Your answer indicates a misunderstanding of the function of an MTA: an MTA is *required* to fully qualify an address when crossing a domain boundary, and in the light of the brain-damage present in some UA's it is not a bad idea to do this for *all* simple local-parts (those with no hostname). The problem stems from misunderstanding the way sender and recipient addresses are processed by sendmail. With respect to From: lines: to help dumb UA's (such as AT&T's stone-age mail) along, sendmail will add a From: line to the message header if such a line is not already present (the format of this line is defined by the `q' macro). Many configuration files simply generate a correct address in $q, and leave it at that. At the same time, the To: line is qualified or not, presumably as the sender specified to the UA. Therefore, presto, mail works. This is, however, only by virtue of the special (or lack of) processing for these specific headers: *all* sender and recipient addresses are processed by the mailer specific rewriting rulesets, and therefore it is there that all simple local-parts, or at least those which will cross a domain boundary, should be qualified. As a result, Cc:/Reply-To:/etc. headers will all magically be correctly qualified. An aside: gertjan@atcmpe.UUCP (Gertjan Vinkesteyn)'s remark that the addition of "hp4nl.nluug.nl" to the Cc local address causes bouncing is incorrect: there is no gertjan on that machine, and hence *one* mail will be returned to "gertjan@atcmpe" stating this. > Unfortunately, RFC822 does not define what >to do in the above case. RFC822 is crystal clear on this point (6.6.2 Abbreviated Domain Specification): When a message crosses a domain boundary, all addresses must be specified in the full format, ending with the top-level name-domain in the right-most field. It is the responsibility of mail forwarding services to ensure that addresses conform with this requirement. > The backbone treats an address without >domain as "local" (as all sendmail based MTAs do). Another >opinion - and more logical - is to interpret CC-addresses relative >to the sender of the message. So the mailers can leave this field >alone, and the user agent can handle replys accordingly. The backbone treats an address without a domain as local, as all MTA's *should* do. Interpreting *any* simple local-part relative to the sender is a gross hack, and one which won't even always work: one problem is that the munging that sender addresses are subjected to may cause ambiguity (what do you do when the From: line contains a!user@b?); another problem is determing the sending host when there are multiple originators (a message may quite legally contain multiple From: mailboxes, a Sender mailbox:, and multiple Reply-To: mailboxes). By the way, note that "mailer" != MTA. > >> So if smail3.x should be accepted in netland, let it be a good MTA mailer, >> comparable to sendmail and mmdf. Proper handling of RFC822 is first demand. > ^^^^^^^^^^^^^^^^^^^^^^ >But not including sendmail bugs and cryptic configuration files. >Smail3.x is plug-compatible with sendmail. And it's worth waiting >for. Cryptic, yes: e-mail is a complex business, TANSTAAFL. Full of bugs, don't be silly: sendmail is a remarkably solid piece of software which unfortunately is delivered by many manufacturers with the most unbelievably cruddy configuration files. Certainly sendmail could be improved. For instance it should be split up into separate functional units (but watch security!); it should differentiate between header and envelope addresses; it should be easier to integrate with e.g. pathalias. I believe Keith Bostic is working on the first point, Lennart Lovstrand's IDA kit (the source modifications) solves the other problems. Smail 3.X may be a fine thing to wait for, but that's precisely the point: my mail has to go out the door *now*. Besides, e-mail being what it is, smail 3.X will have to be a fairly complex piece of software (if it's not, it will probably not be able to do what I want), so how long before it is stable enough that I can really trust it ? >-- >Johan Vromans jv@mh.nl via european backbone (mcvax) >Multihouse [A-Za-z ]* [NB]V uucp: ..!mcvax!mh.nl!jv >Gouda - The Netherlands phone: +31 1820 62944 > > -- Henk Hesselink ACE Associated Computer Experts bv. Amsterdam, The Netherlands e-mail: henk@ace.nl phone: +31 20 6646416