See sendmail, postfix, Exim, qmail, dovecot, cyrus, Zimbra all related mail world.

regards, Santiago N.

------------------------------------------------------------------------

El lun, 23-11-2009 a las 08:55 -0800, John R Pierce escribió:

Susan Day wrote:

...

Hi; I don't want sendmail. What's a good secure email server that I can yum? I really only need smtp right now, but who knows what the future will bring?

SMTP only provides for relaying mail. a mail server typically needs a MTA (message transfer agent, smtp such as sendmail, postfix), a MDA (message delivery agent, such as procmail), and a MUA (message user agent, such as POP, IMAP, and various local unix mail readers).

any mail server is only as secure as you configure it. the usual alternative to sendmail is postfix, which many people find simpler to configure than sendmail.

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Hi folks

I have a Centos 5.3 Box and I'm trying to setup an small wireless link with the AP of a neighbour. I have a brand new NETGEAR WG111V2 USB-WIFI adaptor for that, but Centos doesn't recognize that. Any suggestions? I already tested it on windows XP and the link works fine. How can I do this on Centos?

What kind of encryption is it using?

Oh, and does your neighbor know about this?

mark

Davy Leon wrote:

Hi

There is no encryption and my neighbour knows about it, we are just trying to build an small network for our computers. Centos doesn't recognize the USB device. I just plug ot in and nothing happens.

Any suggestions?

David

What chipset does the device use? Elrepo has drivers and firmware for many wireless devices.

Davy Leon wrote:

[root@linux ~]# lsusb Bus 001 Device 004: ID 0846:6a00 NetGear, Inc. WG111 WiFi (v2) Bus 001 Device 001: ID 0000:0000 Bus 001 Device 002: ID 046d:c016 Logitech, Inc. M-UV69a Optical Wheel Mouse Bus 002 Device 001: ID 0000:0000

so, is Realtek RTL-8187L chipset

As suspected, grepping modules.alias shows that Vendor:Device ID to match rtl8187.ko:

grep 0846 /lib/modules/2.6.18-164.6.1.el5/modules.alias | grep -i 6a00 alias usb:v0846p6A00d*dc*dsc*dp*ic*isc*ip* rtl8187

so try loading the module:

modprobe rtl8187

if it's not already loaded.

At Mon, 30 Nov 2009 11:53:34 -0500 CentOS mailing list centos@centos.org wrote:

Hi

There is no encryption and my neighbour knows about it, we are just trying to build an small network for our computers. Centos doesn't recognize the USB device. I just plug ot in and nothing happens.

Any suggestions?

What shows up in /var/log/messages when you plug in the device? Do a 'sudo tail -f /var/log/messages' and then plug in the device. Copy and paste the usb / udev blather into an E-Mail message. Should start with something like this:

Nov 29 19:50:04 sauron kernel: usb 7-3: new full speed USB device using address 3

David

----- Original Message ----- From: m.roth@5-cent.us To: "CentOS mailing list" centos@centos.org Sent: Monday, November 30, 2009 11:32 AM Subject: Re: [CentOS] Wireless

...

...

Hi folks

I have a Centos 5.3 Box and I'm trying to setup an small wireless link with the AP of a neighbour. I have a brand new NETGEAR WG111V2 USB-WIFI adaptor for that, but Centos doesn't recognize that. Any suggestions? I already tested it on windows XP and the link works fine. How can I do this on Centos?

What kind of encryption is it using?

Oh, and does your neighbor know about this?

   mark

Nov 29 19:50:04 sauron kernel: usb 7-3: new full speed USB device using address 3

...

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

On Mon, Nov 23, 2009 at 11:55 AM, John R Pierce pierce@hogranch.com wrote:

Susan Day wrote:

...

Hi; I don't want sendmail. What's a good secure email server that I can yum? I really only need smtp right now, but who knows what the future will bring?

SMTP only provides for relaying mail. a mail server typically needs a MTA (message transfer agent, smtp such as sendmail, postfix), a MDA (message delivery agent, such as procmail), and a MUA (message user agent, such as POP, IMAP, and various local unix mail readers).

any mail server is only as secure as you configure it. the usual alternative to sendmail is postfix, which many people find simpler to configure than sendmail.

Thanks! Suzie

fred smith wrote:

On Mon, Nov 23, 2009 at 08:55:38AM -0800, John R Pierce wrote:

...

Susan Day wrote:

...

Hi; I don't want sendmail. What's a good secure email server that I can yum? I really only need smtp right now, but who knows what the future will bring?

SMTP only provides for relaying mail. a mail server typically needs a MTA (message transfer agent, smtp such as sendmail, postfix), a MDA (message delivery agent, such as procmail), and a MUA (message user agent, such as POP, IMAP, and various local unix mail readers).

any mail server is only as secure as you configure it. the usual alternative to sendmail is postfix, which many people find simpler to configure than sendmail.

:) but then what ISN'T simpler to configure than sendmail? :)

