Re: use of 'sendmail -t'

[Greg A. Woods]

[ On Monday, May 5, 2003 at 10:32:57 (-0400), Richard Stallman wrote: ]
> Subject: address@hidden: address@hidden: Re: [Don Saklad <address@hidden>] 
> How  to correct or bypass an error. Control-u f rmail in emacs onfencepost]]
>
> We made this change at your recommendation.  Apparently it does not work.
> Can you give us any advice?

It used to work just fine, and IIRC still does, at least for me.
Someone must have broken something else in whatever versions of software
used for testing with now.

However there's an extreme dearth of useful and meaningful information
in the following so I can't really tell what's going wrong or what
anyone else expects to happen.  The straying subject lines, including
the one this message started out with, are very confusing too.

Sendmail, Smail, Exim, Zmailer, and if I remember correctly, Postfix as
well, will each just "do the right thing" (as per RFC [2]822) if given a
'-t' option on the command line, regardless of whether there are
"Resent-*" destination headers or not.  In no case should any addresses
ever be given on the command-line when '-t' is used.  Note also that
Postfix is not (yet) fully sendmail compatible with '-t' and additional
command-line addresses.

So, in summary, yes, "sendmail -t" is definitely always appropriate in
the presense of "Resent-*" headers", for all sendmail compatible mailers
(i.e. MTAs with a "sendmail" command-line interface for message
submission), and Postfix as well (even though Postfix is only part-way
compatible with the real sendmail).

You can see this is true by doing tests similar to these:

        $ /usr/libexec/sendmail/sendmail -t -bv  
        Resent-To: <address@hidden>
        To: <address@hidden>
        
        asdf
        ^D
        <address@hidden>... deliverable: mailer esmtp, host weird.com., user 
address@hidden

        $ smail -v -bv -t
        new spool file is /var/spool/smail/input/19Ciij-001iMEC
        Resent-To: <address@hidden>
        To: <address@hidden>
        
        asdf
        ^D
        address@hidden: weird.com matched by inet_hosts router:
            routed address@hidden --> address@hidden at weird.com
              transport hint mx 1 mail.weird.com
                address hint mail.weird.com 204.92.254.2
            transport is smtp
        address@hidden at weird.com ... deliverable

(Postfix can't be tested in this way, and I don't have command-line
access to sites running Exim or Zmailer but I can assure you they'll
give identical results.)

I can't access the SMTP server on fencpost.gnu.org so I can't tell what
kind of mailer is running there.  I suspect though that's where the
problem lies.

> ------- Start of forwarded message -------
> From: Thien-Thi Nguyen <address@hidden>
> To: address@hidden
> Date: Sat, 03 May 2003 11:23:00 -0400
> Subject: address@hidden: Re: [Don Saklad <address@hidden>] How
>  to correct or bypass an error. Control-u f rmail in emacs onfencepost]
> Reply-To: address@hidden
> Sender: address@hidden
> 
> could a sendmail expert comment on whether or not unconditional "-t" in
> mail/sendmail.el `sendmail-send-it' in the presence of Resent-* headers
> is appropriate?  my gut feeling is that this change was intended as
> temporary, since the code is still there, just commented out.  Gerd does
> not remember the details.
> 
> background: the reported misbehavior is that `C-u f' in rmail on
> fencepost results in the MTA signalling error (it does not accept
> "Resent-*" headers when using "-t").
> 
> thi
> 
> 
>   ------- Start of forwarded message -------
>   From: address@hidden (Gerd Moellmann)
>   Subject: Re: [Don Saklad <address@hidden>] How to correct or bypass an 
> error. Control-u f rmail in emacs on fencepost
>   Date: 03 May 2003 16:51:11 +0200
>   
>   Thien-Thi Nguyen <address@hidden> writes:
>   
>   > i notice a 2001-03-21 change in emacs/mail/sendmail.el:
>   > 
>   >   * mail/sendmail.el (sendmail-send-it): Don't parse Resent-*
>   >   headers.  Always invoke sendmail with option -t.
>   > 
>   > that seems to trigger the problem described below.  was this change
>   > supposed to be temporary?
>   
>   I'm sorry, but I don't remember a bit of this.  Maybe some on 
>   emacs-devel remembers.
>   ------- End of forwarded message -------
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/emacs-devel
> ------- End of forwarded message -------
> 

-- 
                                                                Greg A. Woods

+1 416 218-0098;            <address@hidden>;           <address@hidden>
Planix, Inc. <address@hidden>; VE3TCP; Secrets of the Weird <address@hidden>