[ttn@glug.org: [gerd.moellmann@t-online.de: Re: [Don Saklad <dsaklad@gnu.org>] How to correct or bypass an error. Control-u f rmail in emacs onfencepost]]

[ttn@glug.org: [gerd.moellmann@t-online.de: Re: [Don Saklad <dsaklad@gnu.org>] How to correct or bypass an error. Control-u f rmail in emacs onfencepost]]

[Richard Stallman]

We made this change at your recommendation.  Apparently it does not work.
Can you give us any advice?

------- Start of forwarded message -------
From: Thien-Thi Nguyen <ttn@glug.org>
To: emacs-devel@gnu.org
Date: Sat, 03 May 2003 11:23:00 -0400
Subject: [gerd.moellmann@t-online.de: Re: [Don Saklad <dsaklad@gnu.org>] How
 to correct or bypass an error. Control-u f rmail in emacs onfencepost]
Reply-To: ttn@glug.org
Sender: emacs-devel-bounces+rms=gnu.org@gnu.org

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: gerd.moellmann@t-online.de (Gerd Moellmann)
  Subject: Re: [Don Saklad <dsaklad@gnu.org>] 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 <ttn@glug.org> 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
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel
------- End of forwarded message -------

Re: use of 'sendmail -t'

[Greg A. Woods]