Hardly anything, given that it is almost completely done for you in the supplied /etc/mail/sendmail.mc file. You just have to fix the intentionally-borked DAEMON_OPTIONS if you want to receive outside mail, fill in SMART_HOST if you'd like another machine to relay for you, and add entries in the access file for networks you want to relay for. And restarting the sendmail service will do the updates you need after changing these files.

Beyond that, you'd probably want to add a milter like MimeDefang so you can do anything complex and non-standard in perl.

...

As others have already suggested, consider Postfix.

I'm putting in my $0.02(US) so I can add my experience when I first had a need for a decent MTA. I had used Sendmail in the past, but I didn't want to fight with the arcane syntax of the config files, and at that time the add-on management tools and scripts were not nearly as friendly to a beginner.

When Postfix was suggested to me, I started reading the docs on their Web site, and discovered that the learning curve is nowhere near as steep as it is with Sendmail. So far, Postfix has done everything I have needed, and with a LOT less pain.

As always, YMMV.

+1. Let me throw in something else. If youa re sending more than one email at a time (to more than one person simultaneously), Postfix will beat Sendmail. It can handle high loads better than Sendmail as well. Is it the fastest MTA out there? Doing some Google Fu some time ago, it's right there with the very fastest ones. For my job, I need to send out emergency notifications to 400 people at once. With Sendmail, that took over 7 minutes. With Postfix, that takes seconds, and mostly because of the "handshaking" with the downstream host. If it's fast, I haven't even got time to send the message, get to a command prompt and type "mailq" and see it leaving the outbox queue...because it is already gone!

Gilbert

I can second this; having deployed a bunch of mailing list servers myself, I can tell postfix is _very_ efficient. One can tweak it even further using multiple instances [0], thusly each 'tuneable' to special purposes (e.g., serving mailing lists).

exim [1] also is very powerful and on some topics even more configureable, but IMHO not as easily implemented as postfix and, due to it's design, not as efficient.

[0] -- http://www.postfix.org/MULTI_INSTANCE_README.html

[1] -- http://exim.org/

---

Gilbert Sebenste ******** (My opinions only!) ******

---

Les Mikesell wrote:

Gilbert Sebenste wrote:

...

On Mon, 23 Nov 2009, Ron Loftin wrote:

...

As others have already suggested, consider Postfix.

I'm putting in my $0.02(US) so I can add my experience when I first had a need for a decent MTA. I had used Sendmail in the past, but I didn't want to fight with the arcane syntax of the config files, and at that time the add-on management tools and scripts were not nearly as friendly to a beginner.

When Postfix was suggested to me, I started reading the docs on their Web site, and discovered that the learning curve is nowhere near as steep as it is with Sendmail. So far, Postfix has done everything I have needed, and with a LOT less pain.

As always, YMMV.

+1. Let me throw in something else. If youa re sending more than one email at a time (to more than one person simultaneously), Postfix will beat Sendmail. It can handle high loads better than Sendmail as well. Is it the fastest MTA out there? Doing some Google Fu some time ago, it's right there with the very fastest ones. For my job, I need to send out emergency notifications to 400 people at once. With Sendmail, that took over 7 minutes.

That doesn't make any sense unless you have a backed up queue with at least many thousands of messages - in which case you should tune sendmail to use multiple queue directories.

Maybe he is not using the esmtp mailer. Not doing pipe-lining can make that difference.

Les Mikesell wrote:

Susan Day wrote:

...

Hi; I don't want sendmail. What's a good secure email server that I can yum? I really only need smtp right now, but who knows what the future will bring?

Postfix is probably a reasonable choice, but I'm curious as to how you reached the decision that you don't want to use the standard, mostly-preconfigured tool without already knowing anything about the other choices. Sendmail may have a long history of exploits back in the day with it was monolithic and ran as root, but now it is probably the most carefully audited piece of code shipped in the distribution. The milter interface developed for sendmail (and now also implemented in postfix) lets you add functionality that wasn't designed in, so it is hard to imagine a mail job or environment that either couldn't handle.

I don't see sendmailX on Centos at the moment...do you? It is therefore still monolithic as far as Centos is concerned.

postfix comes with mysql/postgresql support and with connection pooling at that and which can be used directly in a lot of built-in features of postfix. Unless the supporting stuff in the milters are as efficient as what you can get in postfix, sendmail + milters might be hard pressed to handle some environments that postfix can.

Les Mikesell wrote:

Christopher Chan wrote:

...

Les Mikesell wrote:

...

Susan Day wrote:

...

Hi; I don't want sendmail. What's a good secure email server that I can yum? I really only need smtp right now, but who knows what the future will bring?

Postfix is probably a reasonable choice, but I'm curious as to how you reached the decision that you don't want to use the standard, mostly-preconfigured tool without already knowing anything about the other choices. Sendmail may have a long history of exploits back in the day with it was monolithic and ran as root, but now it is probably the most carefully audited piece of code shipped in the distribution. The milter interface developed for sendmail (and now also implemented in postfix) lets you add functionality that wasn't designed in, so it is hard to imagine a mail job or environment that either couldn't handle.

I don't see sendmailX on Centos at the moment...do you? It is therefore still monolithic as far as Centos is concerned.

By not-monolithic, I mean that now submission queuing, forwarding, and local delivery are all different processes, each running with limited credentials most of the time. And milters also can run under different uids.

All that means naught if there is a remote root exploit. sendmail 8.12.x already worked like that.

...

postfix comes with mysql/postgresql support and with connection pooling at that and which can be used directly in a lot of built-in features of postfix.

You probably really want ldap for that sort of thing.

You probably really want to reconsider using ldap for anything that gets loads of changes daily.

...

Unless the supporting stuff in the milters are as efficient as what you can get in postfix, sendmail + milters might be hard pressed to handle some environments that postfix can.

MimeDefang gets this right - it runs as a multiplexor that connects multiple processes as needed so you don't have a 1:1 ratio of mailers to backend milters and you don't have fast step waiting on slow steps to complete. See page 31 of http://www.mimedefang.org/static/mimedefang-lisa04.pdf. Most other approaches use simple pipelines that make everything wait while spamassin runs and have to reparse the mime headers to break out attachments for each scanning step. Some very large sites are running it.

I fail to see how that becomes an advantage for sendmail. I can very well pair postfix and mimedefang for just spamassassin and the rest of the stuff handled by native postfix features. That at the very least cuts out another layer to go through for postfix. In the end, sendmail is at a disadvantage having to depend on a third party for extra features.

Sent from my iPhone

On Nov 23, 2009, at 6:14 PM, Les Mikesell lesmikesell@gmail.com wrote:

On the contrary, having the ability to extend through external software gives you unlimited options. Note that postfix eventually got around to copying this feature. Also with mimedefang you can do most of your special configuration in perl instead of having to learn yet another syntax.

Hmm... I wouldn't exactly call that an advantage... I'd much rather plug in a kilter and spend 20 minutes configuring it properly than have to wrestle custom perl for getting mail flowing...

Les Mikesell wrote:

Christopher Chan wrote:

...

...

By not-monolithic, I mean that now submission queuing, forwarding, and local delivery are all different processes, each running with limited credentials most of the time. And milters also can run under different uids.

All that means naught if there is a remote root exploit. sendmail 8.12.x already worked like that.

How do you have a remote root exploit if you aren't running as root?

Ask the sendmail advisories for 8.12.x.

...

...

...

Unless the supporting stuff in the milters are as efficient as what you can get in postfix, sendmail + milters might be hard pressed to handle some environments that postfix can.

MimeDefang gets this right - it runs as a multiplexor that connects multiple processes as needed so you don't have a 1:1 ratio of mailers to backend milters and you don't have fast step waiting on slow steps to complete. See page 31 of http://www.mimedefang.org/static/mimedefang-lisa04.pdf. Most other approaches use simple pipelines that make everything wait while spamassin runs and have to reparse the mime headers to break out attachments for each scanning step. Some very large sites are running it.

...

I fail to see how that becomes an advantage for sendmail.

It lets you control load very precisely. You can limit sendmail to some number of instances that can be much larger than the number of big/slow scanning backend processes that you permit and the sendmails don't wait for the milters until/unless they need one of their functions and you don't have to start a new process for each message.

Sorry, I meant to say, an advantage for sendmail over postfix.

...

I can very well pair postfix and mimedefang for just spamassassin and the rest of the stuff handled by native postfix features.

Where does your virus scan go? Since spamassassin is perl, MimeDefang can run it internally.

You know the answer to that one. If I am going to use MimeDefang for spamassassin and postfix obviously does not have anti-virus features (unless you call using body_checks to check for known patterns anti-virus support) where do you think I would plug in anti-virus support? Again, in a sendmail + mimedefang versus postfix + mimedefang, sendmail is the loser.

...

That at the very least

...

cuts out another layer to go through for postfix. In the end, sendmail is at a disadvantage having to depend on a third party for extra features.

On the contrary, having the ability to extend through external software gives you unlimited options. Note that postfix eventually got around to copying this feature. Also with mimedefang you can do most of your special configuration in perl instead of having to learn yet another syntax.

Simply because it made sense to use available existing tools that support spamassassin and virus scanners than make yet another interface. No more smtp proxying. Good riddance amavisd. postfix was after all a replacement for sendmail and it would be incomplete without milter support.

Les Mikesell wrote:

Christopher Chan wrote:

...

...

How do you have a remote root exploit if you aren't running as root?

Ask the sendmail advisories for 8.12.x.

Wasn't the last bug found and fixed 5 or 6 years ago?

Which is great. Just saying that if there is one still lurking around, the current model of operation might still be vulnerable.

...

...

...

I fail to see how that becomes an advantage for sendmail.

It lets you control load very precisely. You can limit sendmail to some number of instances that can be much larger than the number of big/slow scanning backend processes that you permit and the sendmails don't wait for the milters until/unless they need one of their functions and you don't have to start a new process for each message.

Sorry, I meant to say, an advantage for sendmail over postfix.

I've been using it with sendmail for many years. Postfix has only recently added milter support and only very recently made it good enough to work with mimedefang. I don't know if it does the session multiplexing as efficiently - maybe...

