smail vs. sendmail

[Henk Hesselink]

In article <2754 at mhres.mh.nl> jv at mhres.mh.nl (Johan Vromans) writes:
>From article <398 at atcmpe.UUCP>, by gertjan at 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 at atcmpe
>> 	Cc: gertjan
>> 	To: user at hp4nl
>> results in 
>> 	From: gertjan at atcmpe
>> 	Cc: gertjan at hp4nl.nluug.nl
>> 	To: user at 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 at 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 at 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 at 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 at 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 at ace.nl
phone:  +31 20 6646416