[ On Monday, May 5, 2003 at 10:32:57 (-0400), Richard Stallman wrote: ]
> Subject: [ttn@glug.org: [gerd.moellmann@t-online.de: Re: [Don Saklad <dsaklad@gnu.org>] 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: <woods@weird.com>
	To: <woods@robohack.ca>
	
	asdf
	^D
	<woods@weird.com>... deliverable: mailer esmtp, host weird.com., user woods@weird.com

	$ smail -v -bv -t
	new spool file is /var/spool/smail/input/19Ciij-001iMEC
	Resent-To: <woods@weird.com>
	To: <woods@robohack.ca>
	
	asdf
	^D
	woods@weird.com: weird.com matched by inet_hosts router:
	    routed woods@weird.com --> woods@weird.com at weird.com
	      transport hint mx 1 mail.weird.com
	        address hint mail.weird.com 204.92.254.2
	    transport is smtp
	woods@weird.com 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 <ttn@glug.org>
> To: emacs-devel@gnu.org
> Date: Sat, 03 May 2003 11:23:00 -0400
> Subject: [gerd.moellmann@t-online.de: Re: [Don Saklad <dsaklad@gnu.org>] How
>  to correct or bypass an error. Control-u f rmail in emacs onfencepost]
> Reply-To: ttn@glug.org
> Sender: emacs-devel-bounces+rms=gnu.org@gnu.org
> 
> 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: gerd.moellmann@t-online.de (Gerd Moellmann)
>   Subject: Re: [Don Saklad <dsaklad@gnu.org>] 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 <ttn@glug.org> 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
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel
> ------- End of forwarded message -------
> 

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>

Re: use of 'sendmail -t'

[Richard Stallman]

    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.

I believe fencepost is running exim.  Can you tell me how to verify
that it is really exim?

Re: use of 'sendmail -t'

[Greg A. Woods]

[ On Tuesday, May 6, 2003 at 06:13:50 (-0400), Richard Stallman wrote: ]
> Subject: Re: use of 'sendmail -t'
>
> I believe fencepost is running exim.  Can you tell me how to verify
> that it is really exim?
 
I wasn't able to get Exim to build with just a very quick try in
NetBSD's pkgsrc, however I was able to find the following paragraph in
Exim's manual (exim-4.10/doc/spec.txt):

       If there are any "Resent-" headers in the message, an error is
       generated, and Exim gives up. RFC 2822 talks about different sets of
       "Resent-" headers (when a message is resent several times), and it is
       not at all clear how -t should operate in this situation. Experiments
       with Sendmail have shown that it amalgamates multiple sets of "Resent-"
       headers when -t is used. This does not seem to be in the spirit of RFC
       2822.

This does indeed suggest that Exim is one of the few, and maybe only,
sendmail-compatible mailer which does not support "Resent-*" destination
headers in combination with use of 'sendmail -t'.

On the other hand Exim does appear to do most of the right things for
fixing up incomplete header sets and rewriting addresses in "Resent-*"
headers that already exist.

I would suggest that the best approach for mail/sendmail.el to to take
in light of this bug would be to check which "sendmail" is available on
the host system by running "sendmail -bV" and looking for indications
that the interface is implemented by Exim.  If so then perhaps the old
code could be conditionally used.

In the mean time I will submit a proposal to Philip Hazel suggesting
that he re-evaluate his position on the support of "Resent-*" headers
when '-t' is used and hopefully Exim will soon become compatible with
Sendmail, Smail, Postfix, and other sendmail-compatible mailers.

BTW, I was able to get command-line access to a system running Postfix
and I have confirmed that Postfix does work just as Sendmail and Smail
do, with the minor exception that Postfix does not support the
additional feature of ignoring any addresses that are also specified on
the command-line with '-t'.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>

Re: use of 'sendmail -t'

[Simon Josefsson]

"Greg A. Woods" <woods@weird.com> writes:

> [ On Tuesday, May 6, 2003 at 06:13:50 (-0400), Richard Stallman wrote: ]
>> Subject: Re: use of 'sendmail -t'
>>
>> I believe fencepost is running exim.  Can you tell me how to verify
>> that it is really exim?
>  
> I wasn't able to get Exim to build with just a very quick try in
> NetBSD's pkgsrc, however I was able to find the following paragraph in
> Exim's manual (exim-4.10/doc/spec.txt):
>
>        If there are any "Resent-" headers in the message, an error is
>        generated, and Exim gives up. RFC 2822 talks about different sets of
>        "Resent-" headers (when a message is resent several times), and it is
>        not at all clear how -t should operate in this situation. Experiments
>        with Sendmail have shown that it amalgamates multiple sets of "Resent-"
>        headers when -t is used. This does not seem to be in the spirit of RFC
>        2822.
>
> This does indeed suggest that Exim is one of the few, and maybe only,
> sendmail-compatible mailer which does not support "Resent-*" destination
> headers in combination with use of 'sendmail -t'.

I believe this is a bug in Exim.  I think it is pretty clear from RFC
2822 that the first Resent-* block is the valid one, if any Resent-*
blocks exist at all.  It is unfortunate that a MUST statement wasn't
used when saying that the fields are prepended to the message.  This
was undefined in RFC 822 though.

,----
| 3.6.6. Resent fields
| 
|    Resent fields SHOULD be added to any message that is reintroduced by
|    a user into the transport system.  A separate set of resent fields
|    SHOULD be added each time this is done.  All of the resent fields
|    corresponding to a particular resending of the message SHOULD be
|    together.  Each new set of resent fields is prepended to the message;
|    that is, the most recent set of resent fields appear earlier in the
|    message.  No other fields in the message are changed when resent
|    fields are added.
`----

> In the mean time I will submit a proposal to Philip Hazel suggesting
> that he re-evaluate his position on the support of "Resent-*" headers
> when '-t' is used and hopefully Exim will soon become compatible with
> Sendmail, Smail, Postfix, and other sendmail-compatible mailers.

Ah, we agree.  Good.

Don't forget to ask for the documentation to be updated.  "-t"
currently doesn't mention Resent-* at all, in all manuals I looked in.

Re: use of 'sendmail -t'

[Richard Stallman]

    In the mean time I will submit a proposal to Philip Hazel suggesting
    that he re-evaluate his position on the support of "Resent-*" headers
    when '-t' is used and hopefully Exim will soon become compatible with
    Sendmail, Smail, Postfix, and other sendmail-compatible mailers.

That is the right solution--I wrote to him also asking for this.

Thanks.