I was the under the impression that it was mimedefang that handled that and not sendmail? In any case, postfix has long had very good multiplexing.

...

You know the answer to that one. If I am going to use MimeDefang for spamassassin and postfix obviously does not have anti-virus features (unless you call using body_checks to check for known patterns anti-virus support) where do you think I would plug in anti-virus support? Again, in a sendmail + mimedefang versus postfix + mimedefang, sendmail is the loser.

If you just started to use email, perhaps.

Ho hum. I do not know why you keep insisting that letting mimedefang handle say lookups to mysql and perform decisions based on those is faster than if sendmail had native support. It is after all, one less layer to going through and not run in something that is interpreted.

...

...

On the contrary, having the ability to extend through external software gives you unlimited options. Note that postfix eventually got around to copying this feature. Also with mimedefang you can do most of your special configuration in perl instead of having to learn yet another syntax.

Simply because it made sense to use available existing tools that support spamassassin and virus scanners than make yet another interface. No more smtp proxying. Good riddance amavisd. postfix was after all a replacement for sendmail and it would be incomplete without milter support.

And it was incomplete for a long time. Which is why sendmail is the standard.

More and more distributions are using postfix as the default even though it does not allow delivery to root. That 'is' will soon become 'was' despite its incomplete milter support. I guess milters are not all that standard then. So many alternatives to milters out there that got established when milters just were not stable enough (no fault of sendmail) so that today milters are not quite as well known as stuff like resource hog amavisd.

...

Ho hum. I do not know why you keep insisting that letting mimedefang handle say lookups to mysql and perform decisions based on those is faster than if sendmail had native support. It is after all, one less layer to going through and not run in something that is interpreted.

It's not faster for that operation, but compared to database lookups a couple more CPU instructions aren't significant and it is more powerful. What you get is a point where you can do any additional operations if you want, regardless of whether the MTA author considered it or not. And, in cases where the program you want to access isn't an already running daemon like mysql, you get a way to run it that doesn't need a 1:1 relationship to the mailer processes.

I doubt that making calls via mimedefang is just a 'couple more' cpu instructions over internal calls within postfix.

But yes, it would be nice for other non-daemonized stuff.

So just chalk sendmail down one notch for lack of multiplexed mysql/postgresql support versus postfix will you? mimedefang cannot completely rectify that for sendmail.

Les Mikesell wrote:

Christopher Chan wrote:

...

...

Wasn't the last bug found and fixed 5 or 6 years ago?

Which is great. Just saying that if there is one still lurking around, the current model of operation might still be vulnerable.

That was a joke, since you can never know when the last bug is found,

The last bug is found when the software is sundowned.

Isn't that one of the axioms of software development?

but I'm comfortable with old code where you know at least some of the bugs have been fixed.

...

...

I've been using it with sendmail for many years. Postfix has only recently added milter support and only very recently made it good enough to work with mimedefang. I don't know if it does the session multiplexing as efficiently - maybe...

I was the under the impression that it was mimedefang that handled that and not sendmail? In any case, postfix has long had very good multiplexing.

MimeDefang multiplexes the client calls to the backend handlers, but the model was designed around sendmail. It might happen to work as well with postfix.

...

Ho hum. I do not know why you keep insisting that letting mimedefang handle say lookups to mysql and perform decisions based on those is faster than if sendmail had native support. It is after all, one less layer to going through and not run in something that is interpreted.

It's not faster for that operation, but compared to database lookups a couple more CPU instructions aren't significant and it is more powerful. What you get is a point where you can do any additional operations if you want, regardless of whether the MTA author considered it or not. And, in cases where the program you want to access isn't an already running daemon like mysql, you get a way to run it that doesn't need a 1:1 relationship to the mailer processes.

Eero Volotinen wrote:

...

...

...

How do you have a remote root exploit if you aren't running as root?

Ask the sendmail advisories for 8.12.x.

Wasn't the last bug found and fixed 5 or 6 years ago?

and still lots of more lurking in the dark corners of sendmail?

Probably not, or someone would have found them in the last five years.

At least I don't want to run software with poor security track on my public servers.

So you don't run the Linux kernel? Wade through the changelog sometime. Or BIND? it is unrealistic to think large software packages don't have bugs or that they won't be found and fixed over time.

thus Eero Volotinen spake:

...

Probably not, or someone would have found them in the last five years.

Probably yes, it's hard to security audit complex software packages.

Yes; my bet would be that OpenBSD's smtpd will be the most secure MTA (when it hits the streets for production). That does NOT mean that it is scalable (well, yet to prove).

...

...

At least I don't want to run software with poor security track on my public servers.

So you don't run the Linux kernel? Wade through the changelog sometime. Or BIND? it is unrealistic to think large software packages don't have bugs or that they won't be found and fixed over time.

I usually prefer softwares with good security track. Anyway kernel is not usually exposed directly to internet,

An IP stack which is part of the kernel *is* (more or less) directly exposed to the internet as long as there's the appropriate cable connected to that machine.

but some server software are directly. Eero

Regards,

Timo

thus Eero Volotinen spake:

