Menu
▾
▴
cvs-syncmail-talk
|
From: Kevin R. <ke...@ro...> - 2003-01-15 17:27:28
|
Hello CVS-Syncmail gang,
I'm forwarding a feature request from a Debian user.
Kevin
Joost van Baal wrote:
> Package: cvs-syncmail
> Version: 1.2-2
> Severity: wishlist
> Tags: upstream
>
> Hi,
>
> I'd be nice if syncmail could supply a commandline option which would
> make it call /usr/sbin/sendmail instead of connecting to localhost on
> port 25 (which is what smtplib.SMTP() does, I believe). On some
> (arguably misconfigured, perhaps) systems, this makes a difference.
> MUA's generally call /usr/sbin/sendmail to sent out mail. Therefore, I
> believe it'd be a sane thing for syncmail to do this too (or make it
> available.)
>
> (In the past, syncmail used to call /bin/mail or /usr/bin/mail. I've
> tried to write a patch, based on these old scripts, but failed. I'm
> not that fluent in python :( )
>
> Bye,
>
> Joost
>
--
Kevin Rosenberg | .''`. ** Debian GNU/Linux **
http://b9.com/debian.html | : :' : The universal
GPG signed and encrypted | `. `' Operating System
messages accepted. | `- http://www.debian.org/
|
|
From: <ba...@zo...> - 2003-01-16 00:17:06
|
>>>>> "MS" == Martin Schroeder <ma...@on...> writes:
>> The advantage of smtplib.SMTP is portability -- some platforms,
>> most notably Windows, do not have a sendmail binary in the
>> default path. The Perl version
MS> And some hosts have no smtp daemon running. :-{
What would be cooler would be to modify Python's smtplib module to
enable it to talk smtp-over-stdin, e.g. use sendmail's -bs command.
I wish I had time for this.
-Barry
|
|
From: Martin S. <ma...@on...> - 2003-01-16 14:34:26
|
On 2003-01-15 12:56:44 -0500, Fred L. Drake, Jr. wrote: > That's a good idea. We'd welcome a patch if anyone has time to > implement it. Alternatively, an issue can be opened in the feature > request tracker: > > http://sourceforge.net/tracker/?atid=450022&group_id=47611&func=browse Are the patches submitted via sf actually seen by any developer? Best regards Martin -- http://www.tm.oneiros.de/calendar/2003/ |
|
From: Fred L. D. Jr. <fd...@ac...> - 2003-01-16 15:02:33
|
Martin Schroeder writes: > Are the patches submitted via sf actually seen by any developer? Only if we know they're there; syncmail is not a project being heavily developed. We don't think it needs a lot of work; we created an SF project since that's a good way to make it available to others. It has proved a good idea since there have been valuable improvements from the community. As for the trackers, they weren't actually configured to send any mail on activity, so I was definately surprised to see so many things there. I've now configured them to send email to this list for all activity; since we really rely on email to know what's going on, this should improve turnaround of patches. (We could set up another list if this generates too much traffic on this list.) Catching up may prove to be another matter, however. ;-) If anyone can help by reviewing patches (and commenting on them in the trackers), that would be good, and generate an email that tells us what people care about the most. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation |
|
From: Fred L. D. Jr. <fd...@ac...> - 2003-01-15 17:56:55
|
Kevin Rosenberg writes: > Hello CVS-Syncmail gang, > > I'm forwarding a feature request from a Debian user. Thanks! Joost van Baal wrote: > I'd be nice if syncmail could supply a commandline option which would > make it call /usr/sbin/sendmail instead of connecting to localhost on > port 25 (which is what smtplib.SMTP() does, I believe). On some > (arguably misconfigured, perhaps) systems, this makes a difference. > MUA's generally call /usr/sbin/sendmail to sent out mail. Therefore, I > believe it'd be a sane thing for syncmail to do this too (or make it > available.) That's a good idea. We'd welcome a patch if anyone has time to implement it. Alternatively, an issue can be opened in the feature request tracker: http://sourceforge.net/tracker/?atid=450022&group_id=47611&func=browse Thanks! -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation |
|
From: Klaus J. R. <Kla...@at...> - 2003-01-15 19:00:00
|
Joost van Baal wrote: > > I'd be nice if syncmail could supply a commandline option which would > > make it call /usr/sbin/sendmail instead of connecting to localhost on > > port 25 (which is what smtplib.SMTP() does, I believe). On some > > (arguably misconfigured, perhaps) systems, this makes a difference. > > MUA's generally call /usr/sbin/sendmail to sent out mail. Therefore, I > > believe it'd be a sane thing for syncmail to do this too (or make it > > available.) The advantage of smtplib.SMTP is portability -- some platforms, most notably Windows, do not have a sendmail binary in the default path. The Perl version of cvs-syncmail at http://cvs-syncmail-pl.sf.net/, which is based on cvs-syncmail, has a configuration option for specifying a different SMTP server, so if you are relaying all messages through a smarthost at your ISP you can do export SMTP_SERVER=myserver cvs-syncmail ... > tried to write a patch, based on these old scripts, but failed. I'm not that fluent in python :( ) Retrofitting the change for allowing different smarthosts to the Python code should not be too difficult, if you prefer hacking Perl code you have a ready-to-use solution already (and changing the Net::SMTP call to an external sendmail call would be easy too if you still want to call sendmail instead). -- Klaus Johannes Rusch Kla...@at... http://www.atmedia.net/KlausRusch/ |
|
From: Fred L. D. Jr. <fd...@ac...> - 2003-01-15 19:22:12
|
Klaus Johannes Rusch writes: > The advantage of smtplib.SMTP is portability -- some platforms, > most notably Windows, do not have a sendmail binary in the default There is a variable MAILHOST in the Python version that can be changed in the script to control this; it still requires an SMTP server to be available. This requires editing the script, but that's not a huge burden since it has to be copied into each repository anyway. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation |
|
From: <ba...@zo...> - 2003-01-15 20:55:27
|
>>>>> "Fred" == Fred L Drake, Jr <fd...@ac...> writes:
Fred> There is a variable MAILHOST in the Python version that can
Fred> be changed in the script to control this; it still requires
Fred> an SMTP server to be available.
Fred> This requires editing the script, but that's not a huge
Fred> burden since it has to be copied into each repository
Fred> anyway.
It'd be less than <wink> a one line change to get that out of an
environment variable too.
-Barry
|
|
From: Kevin R. <ke...@ro...> - 2003-01-15 22:22:05
|
Gentleman,
Thanks for all of the great ideas. From my reading, it seems that
Joost would prefer to have a command line option for cvs-syncmail to
choose to invoke the sendmail program rather than using the direct
SMTP connection to an arbitrary mail host.
Perhaps Joost will chime in and let us know if connection to an
arbitrary mail host will meet his needs or if _really_ needs to have
sendmail invoked.
--
Kevin Rosenberg | .''`. ** Debian GNU/Linux **
http://b9.com/debian.html | : :' : The universal
GPG signed and encrypted | `. `' Operating System
messages accepted. | `- http://www.debian.org/
|
|
From: Martin S. <ma...@on...> - 2003-01-15 23:27:11
|
On 2003-01-15 17:56:24 -0100, Klaus Johannes Rusch wrote:
> The advantage of smtplib.SMTP is portability -- some platforms, most notably
> Windows, do not have a sendmail binary in the default path. The Perl version
And some hosts have no smtp daemon running. :-{
Best regards
Martin
--
http://www.tm.oneiros.de/calendar/2003/
|
|
From: Fred L. D. Jr. <fd...@ac...> - 2003-01-16 07:04:13
|
Martin Schroeder writes:
> And some hosts have no smtp daemon running. :-{
Being able to set the MAILHOST would change the requirement from the
current need to have SMTP available on localhost to simply being
available *somewhere*. That doesn't cover every case, but probably
covers most situations in which syncmail makes sense anyway.
I'll go ahead and apply a patch to the CVS version.
-Fred
--
Fred L. Drake, Jr. <fdrake at acm.org>
PythonLabs at Zope Corporation
|
|
From: Kevin R. <ke...@ro...> - 2003-01-16 19:12:35
|
Fred L. Drake, Jr. wrote:
> Being able to set the MAILHOST would change the requirement from the
> current need to have SMTP available on localhost to simply being
> available *somewhere*. That doesn't cover every case, but probably
> covers most situations in which syncmail makes sense anyway.
Sounds good.
--
Kevin Rosenberg | .''`. ** Debian GNU/Linux **
http://b9.com/debian.html | : :' : The universal
GPG signed and encrypted | `. `' Operating System
messages accepted. | `- http://www.debian.org/
|
|
From: Joost v. B. <j.e...@uv...> - 2003-01-18 13:42:46
|
Hi all, Excuse me for joining the discussion only this late. On Wed, Jan 15, 2003 at 05:56:24PM -0100, Klaus Johannes Rusch wrote: > Joost van Baal wrote: > > > I'd be nice if syncmail could supply a commandline option which would > > > make it call /usr/sbin/sendmail instead of connecting to localhost on > > > port 25 (which is what smtplib.SMTP() does, I believe). On some > > > (arguably misconfigured, perhaps) systems, this makes a difference. > > > MUA's generally call /usr/sbin/sendmail to sent out mail. Therefore,= I > > > believe it'd be a sane thing for syncmail to do this too (or make it > > > available.) >=20 > The advantage of smtplib.SMTP is portability -- some platforms, most nota= bly > Windows, do not have a sendmail binary in the default path. Yes, the reason to move from an /usr/sbin/sendmail interface to talking SMTP quite often is portability: Microsoft Windows lacks a ``standard'' interface to send out mail. However, using /usr/sbin/sendmail (if it's available) has benefits: you can rely on the local mail queueing, to deal with stuff like network outages. Therefore, I feel it's a wise thing to use this interface where available. (Unix MUA's generally do this, too.) > The Perl version > of cvs-syncmail at http://cvs-syncmail-pl.sf.net/, which is based on > cvs-syncmail, has a configuration option for specifying a different SMTP > server, so if you are relaying all messages through a smarthost at your I= SP > you can do >=20 > export SMTP_SERVER=3Dmyserver > cvs-syncmail ... Yep, saw that. Unfortunately, the Perl version lacks the /usr/sbin/sendmail option too. (And this project hasn't made an official release yet.) > > tried to write a patch, based on these old scripts, but failed. I'm not > > that fluent in python :( ) >=20 > Retrofitting the change for allowing different smarthosts to the Python c= ode > should not be too difficult, if you prefer hacking Perl code you have a > ready-to-use solution already (and changing the Net::SMTP call to an exte= rnal > sendmail call would be easy too if you still want to call sendmail instea= d). Hm, what was the reason to start reimplementing the same script in Perl? (I couldn't find any rationale.) Would it be useful if I'd write a patch for the Perl script? Bye, Joost --=20 Joost van Baal http://banach.uvt.nl/ Tilburg University j.e...@uv... The Netherlands |
|
From: Klaus J. R. <Kla...@at...> - 2003-01-18 21:27:23
|
In <200...@ba...>, Joost van Baal <j.e...@uv...> writes:
> Yes, the reason to move from an /usr/sbin/sendmail interface to talking
> SMTP quite often is portability: Microsoft Windows lacks a ``standard''
> interface to send out mail. However, using /usr/sbin/sendmail (if it's
> available) has benefits: you can rely on the local mail queueing, to
> deal with stuff like network outages. Therefore, I feel it's a wise
> thing to use this interface where available. (Unix MUA's generally do
> this, too.)
Agreed.
Would you expect the MUA to handle a message in SMTP format, or would you want
the ability to specify recipients, subject etc. when calling the MUA. The
former approach obviously is a lot easier to implement and would be my
preferred option, something like
--mua="/usr/sbin/sendmail -t"
> Hm, what was the reason to start reimplementing the same script in Perl?
> (I couldn't find any rationale.) Would it be useful if I'd write a patch
> for the Perl script?
Mainly the need to run cvs-syncmail on a system that did not have Python
installed, and once I had ported the code to Perl I thought others might
possibly have an interest, too :-)
A patch would certainly be appreciated, or at least a clarification of the
requirement.
--
Klaus Johannes Rusch
Kla...@at...
http://www.atmedia.net/KlausRusch/
|
|
From: Joost v. B. <j.e...@uv...> - 2003-01-19 13:26:37
Attachments:
syncmail.pl.patch
|
Hi Klaus,
Thanks for your reply.
On Sat, Jan 18, 2003 at 07:45:32PM +0100, Klaus Johannes Rusch wrote:
> In <200...@ba...>, Joost van Baal <j.e...@uv...> writes:
> > using /usr/sbin/sendmail (if it's
> > available) has benefits: you can rely on the local mail queueing, to
> > deal with stuff like network outages. Therefore, I feel it's a wise
> > thing to use this interface where available. (Unix MUA's generally do
> > this, too.)
>
> Agreed.
>
> Would you expect the MUA to handle a message in SMTP format, or would you want
> the ability to specify recipients, subject etc. when calling the MUA. The
> former approach obviously is a lot easier to implement and would be my
> preferred option, something like
>
> --mua="/usr/sbin/sendmail -t"
Yes, this sounds like a good way to implement it. Just build the
message, including the headers, and either feed it to smtplib.SMTP() or
to /usr/sbin/sendmail.
BTW, you might want to invoke sendmail as
--mta="/usr/sbin/sendmail -t -oi"
in order to cope sanely with lines containing single dots in the
message. Perhaps /usr/lib/sendmail is found on more systems than
/usr/sbin/sendmail; you might want to check for that too. See attached
patch.
[Just to get rid of any misunderstanding: I regard syncmail as a - be it
somewhat specialized - Mail User Agent, like mutt or pine or LaMail or
/bin/mail. These MUA programs get rid of their mail using a standard
interface. On Unix, this is the interface supplied by the Message
Transfer Agent, like Sendmail, Exim, qmail or Postfix. All these MTA's
supply a /usr/sbin/sendmail.]
FWIW, I've just taken a look at the Debian reportbug utility, another
Python script which sends out mail. It does:
pipe = os.popen(options.mta+' -t -oi -oem', 'w')
You might want to take a look at http://packages.debian.org/reportbug
and at
http://ftp.debian.org/debian/pool/main/r/reportbug/reportbug_2.10.tar.gz .
> > Hm, what was the reason to start reimplementing the same script in Perl?
> > (I couldn't find any rationale.) Would it be useful if I'd write a patch
> > for the Perl script?
>
> Mainly the need to run cvs-syncmail on a system that did not have Python
> installed, and once I had ported the code to Perl I thought others might
> possibly have an interest, too :-)
A, I see. Sounds reasonable :)
> A patch would certainly be appreciated, or at least a clarification of the
> requirement.
Patch for syncmail.pl attached; clarification, as given earlier: behave
as MUA's generally do on Unix systems: follow current best practice,
Beware: I've only done some minor testing of the patch.
Bye,
Joost
--
Joost van Baal http://banach.uvt.nl/
Tilburg University
j.e...@uv... The Netherlands
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X