Re: sending with perl instead of MTA?
- Original Message - From: Cameron Simpson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, August 12, 2002 1:13 AM Subject: Re: sending with perl instead of MTA? On 13:59 11 Aug 2002, Matej Cepl [EMAIL PROTECTED] wrote: I had thought I'd explained that. If you're going to have a mail system on your home machine that talks to the outside world, you NEED a valid, deliverable domain for it. And that CANNOT be your ISP's domain, because there's plenty of accounts on your home machine whose name will collide with names in the ISP domain, or just be plain undeliverable. Egro, you need a domain, and a listening sendmail. I am not with you. Do you know about the genericstable file? Sendmail is able to translate local addresses (= account names) into different email addresses. For example, my genericstable says matej [EMAIL PROTECTED] ceplova [EMAIL PROTECTED] It means that every email from account matej is sent as from [EMAIL PROTECTED] and every email from account ceplova is sent as from [EMAIL PROTECTED] What's the problem? As I remarked, my ISP (optus@home) blocks SMTP delivery and therefore I can't run a mail service on my home machine without extra finagling. And nor can other Optus customers. Of course, you should deliver all email through smrat_host of your ISP (line define(`SMART_HOST', `mysmtp') in sendmail.mc). Again, what's the problem? So in short, many people are not in a position to setup up a valid mail system at home, ... I strongly believe this statement to be incorrect. Since my script does less (and more; I dispatch news with it too) and sendmail has a long history of vunerabilities and is overfeatured for my needs, I would call that logic a little shakey. Of course, the same can be achieved with SMTP servers (I have used postfix for a while, but you can use exim, qmail, etc. if you wish). Have a nice day Matej Cepl
Re: sending with perl instead of MTA?
At 9:27 AM +1000 2002/08/12, Cameron Simpson wrote: The problem is that the home machine will either stamp unqualified addresses (cameron) with a bogus domain (eg localhost.localdomain on unmodified redhat boxes) or with the ISP's domain (if you've so configured it), which is a LIE, because most accounts on your machine either don't exist in the ISP or collide with other users. See my previous messages. This is not a problem, if you have configured the box correctly and, more importantly, you have configured mutt correctly. the crucial point most people seem to miss here, aside from the whole lack-of-domain thing, is that if you're going to use you local machines mail system, _all_ email clients must be able to use it (without special config hacks like my_hdr), and all local accounts must be able to use it. Again, that's not necessarily true. Even if it is true, with proper configuration, you can support this. That's the whole point! A single user single client setup might as well speak directly to a legitimate SMTP service from one's ISP. That would be the preferred method, yes. However, it is not the only option. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++)
Re: sending with perl instead of MTA?
At 9:22 AM +1000 2002/08/12, Cameron Simpson wrote: No. The outgoing headers include enough reply information for misdelivery to cause bounces to go into the ether, or to my ISP (_postmaster_ or suchlike at my ISP, not _me_) that this is the wrong approach. Not if you set your envelope sender correctly. You have complete control over this value, and if set properly, you can guarantee that all bounces go back to this address. That is, unless the MTA at the other end is seriously screwed-up, but then you can also control the other headers that might potentially be used for those bounces, to also ensure that they will go to the correct place. It is necessary that the first _mail_system_ that handle things be a valid standalone domain for this reason. Again, this is a fallacy. Unless you have been running Internet mail systems for many years and you really understand all the issues involved, you should not be arguing points like this with people who have been doing this sort of thing for a decade or more. So either one needs one's own domain and a full setup on the home box, or one needs to deliver directly to the ISP's SMTP service. That would be the preferred method, yes. However, there are alternatives that do not involve the creation of entirely new pieces of code being written by people who don't really know what they're doing. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++)
Re: sending with perl instead of MTA?
At 9:13 AM +1000 2002/08/12, Cameron Simpson wrote: I had thought I'd explained that. If you're going to have a mail system on your home machine that talks to the outside world, you NEED a valid, deliverable domain for it. Not true. If they have an external mail relay that is configured to accept anything they transmit (hopefully secured via SMTPAUTH or TLSSMTP), then this isn't a problem. You just need to make sure that the envelope sender is set to a valid deliverable domain, but that's a problem you can easily solve with mutt. And that CANNOT be your ISP's domain, because there's plenty of accounts on your home machine whose name will collide with names in the ISP domain, or just be plain undeliverable. Just make sure that the envelope sender address is set correctly, and you don't have a problem. Egro, you need a domain, and a listening sendmail. Not true. Provably so. As I remarked, my ISP (optus@home) blocks SMTP delivery and therefore I can't run a mail service on my home machine without extra finagling. And nor can other Optus customers. It's easy enough to set up port forwarding, including port forwarding to a different port. So in short, many people are not in a position to setup up a valid mail system at home, and further don't need one - they only need to be able to do SMTP dispatch. Actually, this statement is true. Just use the SMTP servers from your network provider. Actually, I now have a correctly configured sendmail at home, having made external delivery arrangements for my domain. And I still use my special wheel, because sendmail doesn't do what I want, not will ANY email only tool. In what way will sendmail not do what you want? Since my script does less (and more; I dispatch news with it too) and sendmail has a long history of vunerabilities and is overfeatured for my needs, I would call that logic a little shakey. When was the last security advisory for sendmail? That is, sendmail the program, not some library that all applications use, or some other mail-related problem that can be potentially resolved with sendmail. The most recent CERT Advisory for sendmail that I can find is dated January 28, 1997 at http://www.cert.org/advisories/CA-1997-05.html. Now, when I left AOL as their Sr. Internet Mail Systems Administrator, they were doing an average of about a mail message a day per user (five million at the time). I understand that they're over 30 million users today. If you assume linear growth (which should underestimate the traffic), you would get about five million users additional per year. That would be 1.825 billion e-mail messages in 1997 alone, and a total of about 38 billion e-mail messages over that five year period of time. And that's just for AOL. Total Internet traffic transmitted via sendmail is almost certainly many orders of magnitude larger than this. How many trillions of e-mail messages has your custom script delivered over the past five years? Long ago, Eric got tired of being the security whipping boy of the Internet. This is why the list of DONTBLAMESENDMAIL configuration options is so incredibly long -- there are so many things that you should not be doing (for security purposes), but because people care more about making things work than making them secure, they need to turn on one or more of these options. In the past, Eric let these things slide, but no more. Hence, the options so that people can turn security off again, and make things work. Sorry, but if I were installing from scratch I'd use postfix, not sendmail. As it is, I've arranged my own domain and set the (fairly easy for a techie) setting in the RedHat sendmail.mc file and am now happy. But I still don't use it for mutt dispatch, and never will. Yes, theoretically, postfix is more secure than sendmail, because of the mutually distrustful/absolutely least possible priviledge mode of operation. In practice, I don't think it is all that much less secure, in part because there are so many fewer places around the world that are running it, and because the code has not yet lived long enough to be able to claim to truly stand the test of time. Keep in mind that I've been involved with the development of postfix since 1998, back when it was still called VMailer. I'm very proud of this involvement, and there are a lot of things for which postfix is quite good for. But if you want to objectively compare the security history of postfix to that of sendmail, you have to keep in mind that sendmail hasn't had a CERT Alert issued since a year before postfix existed. Moreover, there are some features of sendmail that postfix can't really touch. While it is intended to be a drop-in replacement for
Re: sending with perl instead of MTA?
- Original Message - From: Cameron Simpson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, August 11, 2002 5:34 AM Subject: Re: sending with perl instead of MTA? Therefore it's often sensible to use your ISP's SMTP server. And thus a script of some kind instead of sendmail, since you're only doing dispatch, not routing. Yes, it is (actually, it is only sensible way how to make sending of mails working on dial-up machine without bind etc.), but why not to configure your very own sendmail properly? If I were only doing SMTP, I'd be doing that (well, really using my own smtpsend script which does that same job). But I'm doing a bit more. So I have my own script. You do not have to have your own script (have you ever heard about reinventing the wheel?). I understand that you have problems with configuring underdocumented sendmail (who doesn't have them?), but still I believe that it is better to use it than your own Perl script (twenty years of development makes sendmail probably at least slightly more robust than your own creation). So, take a look at http://www.sendmail.org/~ca/email/offline_mailing.html, where is very well documented exactly yours configuration of sendmail and take a look at the attached sendmail.mc. What about that? Matej sendmail.mc Description: Binary data
Re: sending with perl instead of MTA?
* Matej Cepl [EMAIL PROTECTED] [020811 13:59]: You do not have to have your own script (have you ever heard about reinventing the wheel?). I understand that you have problems with configuring underdocumented sendmail (who doesn't have them?) I don't wanna start any MTA wars, but I tend to agree that sendmail is a little overkill for the problem. You could take a look at nullmailer for example, http://untroubled.org/nullmailer/ - the advantage of usin nullmailer or sendmail is that mail gets queued should there be a problem with the ISP's smtp server. -Johan -- Johan Almqvist http://www.almqvist.net/johan/qmail/
Re: sending with perl instead of MTA?
David -- BTW, you shouldn't follow up to the @gbnet address even if the prior message was [mis]directed there... ...and then David Rock said... % % On Sun, Aug 11, 2002 at 01:34:55PM +1000, Cameron Simpson wrote: % % Or with no legitimate domain name to use for outgoing return information; ... % have an opressive ISP (eg optus@home, my cable provider) you _can't_ % run an publicly visible SMTP server because optus filter that port. % % Wouldn't you just use my_hdr From: [EMAIL PROTECTED] to cover most of % this problem? How do you get such a mail out to the outside world so that someone can see that address and reply to it? % % -- % David Rock % [EMAIL PROTECTED] HTH HAND :-D -- David T-G * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] http://www.justpickone.org/davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! msg30200/pgp0.pgp Description: PGP signature
Re: sending with perl instead of MTA?
On 13:59 11 Aug 2002, Matej Cepl [EMAIL PROTECTED] wrote: | Therefore it's often sensible to use your ISP's SMTP server. And thus a | script of some kind instead of sendmail, since you're only doing dispatch, | not routing. | Yes, it is (actually, it is only sensible way how to make sending of mails | working on dial-up machine without bind etc.), but why not to configure your | very own sendmail properly? I had thought I'd explained that. If you're going to have a mail system on your home machine that talks to the outside world, you NEED a valid, deliverable domain for it. And that CANNOT be your ISP's domain, because there's plenty of accounts on your home machine whose name will collide with names in the ISP domain, or just be plain undeliverable. Egro, you need a domain, and a listening sendmail. As I remarked, my ISP (optus@home) blocks SMTP delivery and therefore I can't run a mail service on my home machine without extra finagling. And nor can other Optus customers. So in short, many people are not in a position to setup up a valid mail system at home, and further don't need one - they only need to be able to do SMTP dispatch. | If I were only doing SMTP, I'd be doing that (well, really using my own | smtpsend script which does that same job). But I'm doing a bit more. | So I have my own script. | | You do not have to have your own script (have you ever heard about | reinventing the wheel?). When other wheels are not the right shape, one must roll one's own or be a slave to someone else's unsuitable setup. I have LOTS of wheels with special fittings. | I understand that you have problems with | configuring underdocumented sendmail (who doesn't have them?), Actually, I now have a correctly configured sendmail at home, having made external delivery arrangements for my domain. And I still use my special wheel, because sendmail doesn't do what I want, not will ANY email only tool. | but still I | believe that it is better to use it than your own Perl script (twenty years | of development makes sendmail probably at least slightly more robust than | your own creation). Since my script does less (and more; I dispatch news with it too) and sendmail has a long history of vunerabilities and is overfeatured for my needs, I would call that logic a little shakey. | So, take a look at | http://www.sendmail.org/~ca/email/offline_mailing.html, where is very well | documented exactly yours configuration of sendmail and take a look at the | attached sendmail.mc. | What about that? Sorry, but if I were installing from scratch I'd use postfix, not sendmail. As it is, I've arranged my own domain and set the (fairly easy for a techie) setting in the RedHat sendmail.mc file and am now happy. But I still don't use it for mutt dispatch, and never will. Cheers, -- Cameron Simpson, DoD#743[EMAIL PROTECTED]http://www.zip.com.au/~cs/ Yes, [congress is] petty and venal and selfish. That's why they're called _representatives_. - Will Durst
Re: sending with perl instead of MTA?
On 00:02 11 Aug 2002, David Rock [EMAIL PROTECTED] wrote: | On Sun, Aug 11, 2002 at 01:34:55PM +1000, Cameron Simpson wrote: | Or with no legitimate domain name to use for outgoing return information; | to run a mail service you really do need a valid reply domain, at | least for the addresses (From:) that you permit to escape into the | outside world. On a dialup or cable connection you don't have this | unless you make yourself a domain, eg via homeip.net etc. And if you | have an opressive ISP (eg optus@home, my cable provider) you _can't_ | run an publicly visible SMTP server because optus filter that port. | | Wouldn't you just use my_hdr From: [EMAIL PROTECTED] to cover most of | this problem? No. The outgoing headers include enough reply information for misdelivery to cause bounces to go into the ether, or to my ISP (_postmaster_ or suchlike at my ISP, not _me_) that this is the wrong approach. It is necessary that the first _mail_system_ that handle things be a valid standalone domain for this reason. So either one needs one's own domain and a full setup on the home box, or one needs to deliver directly to the ISP's SMTP service. -- Cameron Simpson, DoD#743[EMAIL PROTECTED]http://www.zip.com.au/~cs/ Using encryption on the Internet is the equivalent of arranging an armored car to deliver credit-card information from someone living in a cardboard box to someone living on a park bench. - Gene Spafford
Re: sending with perl instead of MTA?
On 08:20 11 Aug 2002, David T-G [EMAIL PROTECTED] wrote: | ...and then David Rock said... | % On Sun, Aug 11, 2002 at 01:34:55PM +1000, Cameron Simpson wrote: | % Or with no legitimate domain name to use for outgoing return information; | % have an opressive ISP (eg optus@home, my cable provider) you _can't_ | % run an publicly visible SMTP server because optus filter that port. | % Wouldn't you just use my_hdr From: [EMAIL PROTECTED] to cover most of | % this problem? | How do you get such a mail out to the outside world so that someone can | see that address and reply to it? Oh that side is easy - your home system knows how to send, directly (Optus block inbound SMTP, not outbound SMTP). The problem is that the home machine will either stamp unqualified addresses (cameron) with a bogus domain (eg localhost.localdomain on unmodified redhat boxes) or with the ISP's domain (if you've so configured it), which is a LIE, because most accounts on your machine either don't exist in the ISP or collide with other users. the crucial point most people seem to miss here, aside from the whole lack-of-domain thing, is that if you're going to use you local machines mail system, _all_ email clients must be able to use it (without special config hacks like my_hdr), and all local accounts must be able to use it. That's the whole point! A single user single client setup might as well speak directly to a legitimate SMTP service from one's ISP. -- Cameron Simpson, DoD#743[EMAIL PROTECTED]http://www.zip.com.au/~cs/ Tiggers don't like honey. - A.A.Milne, The House at Pooh Corner
Re: sending with perl instead of MTA?
* Cameron Simpson [EMAIL PROTECTED] [2002-08-10 22:48]: | and why are you using a perl script | for sending when you have mutt? Because, as y'all keep saying, mutt doesn't send email or talk to SMTP servers. It hands messages to sendmail. correct. but why not use an MTA? I also use a perl script for this, and point mutt at it as the sendmail tool. It's especially handy on disconnected home machines which have net connections but not net-aware local mail systems; .. eh? disconnected machines with net connections? . you can then just replace the sendmail with something that delivers, for example, to the host named by your $SMTPSERVER variable. shades of ssmtp? Sven
Re: sending with perl instead of MTA?
On 00:53 11 Aug 2002, Sven Guckes [EMAIL PROTECTED] wrote: | * Cameron Simpson [EMAIL PROTECTED] [2002-08-10 22:48]: | | and why are you using a perl script | | for sending when you have mutt? | Because, as y'all keep saying, mutt doesn't send email | or talk to SMTP servers. It hands messages to sendmail. | correct. but why not use an MTA? The script is the MTA. And because some MTAs are a PITA to configure for many people. And because it may well be infeasible to run a real mail system on one's home box (see below). | I also use a perl script for this, and point mutt at it as | the sendmail tool. It's especially handy on disconnected | home machines which have net connections | but not net-aware local mail systems; .. | eh? disconnected machines with net connections? I mean with default unconfigured sendmail or whatever. Or with no legitimate domain name to use for outgoing return information; to run a mail service you really do need a valid reply domain, at least for the addresses (From:) that you permit to escape into the outside world. On a dialup or cable connection you don't have this unless you make yourself a domain, eg via homeip.net etc. And if you have an opressive ISP (eg optus@home, my cable provider) you _can't_ run an publicly visible SMTP server because optus filter that port. Therefore it's often sensible to use your ISP's SMTP server. And thus a script of some kind instead of sendmail, since you're only doing dispatch, not routing. | . you can then just replace the sendmail | with something that delivers, for example, | to the host named by your $SMTPSERVER variable. | shades of ssmtp? If I were only doing SMTP, I'd be doing that (well, really using my own smtpsend script which does that same job). But I'm doing a bit more. So I have my own script. -- Cameron Simpson, DoD#743[EMAIL PROTECTED]http://www.zip.com.au/~cs/ I sympathize with the makers of _The Net_. We're sad bastards really and they're trying their best to make us seem interesting. - [EMAIL PROTECTED] (Dave Griffiths)
Re: sending with perl instead of MTA?
On Sun, Aug 11, 2002 at 01:34:55PM +1000, Cameron Simpson wrote: Or with no legitimate domain name to use for outgoing return information; to run a mail service you really do need a valid reply domain, at least for the addresses (From:) that you permit to escape into the outside world. On a dialup or cable connection you don't have this unless you make yourself a domain, eg via homeip.net etc. And if you have an opressive ISP (eg optus@home, my cable provider) you _can't_ run an publicly visible SMTP server because optus filter that port. Wouldn't you just use my_hdr From: [EMAIL PROTECTED] to cover most of this problem? -- David Rock [EMAIL PROTECTED]