...

An IP stack which is part of the kernel *is* (more or less) directly exposed to the internet as long as there's the appropriate cable connected to that machine.

Yes, I hope that IP-stack is not so buggy. Anyway, I think that is easier to exploit systems via normal tcp connection as the kernel ip stack.

You probably mean protocols on and/or above layer five. ;)

Anyway, I think that unprotected sshd is bigger risk than postfix or sendmail. Personally I cannot trust sendmail, so I am running postfix on most of mailiservers.

-- Eero

Timo

IP machinery is simple enough, but then there is ICMP and ICMP6, and IPv6 Neighbor discovery, and....

Yes and lot of firewalls even lacks IPv6 support even nowdays..

-- Eero

Eero Volotinen wrote:

...

An IP stack which is part of the kernel *is* (more or less) directly exposed to the internet as long as there's the appropriate cable connected to that machine.

Yes, I hope that IP-stack is not so buggy. Anyway, I think that is easier to exploit systems via normal tcp connection as the kernel ip stack.

Anyway, I think that unprotected sshd is bigger risk than postfix or sendmail. Personally I cannot trust sendmail, so I am running postfix on most of mailiservers.

What basis do you have for not trusting sendmail? This may be biased, but it's probably the most accurate assessment of the code we are running that we are likely to get: Old history here: http://magazine.redhat.com/2009/03/10/risk-report-four-years-of-red-hat-ente... Note 1 bug in sendmail, fixed before publically announced (and long ago). This is out of 130 critical bugs in the distribution. Note also that sendmail does not appear in the 'riskiest packages' list, but the kernel is right up there at number 4, php at #9.

The more current list is at: http://www.redhat.com/security/data/metrics/summary-rhel5-all.html Don't see anything about sendmail in that list of 616 issues. I do see a security related bugfix for postfix here: http://rhn.redhat.com/errata/rhel-server-errata.html Maybe you are worrying about the wrong thing.

thus Robert Moskowitz spake:

Timo Schoeler wrote:

...

thus Eero Volotinen spake:

...

...

Probably not, or someone would have found them in the last five years.

Probably yes, it's hard to security audit complex software packages.

Yes; my bet would be that OpenBSD's smtpd will be the most secure MTA (when it hits the streets for production). That does NOT mean that it is scalable (well, yet to prove).

...

...

...

At least I don't want to run software with poor security track on my public servers.

So you don't run the Linux kernel? Wade through the changelog sometime. Or BIND? it is unrealistic to think large software packages don't have bugs or that they won't be found and fixed over time.

I usually prefer softwares with good security track. Anyway kernel is not usually exposed directly to internet,

An IP stack which is part of the kernel *is* (more or less) directly exposed to the internet as long as there's the appropriate cable connected to that machine.

I am working on Smart Grid and am hearing talk about we can secure the Smart Grid with Layer 2 security and we are done. ARGH!!!! I gave a presentation on this at the 802 meeting last week. Sometimes I feel like I am beating on mush...

Ah, you're talking of 802.1x? Nothing funnier than marketing guys telling you how to secure and run your network. ;)

Timo

Eero Volotinen wrote:

I usually prefer softwares with good security track. Anyway kernel is not usually exposed directly to internet, but some server software are directly.

where do you think IP packets get processed?

On 11/23/2009 08:37 PM, Les Mikesell wrote:

Wasn't the last bug found and fixed 5 or 6 years ago?

No. Earlier this year there was a heap overflow found that may allow arbitrary code execution: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-1490

On Nov 23, 2009, at 5:34 PM, Christopher Chan <christopher.chan@bradbury.edu.hk

wrote:

Les Mikesell wrote:

...

...

You probably really want ldap for that sort of thing.

You probably really want to reconsider using ldap for anything that gets loads of changes daily.

In the case of a mail relay, at one point years back I decided to drop (not bounce) all email to bogus recipients at the relay level rather than let it get to (yuck) Exchange, which would bounce it. The trick was having an updated recipient list. My first thought was to query Active Directory for each user, thus getting an up-to-date result.

This turned out to be a *bad* idea for a couple of reasons. 1) if I can't reach AD, mail won't queue up on the relays, which is one of their major functions. 2) I'm making the relays directly dependent on AD latency. 3) any flood of email from outside can cause a large amount of queries against AD, causing a DOS that the relays are supposed to shield the internal network from.

So instead, I found a script to gather the list of users from AD, did some modifications and wrote some wrappers. The result? A script that runs from cron to get the list of valid addresses, convert them into an access file that sendmail (or postfix, in the first case years ago) can use instead. There's a little more latency, but as long as I do some sanity checking (too many changes? Send an alert and don't change the access file) it works just fine. Ldap-based, yes. But loosely coupled. A good compromise in my experience...

On Tue, 2009-11-24 at 11:00 +0800, Christopher Chan wrote:

Ian Forde wrote:

...

On Nov 23, 2009, at 5:34 PM, Christopher Chan <christopher.chan@bradbury.edu.hk mailto:christopher.chan@bradbury.edu.hk> wrote:

...

Les Mikesell wrote:

...

...

You probably really want ldap for that sort of thing.

You probably really want to reconsider using ldap for anything that gets loads of changes daily.

In the case of a mail relay, at one point years back I decided to drop (not bounce) all email to bogus recipients at the relay level rather than let it get to (yuck) Exchange, which would bounce it. The trick was having an updated recipient list. My first thought was to query Active Directory for each user, thus getting an up-to-date result.

This turned out to be a *bad* idea for a couple of reasons. 1) if I can't reach AD, mail won't queue up on the relays, which is one of their major functions. 2) I'm making the relays directly dependent on AD latency. 3) any flood of email from outside can cause a large amount of queries against AD, causing a DOS that the relays are supposed to shield the internal network from.

So instead, I found a script to gather the list of users from AD, did some modifications and wrote some wrappers. The result? A script that runs from cron to get the list of valid addresses, convert them into an access file that sendmail (or postfix, in the first case years ago) can use instead. There's a little more latency, but as long as I do some sanity checking (too many changes? Send an alert and don't change the access file) it works just fine. Ldap-based, yes. But loosely coupled. A good compromise in my experience...

Precisely why a buffer like this for sites with a very large user base might want to use cdb. postfix supports cdb and sendmail can get cdb support from sf.net/sendmail-cdb. Both need the tinycdb library though. Even mysql/postgresql could do with a break for legit users.

---- considering that LDAP is optimized for high amounts of read and minimal writes, the problem with any SMTP daemon querying an LDAP server getting bogged down suggests that other problems are at hand and should be solved. I mean if the primary user/authentication system can't handle the load, you got problems.

I admire the workarounds but damn, you have to solve the problems anyway because this surely isn't the only place where this is a problem.

Craig

Christopher Chan wrote:

Ian pointed how he needs to 'replicate' a local copy of user 'accounts' from Exchange so that he does not kill Exchange. I just pointed out that this sort of thing can be done also for sites with a very large user base that will want something that is more efficient that Berkeley DB.

There might be a few places big enough where using cdb vs. the built in bdb for the virtuser table would matter. But very few.

You can chain lookups in postfix. Check cdb, then check mysql/postgresql. If the account exists in the cdb, then there is no need to check mysql/postgresql. So essentially only non-existent addresses and recently created addresses will result in hits to mysql/postgresql. This is not a work around. This is performance enhancement. Whacking a local cdb will be faster than whacking a mysql/postgresql database. Geez.

If you have a reasonably fast internal mailer you can just let mimedefang on your external relay check against it with smtp in real time. Exchange isn't one of those, though.

Christopher Chan wrote:

...

If you have a reasonably fast internal mailer you can just let mimedefang on your external relay check against it with smtp in real time. Exchange isn't one of those, though.

That internal mailer still has to whack something. You would just be adding another layer again with the smtp latency. What is with the love of uber number of layers?

You are removing a layer if you just pass through the recipient check to the ultimate source (the internal delivery machine) before accepting, and it does in fact need to be able to handle the lookups at the speed real messages come in. However, your external relay is likely to get whacked with a dictionary attack that it needs to be able to reject quickly so you can't do that if the delivery box is slow.

I used qmail for one of my domains a while back and it's practice of accepting everything, then sending bounces got a dictionary attack onto some kind of 'good to spam' list and I got about 50,000 messages/day for non-existing users for years afterwards. That was a problem until I put a sendmail with the good users in a virtuser table in front of it. Interestingly, the messages would come in from a large number of different IP addresses but in a sorted order and with clearly coordinated timing.

Christopher Chan wrote:

...

...

You are removing a layer if you just pass through the recipient check to the ultimate source (the internal delivery machine) before accepting, and it does in fact need to be able to handle the lookups at the speed real messages come in. However, your external relay is likely to get whacked with a dictionary attack that it needs to be able to reject quickly so you can't do that if the delivery box is slow.

OH are we? So what happens when the frontend hands off to the internal delivery machine? Does not the internal delivery machine again do another lookup?

Yes, but it is pretty unlikely that the results will be different since they are both done quickly against the authoritative source. Unlike if you had made an intermediate copy of the database.

...

I used qmail for one of my domains a while back and it's practice of accepting everything, then sending bounces got a dictionary attack onto some kind of 'good to spam' list and I got about 50,000 messages/day for non-existing users for years afterwards. That was a problem until I put a sendmail with the good users in a virtuser table in front of it. Interestingly, the messages would come in from a large number of different IP addresses but in a sorted order and with clearly coordinated timing.

/me shudders to think of anyone running a pure qmail-1.03 for a mx.

But no one could convince the author that it was anything short of perfect - or that anyone else was qualified to touch the code.

Christopher Chan wrote:

Craig White wrote:

...

On Tue, 2009-11-24 at 11:00 +0800, Christopher Chan wrote:

...

Ian Forde wrote:

...

On Nov 23, 2009, at 5:34 PM, Christopher Chan <christopher.chan@bradbury.edu.hk mailto:christopher.chan@bradbury.edu.hk> wrote:

...

Les Mikesell wrote:

