[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: /usr/sbin/sendmail specification proposal, draft 6

quinlan@transmeta.com (Daniel Quinlan)  wrote on 13.12.99 in <199912140031.QAA21305@sodium.transmeta.com>:

>      It is recommended that applications use as few flags as
>      necessary, none if possible.

Given this (which I certainly approve of) ...

>      Some agents allow aliasing on the local system to be prevented
>      by preceding the address with a backslash.

Why do we need this?

>      -i        Ignore dots alone on lines by themselves in incoming
>                messages.  This option is ignored when -bs is used.

Just forbid using them together.

>      -oew or -ew
>                Write errors to the sender's terminal using the write(1)
>                command, if he is logged in.  Otherwise, mail errors back
>                to the sender.  If not supported, report errors in the
>                same manner as -oem.

What do we need this for?

>      -om       This option means 'me too', indicating that the sender of
>                a message should receive a copy of the message if the
>                sender appears in an alias expansion.  Ignored if aliases
>                are not supported.

AFAIK, ignored by anything except sendmail. We should not define this.

>      -t        Read the message to obtain recipients from the To:, Cc:,
>                and Bcc: headers in the message instead of from the
>                command arguments.  If a Bcc: header is present, it is
>                removed from the message unless there is no To: or Cc:
>                header, in which case a Bcc: header with no data is
>                created, in accordance with RFC 822.
>                If there are any arguments, they specify addresses to
>                which the message is not to be delivered.  That is, the
>                argument addresses are removed from the recipients list
>                obtained from the headers.  Note: some agents implement
>                this behavior in reverse, adding addresses instead of
>                removing them.  Others may disallow addresses in
>                argument list.  Therefore, applications should not put
>                addresses in the argument list if -t is used.
>                This option is sometimes ignored when not in -bm mode
>                (the default).

Can't we just disallow this? It's always nice if the program does  
something sensible with it, but if it can't be relied upon anyway,  
specifying this is, IMO, not useful.

>      -v        Be more verbose.  Additional -v options may make the
>                software increasingly verbose.

Not necessary for LSB.

MfG Kai

Reply to: