Re: Advice on MTA blacklist
David B Funk wrote: Jo you didn't read Chris's statement closely. A conscientious mail server administrator will configure the SERVER to -ONLY- accept encrypted connections for SMTP-AUTH transactions; the server should enforce the encryption requirements. This is a religious war declaration or what? ok, let me see what I can say ;-p grin A conscien-something admin knows that as is always the case with encryption, security depends on the implementation (code, environment, random number generation, ...) and not on the specification. For example, a conscien-something admin knows about thing like this: http://www.henlich.de/moz-smtp/ A conscien-something knows that linking a large library like openssl in an otherwise quite safe MTA adds more opportunities for system compromise. A conscien-somthing admin prefers to be an open relay than a zombie. A conscien-somthing admin knows that it is possible to protect logins without TLS (if data protection is needed, PGP and S/MIME provide this end-to-end, something that no server $thing can provide). sure, not all clients support (secure) authentication methods. but same goes for STARTTLS (and don't tell me about the obsolete smtps, because conscien-seomthing admins don't implement obsolete things). A conscien-something admin knows that unless client certificates are used, starttls doesn't help against dictionary attacks performed from botnets (so you can't just block one IP). the same admin knows that deploying client certificates and/or assisting their users does not come from free, unless they work in a givernment organization financed by public taxes (but even then, a conscien-* admin won't spend people's money so frivoulously). A conscien-something admin knows that the private key is somewhere on the system, and that protecting it does not come for free. And of course, a conscien-something admin can setup an IPSec/ssh/* tunnel and not care about STARTTLS at all, ... and still feel consciencious. but maybe not. maybe he should still enforce STARTTLS? Come on... /grin TLS is nice, but... Thus it does not matter what the client wants to do, the server should not let the client continue the SMTP-AUTH transaction until it has completed the STARTTLS operation (or in the case of SMTPS, it's already encrypted). Back to Skip's question, possibly the easiest way to solve his problem would be to run two SMTP servers, one on port 25 with full spam/AV scanning for regular mail traffic, one on ports 587 645 with SMTP-AUTH/TLS for his users' clients to submit messages, on that one have AV scanning and possibly limited spam scanning. Fully agreed.
Re: Advice on MTA blacklist
Quoting Richard Smits [EMAIL PROTECTED]: Thanks for all the advice.. I think we will be using spamhaus. I am running a test and it blocks a lot of spam. Currently I use the sbl.spamhaus and pbl.spamhaus Is this wise, or should I also use the xbl and switch to zen.spamhaus? Please do not use the individual Spamhaus lists at the MTA level. Please use zen.spamhaus.org Cheers, Jeff C.
RE: Advice on MTA blacklist
Quoting Skip [EMAIL PROTECTED]: I am not certain how anyone can claim that they have no FPs running through those services unless they have prior knowledge of every inbound email. That is impossible. My company deals with on the order of thousands of companies and multiple times that in email addresses. There is no way to know how many of those systems were falsely (or correctly) placed on a blacklist at any point in time. I don't think any blacklist operator will claim that their blacklists have no false positives. The false positives vary by list. Some have more, some have fewer, and their characteristics may vary between lists. It's a responsibility of the mail administrator user of the blacklists to understand the differences and use the tools appropriately. Jeff C.
Re: Advice on MTA blacklist
Jeff Chan wrote: Quoting Richard Smits [EMAIL PROTECTED]: Thanks for all the advice.. I think we will be using spamhaus. I am running a test and it blocks a lot of spam. Currently I use the sbl.spamhaus and pbl.spamhaus Is this wise, or should I also use the xbl and switch to zen.spamhaus? Please do not use the individual Spamhaus lists at the MTA level. Please use zen.spamhaus.org Cheers, Jeff C. Hello, Why not ? We use : sbl-xbl.spamhaus.org now. It does not include the PBL (policy Block List) We serve a big university and we cannot afford False Positives. I can imagine that someone one the PBL (home user) runs a small mailserver and cannot connect to our server ? Or am I seeing trouble that is not there :-) I do not know the PBL as good... but I like the idea. Greetings... Richard
Re: Advice on MTA blacklist
Quoting R.Smits [EMAIL PROTECTED]: Jeff Chan wrote: Quoting Richard Smits [EMAIL PROTECTED]: Thanks for all the advice.. I think we will be using spamhaus. I am running a test and it blocks a lot of spam. Currently I use the sbl.spamhaus and pbl.spamhaus Is this wise, or should I also use the xbl and switch to zen.spamhaus? Please do not use the individual Spamhaus lists at the MTA level. Please use zen.spamhaus.org Why not ? We use : sbl-xbl.spamhaus.org now. It does not include the PBL (policy Block List) We serve a big university and we cannot afford False Positives. I can imagine that someone one the PBL (home user) runs a small mailserver and cannot connect to our server ? Or am I seeing trouble that is not there :-) I do not know the PBL as good... but I like the idea. The original poster was using SBL and PBL and was considering using XBL. In that case, it certainly makes more sense to use zen since it would mean one third as many DNS queries compared to querying each list individually. If you can't use PBL, then please continue using sbl-xbl as that cuts the queries in half. Cheers, Jeff C.
RE: Advice on MTA blacklist
Hello, Which spam blacklists do you use in your MTA config. (postfix) smptd_client_restrictions Currently we only use : reject_rbl_client list.dsbl.org We let spamassassin fight the rest of the spam. But the load of spam is getting to high for our organisation. Wich list is safe enough to block senders at MTA level ? Spamhaus, or spamcop ? I would like to hear some advice or maybe your current setup ? Thank you for any advice we can use . Greetings Richard I'm using reject_rbl_client zen.spamhaus.org, reject_rbl_client safe.dnsbl.sorbs.net, reject_rbl_client list.dsbl.org, and zen.spamhaus.org filtering about 98% of all rbl rejects. Regards, Leon Kolchinsky
Re: Advice on MTA blacklist
On Wed, 10 Oct 2007, R.Smits wrote: | We use : sbl-xbl.spamhaus.org now. It does not include the PBL (policy | Block List) | | We serve a big university and we cannot afford False Positives. | I can imagine that someone one the PBL (home user) runs a small | mailserver and cannot connect to our server ? Hi, Sorry you've confused me now! Unless I've got the posts mixed up, then yesterday in Message-ID: [EMAIL PROTECTED] you said you *were* using the PBL: Currently I use the sbl.spamhaus and pbl.spamhaus Is this wise, or should I also use the xbl and switch to zen.spamhaus? For what it's worth, we are a large University and we use ZEN with no problems whatsoever.
Re: Advice on MTA blacklist
R.Smits wrote: Jeff Chan wrote: Quoting Richard Smits [EMAIL PROTECTED]: Thanks for all the advice.. I think we will be using spamhaus. I am running a test and it blocks a lot of spam. Currently I use the sbl.spamhaus and pbl.spamhaus Is this wise, or should I also use the xbl and switch to zen.spamhaus? Please do not use the individual Spamhaus lists at the MTA level. Please use zen.spamhaus.org Cheers, Jeff C. Hello, Why not ? We use : sbl-xbl.spamhaus.org now. It does not include the PBL (policy Block List) We serve a big university and we cannot afford False Positives. I can imagine that someone one the PBL (home user) runs a small mailserver and cannot connect to our server ? do you consider it an FP if their ISP blocks port 25? If they really run a normal MTA, and if that is authorized by their ISP, then they should ask to be unlisted. (They should also get a meaningful reverse DNS so that they can be identified). Otherwise, they should relay via their ISP... Or am I seeing trouble that is not there :-) I do not know the PBL as good... but I like the idea. Greetings... Richard
Re: Advice on MTA blacklist
Leon Kolchinsky wrote: Hello, Which spam blacklists do you use in your MTA config. (postfix) smptd_client_restrictions Currently we only use : reject_rbl_client list.dsbl.org We let spamassassin fight the rest of the spam. But the load of spam is getting to high for our organisation. Wich list is safe enough to block senders at MTA level ? Spamhaus, or spamcop ? I would like to hear some advice or maybe your current setup ? Thank you for any advice we can use . Greetings Richard I'm using reject_rbl_client zen.spamhaus.org, reject_rbl_client safe.dnsbl.sorbs.net, reject_rbl_client list.dsbl.org, and zen.spamhaus.org filtering about 98% of all rbl rejects. You can't count like this. because what is rejected by zen is not checked against the other two. changing the order of the checks will give you different numbers. the only way to get real numbers is to put warn_if_reject reject_rbl_client $list1 warn_if_reject reject_rbl_client $list2 warn_if_reject reject_rbl_client $list3 before the actual rejects. This way you can count the reject_warning log lines. now this means more lookups (you will lookup all the DNSBLs, instead of stopping at first listing).
Re: Advice on MTA blacklist
Quoting mouss [EMAIL PROTECTED]: If they really run a normal MTA, and if that is authorized by their ISP, then they should ask to be unlisted. (They should also get a meaningful reverse DNS so that they can be identified). Otherwise, they should relay via their ISP... Indeed, one of the strong points of PBL is that it's relatively easy to get legitimate mailservers removed from the list. Agree with your other comments too. Jeff C.
Re: Advice on MTA blacklist
On Tue, 9 Oct 2007, Jo Rhett wrote:
On Oct 9, 2007, at 4:22 PM, Chris Edwards wrote:
Your server then enforces encryption and SMTP-AUTH, and the SSL will
(hopefully) defeat any man-in-the-middle attacks by trans-proxies.
That's exactly the problem I am reporting. A lot of mail clients
don't enforce SSL connections, so man in the middle is silently
accepted. Only T-bird can be configured to not work any other way,
TTBOMK.
Jo you didn't read Chris's statement closely. A conscientious mail server
administrator will configure the SERVER to -ONLY- accept encrypted
connections for SMTP-AUTH transactions; the server should enforce
the encryption requirements.
Thus it does not matter what the client wants to do, the server should
not let the client continue the SMTP-AUTH transaction until it has
completed the STARTTLS operation (or in the case of SMTPS, it's
already encrypted).
Back to Skip's question, possibly the easiest way to solve his
problem would be to run two SMTP servers, one on port 25 with full
spam/AV scanning for regular mail traffic, one on ports 587 645 with
SMTP-AUTH/TLS for his users' clients to submit messages, on that one
have AV scanning and possibly limited spam scanning.
--
Dave Funk University of Iowa
dbfunk (at) engineering.uiowa.eduCollege of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include std_disclaimer.h
Better is not better, 'standard' is better. B{
Re: [sa-list] Re: Advice on MTA blacklist
On Wed, 10 Oct 2007, David B Funk wrote: On Tue, 9 Oct 2007, Jo Rhett wrote: On Oct 9, 2007, at 4:22 PM, Chris Edwards wrote: Your server then enforces encryption and SMTP-AUTH, and the SSL will (hopefully) defeat any man-in-the-middle attacks by trans-proxies. That's exactly the problem I am reporting. A lot of mail clients don't enforce SSL connections, so man in the middle is silently accepted. Only T-bird can be configured to not work any other way, TTBOMK. Jo you didn't read Chris's statement closely. A conscientious mail server administrator will configure the SERVER to -ONLY- accept encrypted connections for SMTP-AUTH transactions; the server should enforce the encryption requirements. Thus it does not matter what the client wants to do, the server should not let the client continue the SMTP-AUTH transaction until it has completed the STARTTLS operation (or in the case of SMTPS, it's already encrypted). Back to Skip's question, possibly the easiest way to solve his problem would be to run two SMTP servers, one on port 25 with full spam/AV scanning for regular mail traffic, one on ports 587 645 with SMTP-AUTH/TLS for his users' clients to submit messages, on that one have AV scanning and possibly limited spam scanning. Assuming sendmail (and we don't make such assumptions), you can specify different options per-port, such that you don't need to run two mail servers. For example, I have no less than seven virtual daemons configured: Submission agents on 587 and 2525, which require auth, and have encryption optional. Also listens on 127.1. A submission agent on 465 (not 645), configured the same way, but with encryption explicit. Standard daemon on port 25 (and yes, it still supports the optional encryption). As a bonus, my own server any port will present a FQDN, signed certificate (not self-signed). I've actually found other servers out there in the wild that do the same, with a valid cert -- I've got my server configured with the CA root certs so it knows which are true (this doesn't affect ability to relay or anything, but it's cool to see others are doing it). Of course, all this is wildly off the topic, but hey... -Dan -- And, a special guest, from the future, miss Ria Pischell. Miss Pischell, as you all know, is the inventor of the Statiophonic Oxygenetic Amplifiagraphaphonadelaverberator, and it's pretty hard to imagine life without one of those. -Rufus, Bill Ted's Bogus Journey Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org ---
Re: Advice on MTA blacklist
On Tue, 2007-10-09 at 17:34 +0200, R.Smits wrote: Hello, Which spam blacklists do you use in your MTA config. (postfix) smptd_client_restrictions Currently we only use : reject_rbl_client list.dsbl.org We let spamassassin fight the rest of the spam. But the load of spam is getting to high for our organisation. Wich list is safe enough to block senders at MTA level ? Spamhaus, or spamcop ? I would like to hear some advice or maybe your current setup ? I would like to recommend this: (that includes rbl lists) http://jimsun.linxnet.com/misc/postfix-anti-UCE.txt -- Byung-Hee HWANG [EMAIL PROTECTED] As he drove Johnney home, Nino thought that if that was success, he didn't want it. -- the Nino Valenti's inside, Chapter 13, page 189
Re: Advice on MTA blacklist
R.Smits wrote: Hello, Which spam blacklists do you use in your MTA config. (postfix) smptd_client_restrictions Currently we only use : reject_rbl_client list.dsbl.org We let spamassassin fight the rest of the spam. But the load of spam is getting to high for our organisation. Wich list is safe enough to block senders at MTA level ? Spamhaus, or spamcop ? Spamhaus: yes. Use zen.spamhaus.org (you might end up needing to pay for it, and use a local cache, if you're a heavy traffic site, but, frankly, it's worth paying for). Spamcop: no. Don't use them as an MTA RBL. I'm leery of even using them as a SA RBL, but it's a very bad idea to use them as an MTA RBL (too many false positives).
RE: Advice on MTA blacklist
None. I'd rather bump up my system resources than allow a system completely out of my control to assess whether or not mail should run through my MTA and SA. - Skip
Re: Advice on MTA blacklist
On Tue, 9 Oct 2007 at 10:00 -0700, [EMAIL PROTECTED] confabulated: Spamhaus: yes. Use zen.spamhaus.org (you might end up needing to pay for it, and use a local cache, if you're a heavy traffic site, but, frankly, it's worth paying for). We use Spamhaus here with their datefeed service. Our two filter servers reject an average 3.2 million messages every 24 hours with using zen.spamhaus.org.
Re: Advice on MTA blacklist
Quoting John Rudd [EMAIL PROTECTED]: R.Smits wrote: Hello, Which spam blacklists do you use in your MTA config. (postfix) smptd_client_restrictions Currently we only use : reject_rbl_client list.dsbl.org We let spamassassin fight the rest of the spam. But the load of spam is getting to high for our organisation. Wich list is safe enough to block senders at MTA level ? Spamhaus, or spamcop ? Spamhaus: yes. Use zen.spamhaus.org (you might end up needing to pay for it, and use a local cache, if you're a heavy traffic site, but, frankly, it's worth paying for). Spamcop: no. Don't use them as an MTA RBL. I'm leery of even using them as a SA RBL, but it's a very bad idea to use them as an MTA RBL (too many false positives). I was about to give the same answer Jeff C.
Re: Advice on MTA blacklist
John Rudd wrote: Spamcop: no. Don't use them as an MTA RBL. I'm leery of even using them as a SA RBL, but it's a very bad idea to use them as an MTA RBL (too many false positives). Actually, sometime in the past several months, SpamCop's FP rate dropped dramatically. I'm not privy to the inside details, but they must have made some dramatic changes. Therefore, whatever bad FP reputation they've earned over the years should be erased and they should be reassessed. Rob McEwen
Re: Advice on MTA blacklist
Jeff Chan writes: Quoting John Rudd [EMAIL PROTECTED]: R.Smits wrote: Spamcop: no. Don't use them as an MTA RBL. I'm leery of even using them as a SA RBL, but it's a very bad idea to use them as an MTA RBL (too many false positives). I was about to give the same answer actually Spamcop is looking pretty good these days, after some backend changes they made a few months back: spam: 53.8562% 225813 of 419287 messages ham: 0.0894% 71 of 79398 messages http://ruleqa.spamassassin.org/20071006-r582471-n/RCVD_IN_BL_SPAMCOP_NET/detail --j.
Re: Advice on MTA blacklist
* R.Smits [EMAIL PROTECTED]: Hello, Which spam blacklists do you use in your MTA config. (postfix) smptd_client_restrictions None, we put them like all restrictions into smtpd_recipient_restrictions. Currently we only use : reject_rbl_client list.dsbl.org reject_rbl_client zen.spamhaus.org -- Ralf Hildebrandt (i.A. des IT-Zentrums) [EMAIL PROTECTED] Charite - Universitätsmedizin BerlinTel. +49 (0)30-450 570-155 Gemeinsame Einrichtung von FU- und HU-BerlinFax. +49 (0)30-450 570-962 IT-Zentrum Standort CBFsend no mail to [EMAIL PROTECTED]
Re: Advice on MTA blacklist
Also, psbl.surriel.com has gotten much better in recent months. It used to have occasional FPs, but I haven't seen any in a while. In my own spam filtering, I merely score on RBLs and I don't outright block... but if I were a large ISP which didn't have that luxury, I'd probably use the following five RBLs for outright blocking: • zen • dsbl • spamcop (now that it has improved) • psbl (now that it has improved) • ivmSIP.com (mine) (njabl **almost** made the cut... I'd take a close look second look at that one) All five of these are safe for outright blocking... if one doesn't mind having a tiny fraction of a percent of FPs ...combined, I'm guessing that these five lists probably produce **LESS** than 1/10 of 1% FPs... most of which would be due to misconfigured small office servers spewing spam or backscatter and stuff like that where some of the legit mail from the SAME IPs also gets blocked... but no egregious mistakes or large MTAs blocked by these. There is no other list out there that comes close to these five lists in terms of low FPs combined with relevancy... that being, does that one list still block a decent percentage of **additional** spam even if the other four lists were already in use prior to adding that fifth list. Lists that have zero FPs, but don't find any additional Spammer's IPs didn't make that list. Rob McEwen wrote: John Rudd wrote: Spamcop: no. Don't use them as an MTA RBL. I'm leery of even using them as a SA RBL, but it's a very bad idea to use them as an MTA RBL (too many false positives). Actually, sometime in the past several months, SpamCop's FP rate dropped dramatically. I'm not privy to the inside details, but they must have made some dramatic changes. Therefore, whatever bad FP reputation they've earned over the years should be erased and they should be reassessed. Rob McEwen
Re: Advice on MTA blacklist
On 10/9/07, R.Smits [EMAIL PROTECTED] wrote: Hello, Which spam blacklists do you use in your MTA config. (postfix) smptd_client_restrictions Currently we only use : reject_rbl_client list.dsbl.org We let spamassassin fight the rest of the spam. But the load of spam is getting to high for our organisation. Wich list is safe enough to block senders at MTA level ? Spamhaus, or spamcop ? I would like to hear some advice or maybe your current setup ? Thank you for any advice we can use . Greetings Richard I would use spamhaus for MTA reject and spamcop in SA. I've also been evaluating a very interesting new RBL for several weeks called the ivmSIP rbl. Its designed to work after RBLs like spamhaus to catch what they miss and it works quite well so far. It's catching about 30% of the mail that makes it past both spamhaus and spamcop (and of course some of that mail is actually not spam :). The web site for the new list isn't ready yet but you can ask for a trial feed by emailing Mr. Rob McEwen at [EMAIL PROTECTED]
Re: Advice on MTA blacklist
Hello, Which spam blacklists do you use in your MTA config. (postfix) smptd_client_restrictions Currently we only use : reject_rbl_client list.dsbl.org http://list.dsbl.org We let spamassassin fight the rest of the spam. But the load of spam is getting to high for our organisation. Wich list is safe enough to block senders at MTA level ? Spamhaus, or spamcop ? I would like to hear some advice or maybe your current setup ? Thank you for any advice we can use . Greetings Richard I would use spamhaus for MTA reject and spamcop in SA. I've also been evaluating a very interesting new RBL for several weeks called the ivmSIP rbl. Its designed to work after RBLs like spamhaus to catch what they miss and it works quite well so far. It's catching about 30% of the mail that makes it past both spamhaus and spamcop (and of course some of that mail is actually not spam :). The web site for the new list isn't ready yet but you can ask for a trial feed by emailing Mr. Rob McEwen at [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Thanks for all the advice.. I think we will be using spamhaus. I am running a test and it blocks a lot of spam. Currently I use the sbl.spamhaus and pbl.spamhaus Is this wise, or should I also use the xbl and switch to zen.spamhaus?
Re: Advice on MTA blacklist
On Tue, 9 Oct 2007, Richard Smits wrote: | Thanks for all the advice.. I think we will be using spamhaus. I am | running a test and it blocks a lot of spam. Currently I use the | sbl.spamhaus and pbl.spamhaus | Is this wise, or should I also use the xbl and switch to zen.spamhaus? You should definitely by using the xbl (or better zen). I suspect you'll find it hits more spam than just about anything else. Preferably use as outright reject at the MTA level.
RE: Advice on MTA blacklist
Well, in the real world, many of us who would have to scan over 150,000 inbound emails a day, of which about 85% are pure 100% spam simply don't have that luxury... We've had best results with zen.spamhaus.org , other dnsbls seem unreliable/not worth the effort regards, jp Admittedly, I process more on the order of 10,000 messages a day. But your second point here is the very reason I won't use them: unreliable. When I initially rolled out SA, I was using both spamcop and spamhaus along with a couple of others. I quickly eliminated down to those two. Then to one. Then removed them entirely after about 2 months of use. I have a number of travelling personnel from my company. I don't want the call at 11pm on a Wednesday night or 6 am on a Sunday morning from a hotel and the network they are on is on one of those lists and they can't use their email. I also have seen my ISP have a range of their network falsely flagged (and it encompassed our network range) for a period of 36-48 hours. That put a major dent in communication with our customers. I am not certain how anyone can claim that they have no FPs running through those services unless they have prior knowledge of every inbound email. That is impossible. My company deals with on the order of thousands of companies and multiple times that in email addresses. There is no way to know how many of those systems were falsely (or correctly) placed on a blacklist at any point in time. - Skip
RE: Advice on MTA blacklist
On Tue, 9 Oct 2007, Skip wrote: | I have a number of travelling personnel from my company. I don't want the | call at 11pm on a Wednesday night or 6 am on a Sunday morning from a hotel | and the network they are on is on one of those lists and they can't use | their email. Hi, Your travellers should be using one of: - Authenticated SMTP submission bypassing your DNSBL tests - VPN into your network - Your webmail service Thus it shouldn't matter if their hotel is blacklisted (many are).
RE: Advice on MTA blacklist
-Original Message- From: Skip [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 09, 2007 2:26 PM To: users@spamassassin.apache.org Subject: RE: Advice on MTA blacklist Well, in the real world, many of us who would have to scan over 150,000 inbound emails a day, of which about 85% are pure 100% spam simply don't have that luxury... We've had best results with zen.spamhaus.org , other dnsbls seem unreliable/not worth the effort regards, jp Admittedly, I process more on the order of 10,000 messages a day. But your second point here is the very reason I won't use them: unreliable. When I initially rolled out SA, I was using both spamcop and spamhaus along with a couple of others. I quickly eliminated down to those two. Then to one. Then removed them entirely after about 2 months of use. I have a number of travelling personnel from my company. I don't want the call at 11pm on a Wednesday night or 6 am on a Sunday morning from a hotel and the network they are on is on one of those lists and they can't use their email. I also have seen my ISP have a range of their network falsely flagged (and it encompassed our network range) for a period of 36-48 hours. That put a major dent in communication with our customers. I am not certain how anyone can claim that they have no FPs running through those services unless they have prior knowledge of every inbound email. That is impossible. My company deals with on the order of thousands of companies and multiple times that in email addresses. There is no way to know how many of those systems were falsely (or correctly) placed on a blacklist at any point in time. - Skip Good points... I'm certainly not claiming we have no fp's from spamhaus, but since no one has complained in over a year, why would I stop now and bring the server to it's knees? Sure, I'd love to accept and scan them all but we simply don't have the resources...
RE: Advice on MTA blacklist
From: Chris Edwards Your travellers should be using one of: - Authenticated SMTP submission bypassing your DNSBL tests - VPN into your network - Your webmail service All of these are available. Unless I somehow had something configured improperly, the blacklists were rejecting connection to the MTA before SMTP auth. The second two are in place because of this very issue. Users prefer not to use webmail because it is inefficient. A mail client (i.e. Outlook, Thunderbird, etc.) has their address books and keeps better records of sent mail. While this has solved my issues with my travelling users, it does not eliminate the FP issues. And I am not willing to take that risk. If there is a communication breakdown due to a 3rd party falsely flagging a network, that is not going to reflect on the 3rd party. It will reflect on us and results in the potential for lost business. - Skip
Re: Advice on MTA blacklist
Skip, Chris's point is that your users **should** use SMTP authorization to distinguish their trusted connections from other connections that must be spam filtered. Additionally, you should NOT do ANY spam filtering on these SMTP Auth connections... especially not outright RBL blocking. You state that the blacklists were rejecting connections to the MTA before SMTP... but this **is** a misconfiguration on your part. You shouldn't allow rejecting of connections before you get a chance to determine whether the connection was SMTP AUTH or not. In a sense, you are asking for something that is unreasonable... you want RBLs to block spam that is spewing out of zombie-infected computers... but, somehow, the DNSBL is suppose to know when YOUR users are attempting to send direct to your server from that same zombie computer... where the RBL isn't bypassed for SMTP AUTH connections. This is a fundamental flaw in your architecture. Until you fix this, you'll get FPs with almost all of the best RBLs that other mail providers use on large networks every day with virtually zero FPs. The problem is your configuration, not with the RBLs. Rob McEwen Skip wrote: From: Chris Edwards Your travellers should be using one of: - Authenticated SMTP submission bypassing your DNSBL tests - VPN into your network - Your webmail service All of these are available. Unless I somehow had something configured improperly, the blacklists were rejecting connection to the MTA before SMTP auth. The second two are in place because of this very issue. Users prefer not to use webmail because it is inefficient. A mail client (i.e. Outlook, Thunderbird, etc.) has their address books and keeps better records of sent mail. While this has solved my issues with my travelling users, it does not eliminate the FP issues. And I am not willing to take that risk. If there is a communication breakdown due to a 3rd party falsely flagging a network, that is not going to reflect on the 3rd party. It will reflect on us and results in the potential for lost business. - Skip
RE: Advice on MTA blacklist
On Tue, 9 Oct 2007, Skip wrote: | Unless I somehow had something configured improperly, the blacklists | were rejecting connection to the MTA before SMTP auth. Hi, That's the problem - you don't want to do blacklist lookups for SMTP-AUTH submissions. FWIW we use Exim which has plenty flexibility to achieve this. I don't know the details for other MTAs. Alternatively, an MTA-independent solution is to separate your MX boxes from your submission boxes - the latter do no spam-filtering, but mandate SMTP-AUTH (and/or user-on-local-network IP). Ah - just seen Rob's said this better ;-)
Re: Advice on MTA blacklist
On Oct 9, 2007, at 10:37 AM, James E. Pratt wrote: Well, in the real world, many of us who would have to scan over 150,000 inbound emails a day, of which about 85% are pure 100% spam simply don't have that luxury... Are you using a 486 to process inbound mail? My 1.4Ghz Athlon 2 system with Amavis/SA processes that much mail PER HOUR without breaking a sweat. No MTA-level RBLs. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: Advice on MTA blacklist
On Oct 9, 2007, at 11:31 AM, Chris Edwards wrote: Your travellers should be using one of: - Authenticated SMTP submission bypassing your DNSBL tests - VPN into your network - Your webmail service Thus it shouldn't matter if their hotel is blacklisted (many are). Both Crackberry and Verizon force you to use their mail servers. Some other data providers are now doing transparent proxy on outbound e-mail. In short, the user can't always control that. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: Advice on MTA blacklist
On Tue, 9 Oct 2007, Jo Rhett wrote: | Both Crackberry and Verizon force you to use their mail servers. Some other | data providers are now doing transparent proxy on outbound e-mail. In short, | the user can't always control that. True, to an extent. I don't know about the *berry, but imagine/hope that verizon allow encrypted SMTP-AUTH out on the appropriate alternate port (465/587). Do they ? However, even assuming your user *is* using the *berry server or the verizon transparent proxy, then mails they send will in the main emerge from a legit mail server run by grown-ups, which is far far less likely to be blacklisted then a user sending direct from a hotel connection or mobile dynamic IP etc etc.
Re: Advice on MTA blacklist
On Tue, 9 Oct 2007, Jo Rhett wrote: | Right, but transparent proxy of SMTP connections is available in even the | lowest end firewalls now (like free ones you get with service). OK. | And very few clients will complain if they aren't required to do SMTP | auth, which means that the user will never know that their session was | intercepted. Yes again. Of course the best solution is for clients to always submit on port 465/587, and hope that's allowed out by the hotels / mobile connectivity providers. ( as per the relevant recommendations ) Your server then enforces encryption and SMTP-AUTH, and the SSL will (hopefully) defeat any man-in-the-middle attacks by trans-proxies.
Re: Advice on MTA blacklist
On Oct 9, 2007, at 3:52 PM, Chris Edwards wrote: However, even assuming your user *is* using the *berry server or the verizon transparent proxy, then mails they send will in the main emerge from a legit mail server run by grown-ups, which is far far less likely to be blacklisted then a user sending direct from a hotel connection or mobile dynamic IP etc etc. Right, but transparent proxy of SMTP connections is available in even the lowest end firewalls now (like free ones you get with service). And very few clients will complain if they aren't required to do SMTP auth, which means that the user will never know that their session was intercepted. Yes, this means man-in-the-middle is trivial. No kidding. Beat up the mail client creators. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: Advice on MTA blacklist
On Oct 9, 2007, at 4:22 PM, Chris Edwards wrote: Of course the best solution is for clients to always submit on port 465/587, and hope that's allowed out by the hotels / mobile connectivity providers. Fairly often not. I've been lucky with T-Mobile, but Sprint and Verizon apparently block it randomly. East coast t-mobile users have had problems with blocking. Your server then enforces encryption and SMTP-AUTH, and the SSL will (hopefully) defeat any man-in-the-middle attacks by trans-proxies. That's exactly the problem I am reporting. A lot of mail clients don't enforce SSL connections, so man in the middle is silently accepted. Only T-bird can be configured to not work any other way, TTBOMK. And this is irrelevant for proprietary systems like Crackberry which use only their own servers, and Verizon which has modified software to use their own servers, etc etc. As more and more people do more and more of their e-mail from hand- held devices, this problem only gets worse. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: Advice on MTA blacklist
Chris Edwards wrote: On Tue, 9 Oct 2007, Jo Rhett wrote: | Both Crackberry and Verizon force you to use their mail servers. Some other | data providers are now doing transparent proxy on outbound e-mail. In short, | the user can't always control that. True, to an extent. I don't know about the *berry, but imagine/hope that verizon allow encrypted SMTP-AUTH out on the appropriate alternate port (465/587). Do they ? mobiles are special (and *berry servers can be whitelisted if you need that). but in the desktop domain, blocking 587 is plain silly. and even if done, nothing prevents you from using an other port, say 10587. an no, there is no universal proxy (people find it hard to proxy known multi-channel protocols. how about proprietary ones ;-p). However, even assuming your user *is* using the *berry server or the verizon transparent proxy, then mails they send will in the main emerge from a legit mail server run by grown-ups, which is far far less likely to be blacklisted then a user sending direct from a hotel connection or mobile dynamic IP etc etc. agreed. I would also add that putting mail in a quarantine (be that a Junk folder) doesn't help much if the said quarantine is so full of junk that the recipient doesn't check it. and in this case, it is worst because mail just disappeared (with an smtp reject, the sender has a chance to notice, and maybe do something). So rejecting some spam at SMTP time helps keeping the quarantine/Junk_folder usable.
