Hi,

This message is just for comment, no problems to report.

In tmail's man page I see several small errors :

1. The description of parameter -f states exactly what sendmail's
manual says about flag P, not f or r like the man page says (P is for
including a Return-path line; f or r is for using a "-f <from>" while
executing tmail).

2. The example "Mlocal ..." configuration has several confusing
details, it uses flags Pr, perhaps tmail wants both but it wasn't
clear, it uses flag + which I could not find in sendmail's manual. It
doesn't use flag m, see next point.

3. No mention is made in the man page to multiple recipients (flag m on
Mlocal configuration), I had to look at the code to see that in fact it
is supported. Perhaps there are problems with parameter -I <mailbox>
and multiple recipients, but perhaps not... something should be
mentioned.

I also think that the sample configuration should be updated to
Sendmail's standard procedure, that is: configure in the .mc file. I
did add the following 4 lines, just before including the local mailer
(adjust the path and flags as needed):

=== sendmail.mc snippet ===
define(`LOCAL_MAILER_PATH', `/usr/local/bin/tmail')dnl
define(`LOCAL_MAILER_ARGS', `tmail $u')dnl
define(`LOCAL_MAILER_FLAGS', `Pfmn8')dnl
define(`LOCAL_MAILER_EOL', `\r\n')dnl
MAILER(local)dnl

Regards.
--
René Berber

On Tue, 19 Sep 2006, Rene$Bi(B Berber wrote:
> 1. The description of parameter -f states exactly what sendmail's
> manual says about flag P, not f or r like the man page says (P is for
> including a Return-path line; f or r is for using a "-f <from>" while
> executing tmail).

tmail's man page is correct as stated: the -f or -r flag in the tmail
command line sets a Return-Path in the header that is written by tmail.

That is not the same as the P flag in sendmail's F= options.

> 2. The example "Mlocal ..." configuration has several confusing
> details, it uses flags Pr, perhaps tmail wants both

It's entirely up to you. Most sendmail.cf files do this.

> but it wasn't
> clear, it uses flag + which I could not find in sendmail's manual.

+ is a common extension to support user+mailbox addressing.

> It
> doesn't use flag m, see next point.
> 3. No mention is made in the man page to multiple recipients (flag m on
> Mlocal configuration), I had to look at the code to see that in fact it
> is supported. Perhaps there are problems with parameter -I <mailbox>
> and multiple recipients, but perhaps not... something should be
> mentioned.

You do NOT want to use flag m in the Mlocal configuation!! It is a VERY
BAD IDEA, not matter which mail delivery program you use!

The problem with sendmail's flag m is that there is only one result return
from an invocation to the delivery program. So, if delivery fails to one
recipient (perhaps because of a disk quota error), the one of the
following outcomes occurs:
a) the message is delivered to all the other recipients, but an error is
passed back to sendmail, so it will retry delivery...to everybody.
b) the error causes the message to fail delivery to all recipients, even
those that it could be delivered to, so nobody gets the message until
the problem with the one recipient is fixed.
c) the message is delivered to the other recipients, but no error is
passed back so the sender never is notified of the failure.
d) some inconsistant combination of the above.

NONE of these options are desirable; and thus flag m in Mlocal is
generally considered to be a BAD idea.

This problem is mentioned, albeit not specifically in relationship to the
Mlocal m flag, under "RESTRICTIONS" in the tmail man page.

> I also think that the sample configuration should be updated to
> Sendmail's standard procedure, that is: configure in the .mc file.

tmail was originally written before there was was such a thing.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Mark Crispin wrote:

> On Tue, 19 Sep 2006, Rene Berber wrote:
> > 1. The description of parameter -f states exactly what sendmail's
> > manual says about flag P, not f or r like the man page says (P is for
> > including a Return-path line; f or r is for using a "-f <from>" while
> > executing tmail).
>
> tmail's man page is correct as stated: the -f or -r flag in the tmail
> command line sets a Return-Path in the header that is written by tmail.
>
> That is not the same as the P flag in sendmail's F= options.
>
> > 2. The example "Mlocal ..." configuration has several confusing
> > details, it uses flags Pr, perhaps tmail wants both
>
> It's entirely up to you. Most sendmail.cf files do this.

Agree, but if I understand correctly using Pr means sendmail adds a
Return-Path line to the headers, then it runs tmail -f ... which makes
tmail add a Return-Path line to the headers, and since I looked at the
code I know that then tmail deletes the line added by sendmail... looks
like triple work to me. But I'm probably wrong since you say that it
is not the same.

> > but it wasn't
> > clear, it uses flag + which I could not find in sendmail's manual.
>
> + is a common extension to support user+mailbox addressing.

I tought so when building sendmail.cf didn't complain, but if it's not
documented...

> > It doesn't use flag m, see next point.
> > 3. No mention is made in the man page to multiple recipients (flag m on
> > Mlocal configuration), I had to look at the code to see that in fact it
> > is supported. Perhaps there are problems with parameter -I <mailbox>
> > and multiple recipients, but perhaps not... something should be
> > mentioned.
>
> You do NOT want to use flag m in the Mlocal configuation!! It is a VERY
> BAD IDEA, not matter which mail delivery program you use!

I understand the point, but on the other hand it is the default on
sendmail. It just stike me as odd when I saw in the log 6 tmail
processes instead of one, it was just different behaviour from what I'm
used.

> The problem with sendmail's flag m is that there is only one result return
> from an invocation to the delivery program. So, if delivery fails to one
> recipient (perhaps because of a disk quota error), the one of the
> following outcomes occurs:
> a) the message is delivered to all the other recipients, but an error is
> passed back to sendmail, so it will retry delivery...to everybody.
> b) the error causes the message to fail delivery to all recipients, even
> those that it could be delivered to, so nobody gets the message until
> the problem with the one recipient is fixed.
> c) the message is delivered to the other recipients, but no error is
> passed back so the sender never is notified of the failure.
> d) some inconsistant combination of the above.
>
> NONE of these options are desirable; and thus flag m in Mlocal is
> generally considered to be a BAD idea.
>
> This problem is mentioned, albeit not specifically in relationship to the
> Mlocal m flag, under "RESTRICTIONS" in the tmail man page.
>
> > I also think that the sample configuration should be updated to
> > Sendmail's standard procedure, that is: configure in the .mc file.
>
> tmail was originally written before there was was such a thing.

Understood, that's why I said updated.

Thanks for your reply, as I wrote before this were just comments not a
real problem.
--
René Berber

On Tue, 19 Sep 2006, Ren$Bi(B Berber wrote:
> Agree, but if I understand correctly using Pr means sendmail adds a
> Return-Path line to the headers, then it runs tmail -f ... which makes
> tmail add a Return-Path line to the headers,

Correct. You'll have a Return-Path from sendmail and one from tmail.

> and since I looked at the
> code I know that then tmail deletes the line added by sendmail...

Huh? tmail doesn't do any such thing.

looks

>> You do NOT want to use flag m in the Mlocal configuation!! It is a VERY
>> BAD IDEA, not matter which mail delivery program you use!
> I understand the point, but on the other hand it is the default on
> sendmail. It just stike me as odd when I saw in the log 6 tmail
> processes instead of one, it was just different behaviour from what I'm
> used.

I don't know why that is sendmail's default. It may be more "efficient"
that way, but IMHO that is outweighed by the loss of per-recipient error
handling.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.