R Lists06 wrote:
I've tried to install qmail 1.03 on CentOS 4.4 using the command:
# make setup check
and I received this error:
./load auto-str substdio.a error.a str.a substdio.a(substdo.o)(.text+0x43): In function `allwrite':
undefined reference to `errno'
collect2: ld returned 1 exit status make: *** [auto-str] Error 1
Can anyone please help?
TIA Dick Holland
and there is lifewithqmail.org and several others
basically what I am saying, is that you should have a well thought out full install before you start of your just in for headaches
if you don't install qmail properly and it is an internet facing unit, some unpleasant issues will eventually arise.
:-)
- rh
IIRC correctly, this is the (in)famous errno problem. It requires a patch to put qmail at 1.03. Life with qmail has all the instruction you need to patch and install qmail. There's a script to do it all for you. Qmail is really straight forward provided you follow the install directions to the letter. Once you do, you'll have the best SMTP server running.
Thanks!
Mark Schoonover *** Winner of the 2008 Best Psychic Award IS Manager American Geotechnical - California, Nevada and Arizona V-> 858.450.4040 F-> 714.685.3909 C-> 858.472.3816
IIRC correctly, this is the (in)famous errno problem. It requires a patch to put qmail at 1.03. Life with qmail has all the instruction you need to patch and install qmail. There's a script to do it all for you. Qmail is really straight forward provided you follow the install directions to the letter. Once you do, you'll have the best SMTP server running.
*COUGH* <flame war> So... the patch upgrades qmail to postfix?
/runs
Jim Perrin spake the following on 2/5/2007 3:53 PM:
IIRC correctly, this is the (in)famous errno problem. It requires a patch to put qmail at 1.03. Life with qmail has all the instruction you need to patch and install qmail. There's a script to do it all for you. Qmail is really straight forward provided you follow the install directions to the letter. Once you do, you'll have the best SMTP server running.
*COUGH*
<flame war> So... the patch upgrades qmail to postfix?
/runs
THIS IS THE CAPTAIN
SET CONDITION 1SQ FOR STRATEGIC MISSILE LAUNCH
SPIN UP MISSILES ONE THROUGH FIVE AND TWENTY THROUGH TWENTY-FOUR
THE RELEASE OF NUCLEAR WEAPONS HAS BEEN AUTHORIZED |`-:_ ,----....____ | `+. THIS IS NOT A DRILL ( ````----....|___ | \ _ ````----....____ \ _) ```---.._ \ \ )`.\ )`. )`. )`. )`. )`. )`. )`. )`. )`. )`. -' `-' `-' `-' `-' `-' `-' `-' `-' `-' `-' `
On Mon, 2007-02-05 at 16:04 -0800, Scott Silva wrote:
Jim Perrin spake the following on 2/5/2007 3:53 PM:
IIRC correctly, this is the (in)famous errno problem. It requires a patch to put qmail at 1.03. Life with qmail has all the instruction you need to patch and install qmail. There's a script to do it all for you. Qmail is really straight forward provided you follow the install directions to the letter. Once you do, you'll have the best SMTP server running.
*COUGH*
<flame war> So... the patch upgrades qmail to postfix?
/runs
THIS IS THE CAPTAIN SET CONDITION 1SQ FOR STRATEGIC MISSILE LAUNCH SPIN UP MISSILES ONE THROUGH FIVE AND TWENTY THROUGH TWENTY-FOUR THE RELEASE OF NUCLEAR WEAPONS HAS BEEN AUTHORIZED |`-:_,----....____ | `+. THIS IS NOT A DRILL ( ````----....|___ | \ _ ````----....____ \ _) ```---.._ \ \ )`.\ )`. )`. )`. )`. )`. )`. )`. )`. )`. )`. -' `-' `-' `-' `-' `-' `-' `-' `-' `-' `-' `
COOL ....
I was a boomer sailor once :P
Johnny Hughes spake the following on 2/7/2007 2:46 AM:
On Mon, 2007-02-05 at 16:04 -0800, Scott Silva wrote:
Jim Perrin spake the following on 2/5/2007 3:53 PM:
IIRC correctly, this is the (in)famous errno problem. It requires a patch to put qmail at 1.03. Life with qmail has all the instruction you need to patch and install qmail. There's a script to do it all for you. Qmail is really straight forward provided you follow the install directions to the letter. Once you do, you'll have the best SMTP server running.
*COUGH*
<flame war> So... the patch upgrades qmail to postfix?
/runs
THIS IS THE CAPTAIN SET CONDITION 1SQ FOR STRATEGIC MISSILE LAUNCH SPIN UP MISSILES ONE THROUGH FIVE AND TWENTY THROUGH TWENTY-FOUR THE RELEASE OF NUCLEAR WEAPONS HAS BEEN AUTHORIZED |`-:_,----....____ | `+. THIS IS NOT A DRILL ( ````----....|___ | \ _ ````----....____ \ _) ```---.._ \ \ )`.\ )`. )`. )`. )`. )`. )`. )`. )`. )`. )`. -' `-' `-' `-' `-' `-' `-' `-' `-' `-' `-' `
COOL ....
I was a boomer sailor once :P
It is not a weapon, it is a deterrent to the flame war!
*COUGH*
<flame war> So... the patch upgrades qmail to postfix?
/runs
Postfix?
Isn't that kinda like a short term pen1s hardener pill for new or old lame server administrators?
;->
- rh
-- Robert - Abba Communications Computer & Internet Services (509) 624-7159 - www.abbacomm.net
*COUGH*
<flame war> So... the patch upgrades qmail to postfix?
/runs
Postfix?
Isn't that kinda like a short term weenie hardener thing to ingest for lame server admins ???
;->
- rh
-- Robert - Abba Communications Computer & Internet Services (509) 624-7159 - www.abbacomm.net
On 05/02/07, Jim Perrin jperrin@gmail.com wrote:
IIRC correctly, this is the (in)famous errno problem. It requires a patch to put qmail at 1.03. Life with qmail has all the instruction you need to patch and install qmail. There's a script to do it all for you. Qmail is really straight forward provided you follow the install directions to the letter. Once you do, you'll have the best SMTP server running.
*COUGH*
<flame war> So... the patch upgrades qmail to postfix?
/runs
Meeeoow! :)
I HAVE to run Qmail because it's a legacy requirement. If I could find something with similar virtual domain and Maildir support (and for all I know Postfix or Exim may provide these) and a nice transition path I'm stuck with it.
And let me throw in to the ring, there's a nicely RPM packaged Qmail package conglomerate at http://www.qmailtoaster.com/ And we all know that packages are the way ahead, right? :)
Complete with CentOS instructions http://www.qmailtoaster.com/centos/cnt40/EZ-QmailToaster-CentOS-4.3.txt
Personally, I hack around with the SPECs before building to strip out the MySQL and other features and just use Qmail listening on localhost only for the very final Maildir delivery after messages have been dealt with by MailScanner and Sendmail, then Courier and VPOPMail for POP3 and IMAP.
Will.
Will McDonald wrote:
<flame war> So... the patch upgrades qmail to postfix?
/runs
Meeeoow! :)
I HAVE to run Qmail because it's a legacy requirement. If I could find something with similar virtual domain and Maildir support (and for all I know Postfix or Exim may provide these) and a nice transition path I'm stuck with it.
Doesn't everything do virtual domains these days? Sendmail has had them for ages, although perhaps not quite the same way. And everything that can use procmail for delivery (the default for sendmail in Centos) can deliver to maildirs.
And let me throw in to the ring, there's a nicely RPM packaged Qmail package conglomerate at http://www.qmailtoaster.com/ And we all know that packages are the way ahead, right? :)
Complete with CentOS instructions http://www.qmailtoaster.com/centos/cnt40/EZ-QmailToaster-CentOS-4.3.txt
Personally, I hack around with the SPECs before building to strip out the MySQL and other features and just use Qmail listening on localhost only for the very final Maildir delivery after messages have been dealt with by MailScanner and Sendmail, then Courier and VPOPMail for POP3 and IMAP.
It's a very bad idea to let an unmodified qmail accept mail directly since it accepts all addresses, then later generates bounces to the ones that it can't deliver. A dictionary attack will bury your outbound queue.
On 06/02/07, Les Mikesell lesmikesell@gmail.com wrote:
Will McDonald wrote:
<flame war> So... the patch upgrades qmail to postfix?
/runs
Meeeoow! :)
I HAVE to run Qmail because it's a legacy requirement. If I could find something with similar virtual domain and Maildir support (and for all I know Postfix or Exim may provide these) and a nice transition path I'm stuck with it.
Doesn't everything do virtual domains these days? Sendmail has had them for ages, although perhaps not quite the same way. And everything that can use procmail for delivery (the default for sendmail in Centos) can deliver to maildirs.
And let me throw in to the ring, there's a nicely RPM packaged Qmail package conglomerate at http://www.qmailtoaster.com/ And we all know that packages are the way ahead, right? :)
Complete with CentOS instructions http://www.qmailtoaster.com/centos/cnt40/EZ-QmailToaster-CentOS-4.3.txt
Personally, I hack around with the SPECs before building to strip out the MySQL and other features and just use Qmail listening on localhost only for the very final Maildir delivery after messages have been dealt with by MailScanner and Sendmail, then Courier and VPOPMail for POP3 and IMAP.
It's a very bad idea to let an unmodified qmail accept mail directly since it accepts all addresses, then later generates bounces to the ones that it can't deliver. A dictionary attack will bury your outbound queue.
This doesn't run unmodified Qmail, it's the Qmail patchset from Qmailtoaster built into packages but I mangle the SPEC a little to remove the MySQL requirement and customise a few bits and bobs.
And, as I said this is "Qmail listening on localhost only for the very final Maildir delivery after messages have been dealt with by MailScanner and Sendmail".
Incoming Sendmail is configured to use a list of valid RCPT TO addresses via LDAPROUTE_DOMAIN_FILE and the ldap_routing FEATURE. This is for mail traffic from the internet so anything attempting to deliver to an invalid RCPT TO gets dropped sharpish.
Outgoing Sendmail (which delivers to Qmail for local deliveries) is configured using relay_mail_from and a list of valid addresses in the access map which isn't ideal but I have a lot of legacy reasons for having things the way they are. It's open to some abuse but only from a very limited set of internal users and the alternatives, SMTP-AUTH isn't feasible under the restrictions we're under. :o\
I will have a look at using Procmail or Postfix as you and Feizhou have mentioned as we're rebuilding a couple of these servers currently.
Will.
I will have a look at using Procmail or Postfix as you and Feizhou have mentioned as we're rebuilding a couple of these servers currently.
procmail is a resource hog. If you do not have to use it, do not. If you need some filtering, maildrop may be a better choice.
Feizhou wrote:
I will have a look at using Procmail or Postfix as you and Feizhou have mentioned as we're rebuilding a couple of these servers currently.
procmail is a resource hog. If you do not have to use it, do not. If you need some filtering, maildrop may be a better choice.
Sendmail + MimeDefang is probably the most efficient combination but spamassassin is the real resource hog wherever it runs.
Les Mikesell wrote:
Feizhou wrote:
I will have a look at using Procmail or Postfix as you and Feizhou have mentioned as we're rebuilding a couple of these servers currently.
procmail is a resource hog. If you do not have to use it, do not. If you need some filtering, maildrop may be a better choice.
Sendmail + MimeDefang is probably the most efficient combination but spamassassin is the real resource hog wherever it runs.
Neither mimedefang nor spamassassin sort mail to different folders as far as I know or I have missed something?
Feizhou wrote:
Les Mikesell wrote:
Feizhou wrote:
I will have a look at using Procmail or Postfix as you and Feizhou have mentioned as we're rebuilding a couple of these servers currently.
procmail is a resource hog. If you do not have to use it, do not. If you need some filtering, maildrop may be a better choice.
Sendmail + MimeDefang is probably the most efficient combination but spamassassin is the real resource hog wherever it runs.
Neither mimedefang nor spamassassin sort mail to different folders as far as I know or I have missed something?
Sendmail continues to deliver with procmail. The difference when using mimedefang is that you have already rejected viruses and spam with high enough scores to reject early in the smtp conversation, and spamassassion only needs to run once on messages with multiple recipients. You can add a header with the spamassassin score, then filter/sort on that in procmail (or pop/imap agents) so users can have different handling of the same message. The mimedefang operations are controlled by a small snippet of perl so it is easy to customize.
Sendmail continues to deliver with procmail. The difference when using mimedefang is that you have already rejected viruses and spam with high enough scores to reject early in the smtp conversation, and spamassassion only needs to run once on messages with multiple recipients. You can add a header with the spamassassin score, then filter/sort on that in procmail (or pop/imap agents) so users can have different handling of the same message. The mimedefang operations are controlled by a small snippet of perl so it is easy to customize.
I'd much rather use maildrop to do the final filtering/delivery than procmail. procmail is a beast.
Feizhou wrote:
Sendmail continues to deliver with procmail. The difference when using mimedefang is that you have already rejected viruses and spam with high enough scores to reject early in the smtp conversation, and spamassassion only needs to run once on messages with multiple recipients. You can add a header with the spamassassin score, then filter/sort on that in procmail (or pop/imap agents) so users can have different handling of the same message. The mimedefang operations are controlled by a small snippet of perl so it is easy to customize.
I'd much rather use maildrop to do the final filtering/delivery than procmail. procmail is a beast.
Sendmail doesn't much care what local delivery agent you configure. If you are using dovecot you might also like its 'deliver' program and its sieve plugin. Procmail is only tolerable because so many people use it and you can find examples of about anything you might want it to do.
Les Mikesell wrote:
Sendmail + MimeDefang is probably the most efficient combination but spamassassin is the real resource hog wherever it runs.
No disagreement there. It *is* the most problematic and time consuming portion of my entire SMTP application. ~5 seconds is about the average time to scan an email. Spamassasin's also susceptible to it's bayesian filter databases becoming corrupted, which causes untold havoc until you rebuild them with a two huge directories full of alternatively SPAM and HAM.
Peter
Will McDonald wrote:
This doesn't run unmodified Qmail, it's the Qmail patchset from Qmailtoaster built into packages but I mangle the SPEC a little to remove the MySQL requirement and customise a few bits and bobs.
And, as I said this is "Qmail listening on localhost only for the very final Maildir delivery after messages have been dealt with by MailScanner and Sendmail".
Incoming Sendmail is configured to use a list of valid RCPT TO addresses via LDAPROUTE_DOMAIN_FILE and the ldap_routing FEATURE. This is for mail traffic from the internet so anything attempting to deliver to an invalid RCPT TO gets dropped sharpish.
Outgoing Sendmail (which delivers to Qmail for local deliveries) is configured using relay_mail_from and a list of valid addresses in the access map which isn't ideal but I have a lot of legacy reasons for having things the way they are. It's open to some abuse but only from a very limited set of internal users and the alternatives, SMTP-AUTH isn't feasible under the restrictions we're under. :o\
I will have a look at using Procmail or Postfix as you and Feizhou have mentioned as we're rebuilding a couple of these servers currently.
Will.
I personally still don't see any need to drop qmail per se, but everything you're doing should be completely functional under one MTA.
That whole sendmail --> qmail --> sendmail sounds like bandaids upon bandaids, piled on top of bandaids to me. I mean, yeah, it works, but rebuilding that application from functional spec is fairly trivial, fairly easy to implement, and will greatly reduce the complexity of your architecture.
In our case, we use qmail because:
A) It satisfies all of our particular requirements.
B) We have a custom MySQL authentication/delivery process that was written in house. Although at this point, there's no cat left there, either.
C) We do more than just email with our setup. Our MySQL authentication drives a bunch of other applications, so unless we want to build everything back out from scratch, we're do it like so.
That being said, while there's things I'd replace in the application infrastructure, qmail's probably not one of them. Everything I know about mail and SMTP pretty much, I learned from qmail, qmail-related documentation, or pointers to more complete documentation I probably wouldn't have looked at had I not been referred to them in a roundabout way from qmail.
Peter
Les Mikesell wrote:
Doesn't everything do virtual domains these days? Sendmail has had them for ages, although perhaps not quite the same way. And everything that can use procmail for delivery (the default for sendmail in Centos) can deliver to maildirs.
Even qmail can route mail through procmail. Of course then, with qmail, you don't have to for Maildir delivery though. :P I have heard of oldschool procmail recipes from way back in the day though that dealt with spam, but that cat's been skinned about 200 other ways since then.
It's a very bad idea to let an unmodified qmail accept mail directly since it accepts all addresses, then later generates bounces to the ones that it can't deliver. A dictionary attack will bury your outbound queue.
Yeah, and unfortunately, there's only *umpteen* patches that deal with that. That dropping SMTP before accepting the messages into the queue cat has had it's skin removed so many times there's no cat left, as well.
Peter
Peter Serwe wrote:
It's a very bad idea to let an unmodified qmail accept mail directly since it accepts all addresses, then later generates bounces to the ones that it can't deliver. A dictionary attack will bury your outbound queue.
Yeah, and unfortunately, there's only *umpteen* patches that deal with that. That dropping SMTP before accepting the messages into the queue cat has had it's skin removed so many times there's no cat left, as well.
The old problems in sendmail have been fixed long ago as well. The difference is that you don't have to assemble the umpteen patches yourself to get a usable copy and if there is a new update you can pick it up immediately from the distribution via 'yum update'. Apparently, qmail's author won't allow anyone else to correct his work.
If I seem a little bitter about this, it is because the domain where qmail accepted those dictionary attack messages is _still getting_ about 50,000 messages a day to non-existent users several years later. The addresses must have made it onto some spam list because they were accepted once. Fortunately, sendmail rejects them quickly now...
Will McDonald wrote:
On 05/02/07, Jim Perrin jperrin@gmail.com wrote:
IIRC correctly, this is the (in)famous errno problem. It requires a
patch to
put qmail at 1.03. Life with qmail has all the instruction you need
to patch
and install qmail. There's a script to do it all for you. Qmail is
really
straight forward provided you follow the install directions to the
letter.
Once you do, you'll have the best SMTP server running.
*COUGH*
<flame war> So... the patch upgrades qmail to postfix?
/runs
Meeeoow! :)
I HAVE to run Qmail because it's a legacy requirement. If I could find something with similar virtual domain and Maildir support (and for all I know Postfix or Exim may provide these) and a nice transition path I'm stuck with it.
Do you make extensive use of .qmail files?
postfix supports maildir delivery and virtual mailboxes but whether you can move to postfix depends on how much of qmail's qmail-local's features you are using.
Hi Will --
We switched to Courier (http://www.courier-mta.org/) several years back, having used qmail before that. We've found that it suites our needs very well. It behaves a lot like qmail with respect to .qmail files and its control files, and avoids many of the issues (both technical and otherwise) with (an unpatched) qmail.
It's even possible to run ezmlm-idx for inbound mail under Courier; one does have to do an install of qmail for outbound stuff. (Make sure to add smtproute info into qmail so it doesn't attempt local delivery for outbound messages that are local.) Having qmail for outbound ezmlm stuff has the side benefit of creating a second queue, so that normal Courier users don't have their messages competing with the list traffic.
best, Jeff
On Feb 5, 2007, at 8:05 PM, Will McDonald wrote:
On 05/02/07, Jim Perrin jperrin@gmail.com wrote:
IIRC correctly, this is the (in)famous errno problem. It
requires a patch to
put qmail at 1.03. Life with qmail has all the instruction you
need to patch
and install qmail. There's a script to do it all for you. Qmail
is really
straight forward provided you follow the install directions to
the letter.
Once you do, you'll have the best SMTP server running.
*COUGH*
<flame war> So... the patch upgrades qmail to postfix?
/runs
Meeeoow! :)
I HAVE to run Qmail because it's a legacy requirement. If I could find something with similar virtual domain and Maildir support (and for all I know Postfix or Exim may provide these) and a nice transition path I'm stuck with it.
And let me throw in to the ring, there's a nicely RPM packaged Qmail package conglomerate at http://www.qmailtoaster.com/ And we all know that packages are the way ahead, right? :)
Complete with CentOS instructions http://www.qmailtoaster.com/centos/cnt40/EZ-QmailToaster- CentOS-4.3.txt
Personally, I hack around with the SPECs before building to strip out the MySQL and other features and just use Qmail listening on localhost only for the very final Maildir delivery after messages have been dealt with by MailScanner and Sendmail, then Courier and VPOPMail for POP3 and IMAP.
Will. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Will McDonald wrote:
Meeeoow! :)
I HAVE to run Qmail because it's a legacy requirement. If I could find something with similar virtual domain and Maildir support (and for all I know Postfix or Exim may provide these) and a nice transition path I'm stuck with it.
And let me throw in to the ring, there's a nicely RPM packaged Qmail package conglomerate at http://www.qmailtoaster.com/ And we all know that packages are the way ahead, right? :)
Complete with CentOS instructions http://www.qmailtoaster.com/centos/cnt40/EZ-QmailToaster-CentOS-4.3.txt
Personally, I hack around with the SPECs before building to strip out the MySQL and other features and just use Qmail listening on localhost only for the very final Maildir delivery after messages have been dealt with by MailScanner and Sendmail, then Courier and VPOPMail for POP3 and IMAP.
Personally, I've just hacked around with my own .spec to add/remove features as I see fit. I cannot for the life of me imagine though why somebody would run qmail just for Maildir delivery when it functions quite well as an MTA using MailScanner and <insert_anti-virus_software_of_choice_here>?
I wouldn't trade my morercpthosts.cdb, or aliases.cdb (using fastforward), for anything. And integration of just about anything you want in the delivery stream with .qmail-default and /var/qmail/users/assign rocks.
Inter7's vpopmail is also quite a nice virtualdomains package, using the same facilities.
Sendmail just makes me want to go "ewwww!".
And yes, I'm typing this while happily wearing my Nomex suit sitting in my nuclear blast bunker.
Peter
-
Feizhou -
Jeff -
Jim Perrin -
Johnny Hughes -
Les Mikesell -
Mark Schoonover -
Peter Serwe -
R Lists06 -
Scott Silva -
Will McDonald