...

You probably really want ldap for that sort of thing.

You probably really want to reconsider using ldap for anything that gets loads of changes daily.

In the case of a mail relay, at one point years back I decided to drop (not bounce) all email to bogus recipients at the relay level rather than let it get to (yuck) Exchange, which would bounce it. The trick was having an updated recipient list. My first thought was to query Active Directory for each user, thus getting an up-to-date result.

This turned out to be a *bad* idea for a couple of reasons. 1) if I can't reach AD, mail won't queue up on the relays, which is one of their major functions. 2) I'm making the relays directly dependent on AD latency. 3) any flood of email from outside can cause a large amount of queries against AD, causing a DOS that the relays are supposed to shield the internal network from.

So instead, I found a script to gather the list of users from AD, did some modifications and wrote some wrappers. The result? A script that runs from cron to get the list of valid addresses, convert them into an access file that sendmail (or postfix, in the first case years ago) can use instead. There's a little more latency, but as long as I do some sanity checking (too many changes? Send an alert and don't change the access file) it works just fine. Ldap-based, yes. But loosely coupled. A good compromise in my experience...

Precisely why a buffer like this for sites with a very large user base might want to use cdb. postfix supports cdb and sendmail can get cdb support from sf.net/sendmail-cdb. Both need the tinycdb library though. Even mysql/postgresql could do with a break for legit users.

---

considering that LDAP is optimized for high amounts of read and minimal writes, the problem with any SMTP daemon querying an LDAP server getting bogged down suggests that other problems are at hand and should be solved. I mean if the primary user/authentication system can't handle the load, you got problems.

I was trumpeting postfix's mysql/postgresql support and then Les says LDAP is the way to go and then I point out that LDAP don't like heavy write environments and you are starting the circle again.

And how many LDAP implementations have mysql/postgresql behind the LDAP syntax?

So LDAP is frequently WORST than just a direct SQL table lookup.

At least the few that I have dealt with. I LIKE LDAP. Much better than DAP any day of the year ;)

/me tramples LDAP underfoot, gets a horse to trample LDAP, gets a tank to complete the job.

LDAP ain't THE SOLUTION for everything you know.

...

I admire the workarounds but damn, you have to solve the problems anyway because this surely isn't the only place where this is a problem.

Ian pointed how he needs to 'replicate' a local copy of user 'accounts' from Exchange so that he does not kill Exchange. I just pointed out that this sort of thing can be done also for sites with a very large user base that will want something that is more efficient that Berkeley DB. You can chain lookups in postfix. Check cdb, then check mysql/postgresql. If the account exists in the cdb, then there is no need to check mysql/postgresql. So essentially only non-existent addresses and recently created addresses will result in hits to mysql/postgresql. This is not a work around. This is performance enhancement. Whacking a local cdb will be faster than whacking a mysql/postgresql database. Geez. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Christopher Chan wrote:

...

And how many LDAP implementations have mysql/postgresql behind the LDAP syntax?

Okay, I will be honest, I do not have that much ldap experience but I was under the impression that they used Berkeley DB or something. I did not know that some had a sql backend...

...

So LDAP is frequently WORST than just a direct SQL table lookup

We LOVE LAYERS. The Linux Kernel loves layers. We have to follow suit!

...

.

At least the few that I have dealt with. I LIKE LDAP. Much better than DAP any day of the year ;)

Which ones are those?

DAP ::= Directory Access Protocol. The OSI way.

Then some english chap (been over a decade back) realized that all we needed was a Lightweight DAP in the true IETF way. Though you still find some DAPish things buried in backends that have one LDAP server asking another for data.

On Mon, 2009-11-23 at 13:30 -0500, Susan Day wrote:

On Mon, Nov 23, 2009 at 1:23 PM, Craig White craigwhite@azapple.com wrote: yum install postfix system-switch-mail # edit /etc/postfix/main.conf system-switch-mail # choose postfix, confirm # done

Craig, I stopped qmail, which I had installed outside of yum, turning off sendmail first, then I just did a yum install postfix and (I believe) /etc/init.d/postfix start or some such and it's sending email. All well, or should I do a yum remove postfix and then your commands?

---- No but you need to do this then...

chkconfig postfix on chkconfig sendmail off

and if there is some mechanism for starting qmail on startup, you will have to disable it...perhaps there is a sysv initscript that you can discover here...

chkconfig --list

Craig

Susan Day wrote:

On Mon, Nov 23, 2009 at 1:46 PM, Craig White <craigwhite@azapple.com mailto:craigwhite@azapple.com> wrote:

No but you need to do this then...

chkconfig postfix on
chkconfig sendmail off

and if there is some mechanism for starting qmail on startup, you will
have to disable it...perhaps there is a sysv initscript that you can

qmail usually uses daemon-tools. check supervise man page.

-- Eero

Susan Day wrote:

On Mon, Nov 23, 2009 at 1:23 PM, Craig White <craigwhite@azapple.com mailto:craigwhite@azapple.com> wrote:

yum install postfix system-switch-mail
# edit /etc/postfix/main.conf
system-switch-mail # choose postfix, confirm
# done

