At 22:16 30-10-2002, Michael Sisolak wrote:
Several months ago the imap_sendmail.c routines were merged into the
standard Win32 sendmail.c code. One of the results of this was that
the TSendMail function gained a parameter to specifically set the mail
header return path. The imap_mail() function can use this parameter,
but the standard mail() function cannot (it is always set to NULL).
Based on the number of comments on the mail() manual pages about issues
that occur when the return path is always the sendmail_from ini value,
it appears that it would be useful to add an additional optional
parameter to mail() to set the return path.
The only downside I see to this is that the value would only work for
the internal Win32 sendmail code and not the standard Unix calls to
sendmail.
Any thoughts on this?
Another downside, is that many SMTP servers by default ignores hardcoded
Return-Path values - sendmail for instance, doesn't allow this on a
socket, and only from a trusted user who is allowed to use -f on the
command-line.
If you choose to implement this, be warned that the MAIL FROM: command may
override any attempts to set this.
I think a parameter to set the MAIL FROM: user, will work much better.
Last time I looked the 'From:' header is copied onto 'MAIL FROM:'.
Separating those will have a more flexible and cross-platform solution,
since you map that address to /usr/sbin/sendmail -f <MAIL_FROM_USER> on
*nix.
If you are going to work on this, could you please also look into
bug #20056. Changes made to the win32 sendmail back in may IIRC involved
fixes to address \n on less tolerant mailers. The problem is that MIME mail
sent through the extra headers is now broken, since \r\n\r\n is truncated
to \r\n.
Met vriendelijke groeten / With kind regards,
Webmaster IDG.nl
Melvyn Sopacua
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