Craig, I stopped qmail, which I had installed outside of yum, turning off sendmail first, then I just did a yum install postfix and (I believe) /etc/init.d/postfix start or some such and it's sending email. All well, or should I do a yum remove postfix and then your commands?

What kind of email is it sending? Email accepted via smtp? What about system generated mail? Check that the symlinks are not still pointing to qmail. ls -l /usr/sbin/sendmail, ls -l /usr/lib/sendmail. If both these are pointing to something under /etc/alternatives then check those symlinks in /etc/alternatives. (mta-mailq, mta, mta-sendmail, etc)

On Mon, Nov 23, 2009 at 01:59:40PM -0500, Robert Moskowitz wrote:

It points you to: http://howtoforge.net/virtual-users-domains-postfix-courier-mysql-squirrelma...

Now granted this is for FC10, but I suspect it would be easy to fit into Centos.

Please, for the love of god and country, do not follow garbage like this. Under "1. Preliminary Note" is this text:

"You should make sure that the firewall is off (at least for now) and that SELinux is disabled (this is important!)".

Documents that advocate disabling SELinux should be tossed in a pile and set on fire. Documents that tell you to disable your firewall with no mention in the remaining portion of the document to reenable it post install or how to properly configure it should join the burn pile.

Howtoforge, while perhaps useful for *something* at *some* point in time, more often than not provides information which will either break your system outright or lead to tears and suffering before bedtime.

John

On 11/23/2009 2:21 PM, John R. Dennison wrote:

On Mon, Nov 23, 2009 at 01:59:40PM -0500, Robert Moskowitz wrote:

...

It points you to: http://howtoforge.net/virtual-users-domains-postfix-courier-mysql-squirrelma...

Now granted this is for FC10, but I suspect it would be easy to fit into Centos.

Please, for the love of god and country, do not follow garbage like this. Under "1. Preliminary Note" is this text:

"You should make sure that the firewall is off (at least for now) and that SELinux is disabled (this is important!)".

Documents that advocate disabling SELinux should be tossed in a pile and set on fire. Documents that tell you to disable your firewall with no mention in the remaining portion of the document to reenable it post install or how to properly configure it should join the burn pile.

+1... While SELinux can be a PITA at times, it's not going to go away anytime soon, so a smart sysadmin needs to learn to work with it rather then against it. HowTos that tell me to disable SELinux or a firewall are held at arms length and never to be followed literally. (They might contain some useful commands or configuration options... maybe.)

(personal rant)

You can do a lot of SELinux workarounds with brute-force egrep'ing of the audit log combined with audit2allow. It's not the best way to do it. If you have mislabeled files that are labeled with a generic var_t label, and you grant processes access to those files with blind acceptance of what audit2allow says, you're also granting access to every other file that is labeled as var_t. (Better choice would be to properly label the files that didn't get labeled correctly.)

But even a brute-force application of audit2allow is still a step up from disabling SELinux entirely.

(I have a love/hate relationship at times with SELinux. I need to spend another weekend reading up on it again and figuring out some of the things that I'm not sure about yet.)

Thomas Harold wrote:

On 11/23/2009 1:59 PM, Robert Moskowitz wrote:

...

Susan Day wrote:

...

Hi; I don't want sendmail. What's a good secure email server that I can yum? I really only need smtp right now, but who knows what the future will bring?

See my slightly prior post on: Re: [CentOS] smtp+pop3+imap+tls+webmail+anti spam+anti virus

We use postfix, dovecot, clamav milter (reject at SMTP time), spf policy check (with rejecting on SPF_FAIL at SMTP time), and AmavisD-New w/ SpamAssassin for scoring what's left.

Have you looked at spamass-milter too?

Thomas Harold wrote:

On 11/25/2009 6:45 PM, Christopher Chan wrote:

...

Thomas Harold wrote:

...

We use postfix, dovecot, clamav milter (reject at SMTP time), spf policy check (with rejecting on SPF_FAIL at SMTP time), and AmavisD-New w/ SpamAssassin for scoring what's left.

Have you looked at spamass-milter too?

No, I must have overlooked that.

We're taking advantage of a lot of the amavisd-new features that enhance SpamAssassin. OTOH, spamass-milter looks to be a lot simpler to configure and would've allowed us to reject the super-high scoring spam (>=25.0) during the SMTP transaction.

Heh. Showing guns at 10 over here.

(I prefer to only reject on bogus HELO names, virus-infected messages caught by ClamAV and SPF_FAILs at the moment. Rejecting on a spam score is trickier and more subjective.)

True that.

One advantage of amavisd-new is that we could, if needed, move the spam scoring off to a secondary internal server and round trip it back to the primary mail server. There are some other tricks that amavisd-new handles beyond that (such as the policy banks, or the ability to boost/lower a sender's email address or a sender's domain by a few points instead of outright whitelisting/blacklisting).

Hmm, same with spamass-milter. spamd running elsewhere and accepting queries over the network. I don't know how much of the rest is supported by spamassassin rules whether individual or site but I suspect the latter is doable.