Re: SA on outgoing SMTP servers
On 09.09.11 17:20, Matus UHLAR - fantomas wrote: due to many spam problems (outbreaks) in history, we check for spamminess on outgoing mail servers. However there are rules that should not apply on them. - Dynamic/blacklist (except URIBL) checks I can avoid these by defining local server to msa_networks - ALL_TRUSTED I'm sure I have to turn this off, does it also apply to dependencies? What about !ALL_TRUSTED dependencies? - SPF checks While we should reject/quarantine e-mail that does not match SPF, it should not apply to domains we are designed to send mail for . (SPF records include us) ... any other ideas? Further watching and thinking advises me to: - skip all RBL checks that check on IP address, which means all except rfci and ahbl - zero (or, make nearly zero) RDNS_NONE and TVD_RCVD_SINGLE - MAYBE define all hosts as trusted/internal - MAYBE use first scoreset, as if we didn't do network checks, even if we do RAZOR, PYZOR, DCC, URIBL's, rfci etc... (would be worth checking) -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I just got lost in thought. It was unfamiliar territory.
Re: SA on outgoing SMTP servers
due to many spam problems (outbreaks) in history, we check for spamminess on outgoing mail servers. However there are rules that should not apply on them. - Dynamic/blacklist (except URIBL) checks I can avoid these by defining local server to msa_networks - ALL_TRUSTED I'm sure I have to turn this off, does it also apply to dependencies? What about !ALL_TRUSTED dependencies? - skip all RBL checks that check on IP address, which means all except rfci and ahbl - zero (or, make nearly zero) RDNS_NONE and TVD_RCVD_SINGLE I have implemented these until now: score ALL_TRUSTED 0 meta__DOS_DIRECT_TO_MX (0) score RDNS_NONE 0 score TVD_RCVD_SINGLE 0 -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. 99 percent of lawyers give the rest a bad name.
Re: SA on outgoing SMTP servers
Am 09.09.2011 17:20, schrieb Matus UHLAR - fantomas: due to many spam problems (outbreaks) in history, we check for spamminess on outgoing mail servers. However there are rules that should not apply on them. - Dynamic/blacklist (except URIBL) checks I can avoid these by defining local server to msa_networks - ALL_TRUSTED I'm sure I have to turn this off, does it also apply to dependencies? What about !ALL_TRUSTED dependencies? - SPF checks While we should reject/quarantine e-mail that does not match SPF, it should not apply to domains we are designed to send mail for . (SPF records include us) ... any other ideas? On 09.09.11 20:17, Robert Schetterer wrote: try using clamav-milter with sanesecurity antispam signatures this should avoid a lot of outgoing spam Maybe, but this is not what I have asked for, and it won't help me a bit resolving my problem, sorry. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Chernobyl was an Windows 95 beta test site.
SA on outgoing SMTP servers
Hello, due to many spam problems (outbreaks) in history, we check for spamminess on outgoing mail servers. However there are rules that should not apply on them. - Dynamic/blacklist (except URIBL) checks I can avoid these by defining local server to msa_networks - ALL_TRUSTED I'm sure I have to turn this off, does it also apply to dependencies? What about !ALL_TRUSTED dependencies? - SPF checks While we should reject/quarantine e-mail that does not match SPF, it should not apply to domains we are designed to send mail for . (SPF records include us) ... any other ideas? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Microsoft dick is soft to do no harm
Re: SA on outgoing SMTP servers
Am 09.09.2011 17:20, schrieb Matus UHLAR - fantomas: Hello, due to many spam problems (outbreaks) in history, we check for spamminess on outgoing mail servers. However there are rules that should not apply on them. - Dynamic/blacklist (except URIBL) checks I can avoid these by defining local server to msa_networks - ALL_TRUSTED I'm sure I have to turn this off, does it also apply to dependencies? What about !ALL_TRUSTED dependencies? - SPF checks While we should reject/quarantine e-mail that does not match SPF, it should not apply to domains we are designed to send mail for . (SPF records include us) ... any other ideas? try using clamav-milter with sanesecurity antispam signatures this should avoid a lot of outgoing spam -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: SA on outgoing SMTP
Hi, On Tue, Feb 16, 2010 at 04:44:05PM -1000, Alexandre Chapellon wrote: Le mercredi 17 fe'vrier 2010 a` 01:38 +0100, Karsten Bra:ckelmann a e'crit : ... The one using SMTP-AUTH to relay spam through my servers are most of the time IP address outside of my network... I imagine they have credentials sent by trojan or stuff like this. brute-force password-scan is cheap and easy with most MTAs :-( Change mail-password of abused accounts immediately and in any case of abuse. Make it difficult to pwd-scan your server (limit failed passwd attempts per time). But I also have others that are machines inside my network using AUTH. If you want to take a look at it, I can forward one complaint. Is this correct? You have authenticated users inside and outside of your network sending spam. In other words: you know the user - or at least the users account sending spam. So you have any possibility to close or limit the account, inform the user etc. Having this, how could spamassassin help you? o Knowing about the abuse maybe 2 hours before you get complaints? yes. o Tagging outgoing messages as spam? That's ridiculous. o Blocking mails with high spam-scores and routing the others? - Since SA will never fetch any single spam (I guess some 10% false negative when feeded directly from a spam-bot (new pattern, no hashes yet, no IP blacklists possible) and without causing excessive FPs) you'll still send out enough spam to get complaints or to get blacklisted. - It does not help your customers with their obsessed PCs Yes, most Customers like to be informed about an infection. - It does not help the rest of us since the Bot in the obsessed PC may send direct to our MTAs tomorrow. Summarized: If you setup SA outgoing for blocking spam without stopping your users to produce/relay spam and without stopping your smtp-auth accounts getting abused - you'll still have complaints from your customers about blocked mails - now additional from your own servers false positives - your mailhost still will be blacklisted - your Network still will be blacklisted - all others still will get spam from your net (even if less directly sent from your server) - your customers still have obsessed PCs with all dangers of losing private data, having the pc abused for filesharing, DoS, hacking, beeing sued about this... But it may save your ass for 2 month if your boss is after you. That's no affordable scenario in my eyes, sorry. -- Greets Frank
Re: SA on outgoing SMTP
Alexandre Chapellon wrote: I am an ISP with over 5 users (wich is not that big for an isp) permannently connected. I can hardly imagine to manage the poilicies of all my customer, and I know they would really don't like it. What if your ISP told you what you got to do, where to go and to forget about your buggy OS your using for years? On 16.02.10 13:57, Ted Mittelstaedt wrote: If your unwilling to block your dynamics from outbound SMTP then it is perfectly legitimate for the rest of the Internet to block you from sending them mail. This is equivalent to somebody being told that a home they own is being used by drug dealers to cook methamphetamines, and the homeowner saying I can hardly imagine to manage the policies of all my renters, and I know they would really don't like it, then the community getting together and firebombing the home one night. But even in such case you must be prepared that you - will get reports about spam sent from their IP addresses - will get blocked in blacklists like UCEPROTECT-L2 or UCEPROTECT-L3 that block whole network if there's much spaming IPs in it. - will have YOUR mail blocked because of the above. (I'm not saying this is a good practice, but it will happen). Blocking outgoing SMTP for any customers without mailserver is the easiest and currently most effective way to stop this problem. Note that I even do not like blocking customers from doing any kind of stuff, but in the world where 90% machines have windows installed and 50% of them is unmaintained, unprotected etc (does anyone know correct numbers) there's nearly no other way to go. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. A day without sunshine is like, night.
Re: SA on outgoing SMTP
Alexandre Chapellon wrote: Not public blacklists but for example Yahoo!'s servers spends most of its days replying defered temporarily due user complaints' o our relays. Start building a good reputation at Yahoo for your clean outgoing mail: - allocate a new IP address for your new 'clean' outgoing MTA, preferably outside your IP networks which are currently sending out mail; - set up a new clean outgoing MTA using this IP address. This can be a new independent mailer, or just use the 2.7 Postfix reputation management mechanisms for outgoing IP selection with your existing mailer, along with added spam and virus filtering, and with DKIM signing (leaving your existing mail system and client requirements untouched for now); - redirect submitted mail from authenticated clients (some or all, or as an opt-in service) through this new clean outgoing mail path. They will benefit with a much better acceptance rate at Yahoo. - check mail archives on the postfix user list (or ask) for some advice on best approaches to feed mail to yahoo and other large MSP providers; a dedicated Postfix smtp (client) service for each of the large players may be in order, with some restraint on the number of parallel outgoing sessions. A carrot and a stick method - carrot first :) The above only applies to clients using in their From header filed one of your (ISP's or their own) domain names. Those using foreign domains like gmail or yahoo should be submitting through their mail submission service anyway, for best mail acceptance. You can still allow them to send through your 'clean' or regular mailers, except they won't be able to obtain a signature from their 'home' domain. Mark
Re: SA on outgoing SMTP
On Tue, 2010-02-16 at 17:11 -1000, Alexandre Chapellon wrote: Yes but most of the time (here) undeliverable mails are undeliverable because of recipient over quota, wrong mx records on dst domain or things like this... I can explain this to my customer. By cons I cannot tell him we silently droped your mail this morning cause it looked like spam... at least I don't feel confortable with this. So redirect it back to him as an attachment to a spam report. I'd do that by having Postfix initially redirect to a local spam handling mailbox. The program reading that mailbox, probably based round JavaMail because that makes mail handling very easy, would first check whether the sender is one of your legitimate users. If not, the sender is forged and the mail can be discarded. If the sender is legit, the program creates a covering form letter, attaches the spammy message and sends it to the user. Such a program would check its mail every 5 - 10 minutes. Martin
Re: SA on outgoing SMTP
Alexandre, To answer your first question, yes we filter outbound mail. We were once in the same position as you are now and corrected the problem successfully. All the advice given is good and I can attest that it will work. We first created a separate outbound service with authenticated smtps added and then worked hard to convert all clients to the new service. We went so far as to make it mandatory that all new clients were only allowed to send mail if authenticated. Our support staff would change a users MUA to authenticated connection if the client called support for *any* reason. We filter all messages at connection time and refuse the message if it scores above the set SpamAssassin limit or contains a virus. The user knows immediately their mail will not go out. When the client calls support, the first thing support does is of course, change their MUA to authenticated smtps. We rate limit all outbound mail, exceed the messages per minute and we block your connection until a sysadmin looks at the problem. We limited recipients per message, first at 100, then we moved to 75, now we are 50. Want more recipients? Purchase a mail list with verp from us. A few complaints, a few clients changed to another provider, but the problem stopped. We have feedback loops setup and we read the messages everyday. We have all our hosted domains postmaster mail sent to us, and we read it everyday. We spot a problem and we have the client on the phone within minutes. We have had to block a few clients until they cleaned up their network/PC, but not very often anymore. We now have *all* (100% except Nagios alerts) mail traffic flowing through our filtered outbound servers. Clients, office, printers, scan2mail, fax2mail, even the web servers use our outbound servers as smart hosts. Messages go through our outbound servers, or they do not leave our network. We are not perfect, we still see some feedback (mostly bad addresses and clueless recipients) but we are far better than we were four years ago. Listen to what the experts are telling you and implement their suggestions. You may loose a client or two, but you will improve your network and get better clients in return for your efforts. DAve -- Posterity, you will know how much it cost the present generation to preserve your freedom. I hope you will make good use of it. If you do not, I shall repent in heaven that ever I took half the pains to preserve it. John Adams http://appleseedinfo.org
Re: SA on outgoing SMTP
Mark Martinec wrote: SA already has some awareness of mail flow direction (inbound vs. outbound) through its trusted_networks/internal_networks/msa_networks settings, and recognizes authentication signs in Received header fields, as well as its whitelist_bounce_relays awareness, so it should be able to deal with things like DUL blacklists correctly. Since you already have split mail paths, i.e. a dedicated MTA for outgoing mail, that's even easier, you can just turn off some dynamic blacklist lookups and adjust some other rules for mail submitted from internal networks or from authenticated roaming users. FWIW, with properly-configured trusted_networks etc, I haven't seen anything more than noise-level problems (one or two oddities every few months; ~100K messages/day outbound). Some of that may be a higher spam threshold for AUTH'ed mail (8 vs 5) too. -kgd
Re: SA on outgoing SMTP
Charles Gregory wrote: ... but any legitimate mail that is blocked will result in their MUA (Outlook) displaying an error message. This is GOOD. :) My experience has been that Outlook in particular (not Outlook Express or its descendant Windows (Live) Mail) does NOT in fact display SMTP error messages exactly as the server spits them out. :( A few other MUAs also commit this stupidity. (I agree with your main point about rejecting while the connection is open instead of generating DSNs for spammy mail though.) -kgd
Re: SA on outgoing SMTP
Hi Alexandre, On Tue, Feb 16, 2010 at 11:44:35AM -1000, Alexandre Chapellon wrote: I am an ISP with over 5 users (wich is not that big for an isp) permannently connected. FYI: similar scale here. I can hardly imagine to manage the poilicies of all my customer, and I know they would really don't like it. On the other hand they will strongly dislike you if your net is blacklisted and they are not longer able to send any regular mail. I think you'll lose more customers with mail-delays and blacklist caused bounces than with limiting smtp outgoing. And: If you enforce spamassassin-filters in your outgoing smtp-traffic, this would be a new policy too! What if your ISP told you what you got to do, where to go and to forget about your buggy OS your using for years? Even if you missed to tell your customers some rules - it's common practice to have contracts that allow filtering or disconnecting customers who abuse your infrastructure. And even if you missed to put this in your contracts: Not being a monopolist you should be able to cancel any contract or limit the services if the customer threatens your net and your business. Customers are often not aware that they endangers other customers and the ISPs infrastructure. Tell them. Tell them about the expenses they cause and about possible demand of recourses. This works. Been there, done that. Work on the proposal of Tom. You will not be able to switch this in one day, that's fully obvious. But you could on the one hand give new customers policies about using smtp-auth and message submission only, on the other hand filter outgoing port 25 of any user you get complaints about. Allow these only connecting your relayserver using message-submission with smtp-auth. If you assign dynamic IPs, put all misbehaving customers in a sperate IP-pool. Filter IPs in this pool. If a customer wants to use an outside SMTP-Server, allow this server (or any smtp-out) but tell the customer you'll bill him for any of your expenses caused by spam sent from his account - and of course tell him you'll filter again any time his account is abused again. Spam sent from customers over your mailrelay is very uncommon since bot-nets usually (so far) send without using a relay to get a better throughput. If spam is sent intensionally and repeatedly this is a good reason to cancel the contract. But mostly I agree, a clean network should be the basis. Le mardi 16 fe'vrier 2010 a` 12:40 -0800, Ted Mittelstaedt a e'crit : do not send fullquotes. Tnx. -- Regards Frank
Re: SA on outgoing SMTP
On Wed, 17 Feb 2010, Kris Deugau wrote: My experience has been that Outlook in particular (not Outlook Express or its descendant Windows (Live) Mail) does NOT in fact display SMTP error messages exactly as the server spits them out. :( Sorry. You've heard that old phrase goes without saying? Well, I didn't say it. (smile) Where Microsoft and error messages are concerned, I consider it par for the course that what is reported to the user will be a miserable distortion of whatever actual error occurred. But just the same, the user will know that *something* has gone wrong with their mail. Obviously the fewer FP's the better when dealing with confusing error messages :) - C
SA on outgoing SMTP
Hello the list, I have a quite buggy customer network, full of zombie PCs that spends all days sending spam and wasting the whole reputation of my networks. As a result it sometimes become quite hard to delivers queues for specific domains such as Yahoo!'s hosted ones. Indeed they have some temp fail (blacklist) mechanism that forbid my servers to send messages to them during hours. Taht's why I would like to setup some ougoing filtering to avoid sending too much spam through my mail relays. I think SA can help me in doing so, but I know too it's not really intented to work this way. I guess SA expects to work on MX hosts more than on smtp relays. My prerequisites are mainly: - STOP as much spam as possible at SMTP time (before queuing) - Have NO (or very few) false positives cause I could not manage telling thousands of users that they should *always_have_a_subject*, *shouldn't_write_the_subject_in_CAPS* or anything else. Further more I can't rely on RBL because a lot of my dyn IP address are regularily listed on different blacklist. Does anyone have already setup something like that and what specific config/tools/plugin could be usefull for me. If some one already done it does he/she have any statistics about the efficiency of this setup. Best regards.
Re: SA on outgoing SMTP
Slightly OT. To get 'control' of what my MX does at SMTP time I installed a simple SMTP daemon called 'Mail Avenger', which acts as a front end to my spamassassin and postfix. It's scripting capabilties allow for such interesting things as tracking the volume of mail sent by any one IP over a given time period. Stuff like that. Primarily designed for use as an MX, but no reason it couldn't help monitor/limit outgoing mail http://www.mailavenger.org - C On Tue, 16 Feb 2010, Alexandre Chapellon wrote: I have a quite buggy customer network, full of zombie PCs that spends all days sending spam and wasting the whole reputation of my networks. As a result it sometimes become quite hard to delivers queues for specific domains such as Yahoo!'s hosted ones. Indeed they have some temp fail (blacklist) mechanism that forbid my servers to send messages to them during hours. Taht's why I would like to setup some ougoing filtering to avoid sending too much spam through my mail relays. I think SA can help me in doing so, but I know too it's not really intented to work this way. I guess SA expects to work on MX hosts more than on smtp relays. My prerequisites are mainly: - STOP as much spam as possible at SMTP time (before queuing) - Have NO (or very few) false positives cause I could not manage telling thousands of users that they should *always_have_a_subject*, *shouldn't_write_the_subject_in_CAPS* or anything else. Further more I can't rely on RBL because a lot of my dyn IP address are regularily listed on different blacklist. Does anyone have already setup something like that and what specific config/tools/plugin could be usefull for me. If some one already done it does he/she have any statistics about the efficiency of this setup. Best regards.
Re: SA on outgoing SMTP
On Tue, 2010-02-16 at 08:44 -1000, Alexandre Chapellon wrote: Hello the list, I have a quite buggy customer network, full of zombie PCs that spends all days sending spam and wasting the whole reputation of my networks. 1) Are you already using separate inbound and outbound mail servers? 2) If not, does your mail server have any way of distinguishing the inbound and outbound streams (i.e., are your users sending on the standard SMTP port or on another one)? 3) Do you require all outbound mail to go through your servers and have you blocked users from sending outbound mail directly? 4) When you catch outgoing spam what do you want to do about it? Obvious choices for (4), in order of hitting the infected user with a successively bigger clue stick, are: - silently discard the spam, but you'll also throw away false positives. - silently discard the spam and tell him you've done so on a daily basis - tell your user he's infected and send all the spam back to him - tell your user he's infected, bin the spam and cut him off until his PC is clean. If you haven't decided what to do with the outbound spam yet, it would be a good idea to work that out before doing anything. If (1) or (2) are true, you can run a separate copy of SA for outbound mail, use a different rule set from the one you use on inbound mail, and/or disable RBL checks on it. Since you know where the mail is coming from, there's little point in wasting cycles with RBL checks unless you want to use them to spot forged sender addresses. The answers to these questions should help you figure out what you want to do about users with infected machines and help you decide what to do with the spam they're sending. It will also give us some idea of what to suggest. Martin
Re: SA on outgoing SMTP
I know your not going to want to hear this because your looking for a quick fix, but nothing substitutes for good network design. Your buggy customer network should enforce the following: Direct SMTP transmission (port 25) is filtered so that only machines designated as mailservers are allowed to send outbound mail to port 25, everyone else must use the submission port 587 with SMTP authentication to send mail to one of your mailservers, which then relays this to the rest of the world. I know you don't have this now. But, you should be enforcing it on new customers and you should adjust all of your self-help documentation so that as customers discard PC's and set new ones up, that they start using auth-SMTP on the submission port. It will take a few years. And for some time you will wonder why your bothering since it will seem like your only doing all of the extra work of maintaining auth-smtp for a minority of customer. But the day will come that you will realize the majority of your customers are using smtp-auth. And every day after that the number of clients sending mail directly to port 25 will continue to dwindle and you will become more and more interested in just chopping the minority off and letting them scream. Ted Alexandre Chapellon wrote: Hello the list, I have a quite buggy customer network, full of zombie PCs that spends all days sending spam and wasting the whole reputation of my networks. As a result it sometimes become quite hard to delivers queues for specific domains such as Yahoo!'s hosted ones. Indeed they have some temp fail (blacklist) mechanism that forbid my servers to send messages to them during hours. Taht's why I would like to setup some ougoing filtering to avoid sending too much spam through my mail relays. I think SA can help me in doing so, but I know too it's not really intented to work this way. I guess SA expects to work on MX hosts more than on smtp relays. My prerequisites are mainly: - STOP as much spam as possible at SMTP time (before queuing) - Have NO (or very few) false positives cause I could not manage telling thousands of users that they should *always_have_a_subject*, *shouldn't_write_the_subject_in_CAPS* or anything else. Further more I can't rely on RBL because a lot of my dyn IP address are regularily listed on different blacklist. Does anyone have already setup something like that and what specific config/tools/plugin could be usefull for me. If some one already done it does he/she have any statistics about the efficiency of this setup. Best regards.
Re: SA on outgoing SMTP
Hi Alexandre, At 10:44 16-02-10, Alexandre Chapellon wrote: I have a quite buggy customer network, full of zombie PCs that spends all days sending spam and wasting the whole reputation of my networks. Do they send these messages through your mail server? As a result it sometimes become quite hard to delivers queues for specific domains such as Yahoo!'s hosted ones. Indeed they have some temp fail (blacklist) mechanism that forbid my servers to send messages to them during hours. Taht's why I would like to setup some ougoing filtering to avoid sending too much spam through my mail relays. I think SA can help me in doing so, but I know too it's not really intented to work this way. I guess SA expects to work on MX hosts more than on smtp relays. You can still run some SpamAssassin tests to catch some of the spam. My prerequisites are mainly: - STOP as much spam as possible at SMTP time (before queuing) As this is outgoing, post-SMTP filtering is not much of an issue. Further more I can't rely on RBL because a lot of my dyn IP address are regularily listed on different blacklist. Relying on other people to tell you that there is a problem on your network is not a good idea. Sign up for feedback loops. Rate limit mail submissions or set up triggers to identify abnormalities. You may also wish to do traffic flow analysis to see what's going through your network. Regards, -sm
Re: SA on outgoing SMTP
Le mardi 16 février 2010 à 20:29 +, Martin Gregorie a écrit : On Tue, 2010-02-16 at 08:44 -1000, Alexandre Chapellon wrote: Hello the list, I have a quite buggy customer network, full of zombie PCs that spends all days sending spam and wasting the whole reputation of my networks. 1) Are you already using separate inbound and outbound mail servers? yes of course 2) If not, does your mail server have any way of distinguishing the inbound and outbound streams (i.e., are your users sending on the standard SMTP port or on another one)? 3) Do you require all outbound mail to go through your servers and have you blocked users from sending outbound mail directly? I can't block users from sendin directly I am an ISP my users are free to use another relay than mine... eg google or yahoo or some mails relay of their own hosted i don't know where. 4) When you catch outgoing spam what do you want to do about it? DROP! Obvious choices for (4), in order of hitting the infected user with a successively bigger clue stick, are: - silently discard the spam, but you'll also throw away false positives. Using before queuing filtering (on postfix) I reject the mail at SMTP time so the client gets an error (550 i guess) an so is aware (as far as a user can be aware of anything) his mail has been refused. - silently discard the spam and tell him you've done so on a daily basis I don't want to do something like this. - tell your user he's infected and send all the spam back to him - tell your user he's infected, bin the spam and cut him off until his PC is clean. I will, based on feedback loop mail processing. But that's another stuff. If you haven't decided what to do with the outbound spam yet, it would be a good idea to work that out before doing anything. If (1) or (2) are true, you can run a separate copy of SA for outbound mail, use a different rule set from the one you use on inbound mail, and/or disable RBL checks on it. Since you know where the mail is coming from, there's little point in wasting cycles with RBL checks unless you want to use them to spot forged sender addresses. The answers to these questions should help you figure out what you want to do about users with infected machines and help you decide what to do with the spam they're sending. It will also give us some idea of what to suggest. Indeed thoose questions (I already asked myself) are the first to setting up something efficient and too borring for users. It's good to see people who try to have a global view of the problem. Martin
Re: SA on outgoing SMTP
I am an ISP with over 5 users (wich is not that big for an isp) permannently connected. I can hardly imagine to manage the poilicies of all my customer, and I know they would really don't like it. What if your ISP told you what you got to do, where to go and to forget about your buggy OS your using for years? But mostly I agree, a clean network should be the basis. Le mardi 16 février 2010 à 12:40 -0800, Ted Mittelstaedt a écrit : I know your not going to want to hear this because your looking for a quick fix, but nothing substitutes for good network design. Your buggy customer network should enforce the following: Direct SMTP transmission (port 25) is filtered so that only machines designated as mailservers are allowed to send outbound mail to port 25, everyone else must use the submission port 587 with SMTP authentication to send mail to one of your mailservers, which then relays this to the rest of the world. I know you don't have this now. But, you should be enforcing it on new customers and you should adjust all of your self-help documentation so that as customers discard PC's and set new ones up, that they start using auth-SMTP on the submission port. It will take a few years. And for some time you will wonder why your bothering since it will seem like your only doing all of the extra work of maintaining auth-smtp for a minority of customer. But the day will come that you will realize the majority of your customers are using smtp-auth. And every day after that the number of clients sending mail directly to port 25 will continue to dwindle and you will become more and more interested in just chopping the minority off and letting them scream. Ted Alexandre Chapellon wrote: Hello the list, I have a quite buggy customer network, full of zombie PCs that spends all days sending spam and wasting the whole reputation of my networks. As a result it sometimes become quite hard to delivers queues for specific domains such as Yahoo!'s hosted ones. Indeed they have some temp fail (blacklist) mechanism that forbid my servers to send messages to them during hours. Taht's why I would like to setup some ougoing filtering to avoid sending too much spam through my mail relays. I think SA can help me in doing so, but I know too it's not really intented to work this way. I guess SA expects to work on MX hosts more than on smtp relays. My prerequisites are mainly: - STOP as much spam as possible at SMTP time (before queuing) - Have NO (or very few) false positives cause I could not manage telling thousands of users that they should *always_have_a_subject*, *shouldn't_write_the_subject_in_CAPS* or anything else. Further more I can't rely on RBL because a lot of my dyn IP address are regularily listed on different blacklist. Does anyone have already setup something like that and what specific config/tools/plugin could be usefull for me. If some one already done it does he/she have any statistics about the efficiency of this setup. Best regards.
Re: SA on outgoing SMTP
Le mardi 16 février 2010 à 12:46 -0800, SM a écrit : Hi Alexandre, At 10:44 16-02-10, Alexandre Chapellon wrote: I have a quite buggy customer network, full of zombie PCs that spends all days sending spam and wasting the whole reputation of my networks. Do they send these messages through your mail server? Mostly not but thoose who are doing so make my mail servers being blacklisted from time to times. (And I don't really care about dyn IP adresses being on blacklists... for now) As a result it sometimes become quite hard to delivers queues for specific domains such as Yahoo!'s hosted ones. Indeed they have some temp fail (blacklist) mechanism that forbid my servers to send messages to them during hours. Taht's why I would like to setup some ougoing filtering to avoid sending too much spam through my mail relays. I think SA can help me in doing so, but I know too it's not really intented to work this way. I guess SA expects to work on MX hosts more than on smtp relays. You can still run some SpamAssassin tests to catch some of the spam. This is what i am doing... but I'd like to know if someone has done it too and how efficient it is. I don't want to set this up if It won't change my reputation and just cause some false positives. My prerequisites are mainly: - STOP as much spam as possible at SMTP time (before queuing) As this is outgoing, post-SMTP filtering is not much of an issue. It definetly is when hitting the problem of false positive... I can't let a user thinking we sent his mail when we wrongly dropped it. Further more I can't rely on RBL because a lot of my dyn IP address are regularily listed on different blacklist. Relying on other people to tell you that there is a problem on your network is not a good idea. Sign up for feedback loops. Rate limit mail submissions or set up triggers to identify abnormalities. You may also wish to do traffic flow analysis to see what's going through your network. Indeed Flow analisys is something I didn't think about but which could be helpful regards Regards, -sm
Re: SA on outgoing SMTP
Alexandre Chapellon wrote: Le mardi 16 février 2010 à 20:29 +, Martin Gregorie a écrit : Obvious choices for (4), in order of hitting the infected user with a successively bigger clue stick, are: - silently discard the spam, but you'll also throw away false positives. Using before queuing filtering (on postfix) I reject the mail at SMTP time so the client gets an error (550 i guess) an so is aware (as far as a user can be aware of anything) his mail has been refused. - silently discard the spam and tell him you've done so on a daily basis I don't want to do something like this. Daily notifications might be a good idea. If there is a spam-bot on the user's computer, he will not see the SMTP rejections. The only way he will know he is infected is if you let him know (assuming the generic clueless user here). Sending an email on a daily (or weekly) basis to let him know that there is spam coming from his computer along with a support number to call or a link to an FAQ of some sort would probably be useful. -- Bowie
Re: SA on outgoing SMTP
On Tue, 2010-02-16 at 11:38 -1000, Alexandre Chapellon wrote:
Le mardi 16 février 2010 à 20:29 +, Martin Gregorie a écrit :
I have a quite buggy customer network, full of zombie PCs that spends
all days sending spam and wasting the whole reputation of my
networks.
1) Are you already using separate inbound and outbound mail servers?
yes of course
3) Do you require all outbound mail to go through your servers and have
you blocked users from sending outbound mail directly?
I can't block users from sendin directly I am an ISP my users are
free to use another relay than mine... eg google or yahoo or some
mails relay of their own hosted i don't know where.
This may just be me being confused today, but -- if your users are free
to use external SMTP servers on port 25 (which, as you stated probably
is a major part or your problem, given you mentioned bots), how exactly
is your hypothetical SA bastion server supposed to filter them?
I mean, the bots won't talk to your server, just because you ask nicely.
Enforced transparent SMTP proxy for all outgoing connections to port 25?
--
char *t=\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: SA on outgoing SMTP
It is standard practice in the ISP industry to block outgoing port 25 nowadays on dynamically assigned addresses. This is not a barrier to your customers using another mailserver (google, gmail, etc.) because all of those businesses support Auth-SMTP on the submission port 587. In fact, nowadays most require it. This is only a barrier to your customers who want to operate their own mailservers. Since those customers should have static IP addresses, if your network has any reasonable organization you have a subnet set aside for static IP addresses, one for dynamics, etc. You don't block the statics when your doing this. If your unwilling to block your dynamics from outbound SMTP then it is perfectly legitimate for the rest of the Internet to block you from sending them mail. This is equivalent to somebody being told that a home they own is being used by drug dealers to cook methamphetamines, and the homeowner saying I can hardly imagine to manage the policies of all my renters, and I know they would really don't like it, then the community getting together and firebombing the home one night. Ted Alexandre Chapellon wrote: I am an ISP with over 5 users (wich is not that big for an isp) permannently connected. I can hardly imagine to manage the poilicies of all my customer, and I know they would really don't like it. What if your ISP told you what you got to do, where to go and to forget about your buggy OS your using for years? But mostly I agree, a clean network should be the basis. Le mardi 16 février 2010 à 12:40 -0800, Ted Mittelstaedt a écrit : I know your not going to want to hear this because your looking for a quick fix, but nothing substitutes for good network design. Your buggy customer network should enforce the following: Direct SMTP transmission (port 25) is filtered so that only machines designated as mailservers are allowed to send outbound mail to port 25, everyone else must use the submission port 587 with SMTP authentication to send mail to one of your mailservers, which then relays this to the rest of the world. I know you don't have this now. But, you should be enforcing it on new customers and you should adjust all of your self-help documentation so that as customers discard PC's and set new ones up, that they start using auth-SMTP on the submission port. It will take a few years. And for some time you will wonder why your bothering since it will seem like your only doing all of the extra work of maintaining auth-smtp for a minority of customer. But the day will come that you will realize the majority of your customers are using smtp-auth. And every day after that the number of clients sending mail directly to port 25 will continue to dwindle and you will become more and more interested in just chopping the minority off and letting them scream. Ted Alexandre Chapellon wrote: Hello the list, I have a quite buggy customer network, full of zombie PCs that spends all days sending spam and wasting the whole reputation of my networks. As a result it sometimes become quite hard to delivers queues for specific domains such as Yahoo!'s hosted ones. Indeed they have some temp fail (blacklist) mechanism that forbid my servers to send messages to them during hours. Taht's why I would like to setup some ougoing filtering to avoid sending too much spam through my mail relays. I think SA can help me in doing so, but I know too it's not really intented to work this way. I guess SA expects to work on MX hosts more than on smtp relays. My prerequisites are mainly: - STOP as much spam as possible at SMTP time (before queuing) - Have NO (or very few) false positives cause I could not manage telling thousands of users that they should *always_have_a_subject*, *shouldn't_write_the_subject_in_CAPS* or anything else. Further more I can't rely on RBL because a lot of my dyn IP address are regularily listed on different blacklist. Does anyone have already setup something like that and what specific config/tools/plugin could be usefull for me. If some one already done it does he/she have any statistics about the efficiency of this setup. Best regards.
Re: SA on outgoing SMTP
Alexandre Chapellon wrote: Le mardi 16 février 2010 à 12:46 -0800, SM a écrit : Hi Alexandre, At 10:44 16-02-10, Alexandre Chapellon wrote: I have a quite buggy customer network, full of zombie PCs that spends all days sending spam and wasting the whole reputation of my networks. Do they send these messages through your mail server? Mostly not but thoose who are doing so make my mail servers being blacklisted from time to times. (And I don't really care about dyn IP adresses being on blacklists... for now) No, you don't - but the rest of us care very much about getting the garbage that those dyn IP addresses are sending out. You need to adjust your attitude. I'm glad your at least trying to do something about spam but it certainly appears that your only interested in it insofar as it affects you, and you don't give a rat's ass about how your network affects the rest of us. Ted
Re: SA on outgoing SMTP
On Tue, 2010-02-16 at 11:49 -1000, Alexandre Chapellon wrote:
I have a quite buggy customer network, full of zombie PCs that
spends all days sending spam and wasting the whole reputation of my
networks.
Do they send these messages through your mail server?
Mostly not but thoose who are doing so make my mail servers being
blacklisted from time to times.
(And I don't really care about dyn IP adresses being on blacklists...
for now)
Hmm, wait. Are you saying the bots are using your infrastructure, rather
than the most common direct to MX? Or are you saying your customers are
actively spamming themselves?
AFAIK bots still don't abuse MUA credentials on the infected machine to
authenticate against the outbound SMTP. A policy change to offer SMTP
only with auth and TLS in 3 months time should be easy to tell your
customers.
Any mail traffic not relaying via your SMTP server should NOT get you on
any blacklist. Serious blacklist, that is.
What blacklists are we talking about?
--
char *t=\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: SA on outgoing SMTP
Le mardi 16 février 2010 à 23:07 +0100, Karsten Bräckelmann a écrit : On Tue, 2010-02-16 at 11:49 -1000, Alexandre Chapellon wrote: I have a quite buggy customer network, full of zombie PCs that spends all days sending spam and wasting the whole reputation of my networks. Do they send these messages through your mail server? Mostly not but thoose who are doing so make my mail servers being blacklisted from time to times. (And I don't really care about dyn IP adresses being on blacklists... for now) Hmm, wait. Are you saying the bots are using your infrastructure, rather than the most common direct to MX? Or are you saying your customers are actively spamming themselves? If I take a look at the feedback loop i received I can see that some bots are sending directly to mx and somes other are sending to my mails relay (probably using outlook connectors or others) AFAIK bots still don't abuse MUA credentials on the infected machine to authenticate against the outbound SMTP. A policy change to offer SMTP only with auth and TLS in 3 months time should be easy to tell your customers. I already set up SMTP-AUTH few month ago but it's not mandatory yet and most of my users didn't configured it yet. Any mail traffic not relaying via your SMTP server should NOT get you on any blacklist. Serious blacklist, that is. If talking about blacklist, of course the problem is spam my server relay. What blacklists are we talking about? I'd like to re-focused to my initial questions: does SA on outgoing smtp needs specific tweaks? Is it a good idea and does any body already set it up? thanks
Re: SA on outgoing SMTP
On Tue, 2010-02-16 at 11:38 -1000, Alexandre Chapellon wrote: Le mardi 16 février 2010 à 20:29 +, Martin Gregorie a écrit : On Tue, 2010-02-16 at 08:44 -1000, Alexandre Chapellon wrote: Hello the list, I have a quite buggy customer network, full of zombie PCs that spends all days sending spam and wasting the whole reputation of my networks. 1) Are you already using separate inbound and outbound mail servers? yes of course OK, so nothing is stopping you from running separate inbound and outbound SA rule sets. If you include spamc in your SMTP-time processing you can easily reject spam with 5xx responses. Granted a spam-bot will consume any directed at it, but if a FP reject is returned to the user's MUA he should see it. Look at grey-listing as well. It should be useful if it can distinguish between the user's MUA (or private MTA) and a bot. Better yet, as others have suggested, swap over to using SMTP authentication and TLS. Once you've blocked direct outward SMTP, using authenticated SMTP will also stop the bots in their tracks. I can't block users from sendin directly I am an ISP my users are free to use another relay than mine... eg google or yahoo or some mails relay of their own hosted i don't know where. Why on earth not? You control TC for your ISP and can change them. If necessary you can keep existing charges for authenticated connections and raise them for those who don't convert. - silently discard the spam and tell him you've done so on a daily basis I don't want to do something like this. Where's the problem? You'll need to write some code to interpret SA's spam markers anyway, so it can easily add a log message to maillog. Then its trivial to extend logwatch to scan the maillog and generate messages to spamiferous users. Martin
Re: SA on outgoing SMTP
Le mardi 16 février 2010 à 23:54 +, Martin Gregorie a écrit : On Tue, 2010-02-16 at 11:38 -1000, Alexandre Chapellon wrote: Le mardi 16 février 2010 à 20:29 +, Martin Gregorie a écrit : On Tue, 2010-02-16 at 08:44 -1000, Alexandre Chapellon wrote: Hello the list, I have a quite buggy customer network, full of zombie PCs that spends all days sending spam and wasting the whole reputation of my networks. 1) Are you already using separate inbound and outbound mail servers? yes of course OK, so nothing is stopping you from running separate inbound and outbound SA rule sets. If you include spamc in your SMTP-time processing you can easily reject spam with 5xx responses. Granted a spam-bot will consume any directed at it, but if a FP reject is returned to the user's MUA he should see it. Look at grey-listing as well. It should be useful if it can distinguish between the user's MUA (or private MTA) and a bot. Better yet, as others have suggested, swap over to using SMTP authentication and TLS. Once you've blocked direct outward SMTP, using authenticated SMTP will also stop the bots in their tracks. thanks I can't block users from sendin directly I am an ISP my users are free to use another relay than mine... eg google or yahoo or some mails relay of their own hosted i don't know where. Why on earth not? You control TC for your ISP and can change them. If necessary you can keep existing charges for authenticated connections and raise them for those who don't convert. My english is not good enough to understand this sorry :p - silently discard the spam and tell him you've done so on a daily basis I don't want to do something like this. Where's the problem? You'll need to write some code to interpret SA's spam markers anyway, so it can easily add a log message to maillog. Then its trivial to extend logwatch to scan the maillog and generate messages to spamiferous users. Believe me I can't. If I reject mail, user have to be informed when I do it and not even 12 hours after. I have governemental customer, and they are really... demanding. Martin
Re: SA on outgoing SMTP
On Tue, 2010-02-16 at 13:43 -1000, Alexandre Chapellon wrote:
Le mardi 16 février 2010 à 23:07 +0100, Karsten Bräckelmann a écrit :
Hmm, wait. Are you saying the bots are using your infrastructure, rather
than the most common direct to MX? Or are you saying your customers are
actively spamming themselves?
If I take a look at the feedback loop i received I can see that some
bots are sending directly to mx and somes other are sending to my
mails relay (probably using outlook connectors or others)
Authenticated!?
Also, do you care about those sending direct to MX?
AFAIK bots still don't abuse MUA credentials on the infected machine to
authenticate against the outbound SMTP. A policy change to offer SMTP
only with auth and TLS in 3 months time should be easy to tell your
customers.
I already set up SMTP-AUTH few month ago but it's not mandatory yet
and most of my users didn't configured it yet.
This is a good time to have it mandatory in 2 months, don't you think?
Either auth, or use some external SMTP. No excuse, no mercy.
What blacklists are we talking about?
I'd like to re-focused to my initial questions:
I'd like to get an answer to the question.
Yes, the blacklist might make a hell of a difference. And the answer to
this might even make a difference, if you really want to filter outbound
mail through SA, or if there are other alternatives.
does SA on outgoing smtp needs specific tweaks? Is it a good idea and
does any body already set it up?
Yes, it needs specific tweaks. As has been pointed out before. For
starters, you do not want any PBL style blacklists. Given the bot
infected picture of your customers you paint, you definitely don't want
any XBL style blacklists either.
Oh, and of course the yet-unnamed ones *you* are listed on... See?
Good idea? Depends. For some, yes. Someone done it before? Definitely.
Did you google or check this list's archives?
guenther
--
char *t=\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: SA on outgoing SMTP
On Wednesday February 17 2010 00:43:04 Alexandre Chapellon wrote: I'd like to re-focused to my initial questions: does SA on outgoing smtp needs specific tweaks? Is it a good idea and does any body already set it up? SA already has some awareness of mail flow direction (inbound vs. outbound) through its trusted_networks/internal_networks/msa_networks settings, and recognizes authentication signs in Received header fields, as well as its whitelist_bounce_relays awareness, so it should be able to deal with things like DUL blacklists correctly. Since you already have split mail paths, i.e. a dedicated MTA for outgoing mail, that's even easier, you can just turn off some dynamic blacklist lookups and adjust some other rules for mail submitted from internal networks or from authenticated roaming users. Is it a good idea to check outgoing mail? It certainly is, as you are already well aware. Mail filtering on a MTA should be combined with blocking outgoing connections to port 25, as already noted by several posters. Allow outgoing connections to mail submission port 587 and to a legacy port 465, but allow outgoing connections to 25 only based on explicit requests from users, and block it by default. Mail submission rate limiting is very effective against traffic bursts from infected PCs. As you are using Postfix, see its anvil(8) service, along with its settings: anvil_rate_time_unit smtpd_client_connection_count_limit smtpd_client_connection_rate_limit smtpd_client_message_rate_limit smtpd_client_event_limit_exceptions A more fine-grained rate control is possible through policy servers, there are a couple of them much praised - check the postfix user ML. As for interfacing SpamAssassin with a Postfix MTA there are some choices, perhaps the most straightforward is using amavisd in place of spamd because it speaks a SMTP protocol directly on its input and output sides, interfacing naturally with Postfix without resorting to pipes, temporary files, scripts, etc. Just turn off anything not needed (like decoding mail), and you end up basically with a spamd lookalike speaking SMTP. The setup offers a fast interface to virus scanners such as clamd, to protect against outbound virus outbreaks too. As a bonus, such setup can offer DKIM signing, and a 'pen-pals' feature when inbound and outbound content filtering uses the same SQL database: grants some bonus score points to inbound replies to previous outbound mail with reversed sender/recipient addresses, similar to an automatic soft-whitelisting, which gradually fades away with time. Depending on mail rate and your needs, you may choose a more common and robust post-queue content filtering setup, or go for a pre-queue proxy content filtering. For improved robustness of a pre-queue setup look for Postfix 2.7.0 with its smtpd_proxy_options=speed_adjust feature, the coming amavisd-new 2.7.0, and SpamAssassin 3.3.0 - the combination of new features in all three products is really geared to much better support pre-queue setups. Mark
Re: SA on outgoing SMTP
Look at grey-listing as well. It should be useful if it can distinguish between the user's MUA (or private MTA) and a bot. MUAs generally don't cope well with greylisting, as they lack good mechanisms for automatic retries - so I'm not sure that's a good advice. Why on earth not? You control TC for your ISP and can change them. If necessary you can keep existing charges for authenticated connections and raise them for those who don't convert. My english is not good enough to understand this sorry :p TC = terms and conditions. It's your call to set rules of the game. Tell the clients that for a little effort on their part turning on the SASL authentication and submitting through standard mail submission ports, they will be gaining a better service with more reliable acceptance rate by their recipients. Here is another good incentive to use a mail submission service of a domain matching their From address: they gain a valid DKIM signature on their outgoing mail. For example: when using a gmail From address it pays off to submit mail to google on port 587 - the message gains a gmail signature. Sending directly from a home or small office machine and using a gmail or yahoo From address is likely to be treated as second-class mail by recipients (not trustworthy, likely to gain some spam score points). The same (but in reverse) applies to outgoing mail using your ISP's domain: it pays off to submit it to ISP's mail submission service, this is the only way to gain its DKIM signature. Increasing number of domains (like yahoo) treat mail with a valid DKIM signature favourably. Mark
Re: SA on outgoing SMTP
For improved robustness of a pre-queue setup look for Postfix 2.7.0 with its smtpd_proxy_options=speed_adjust feature Btw, the Postfix 2.7.0 also brings a feature which may be valuable to you: an outgoing MTA can have multiple IP addresses on its interface, and you can choose from which IP address a mail will be sent based on some criteria you establish to differentiate your customers. Postfix 2.7.0 release notes: - Support for reputation management based on the local SMTP client IP address. This is typically implemented with FILTER transportname: actions in access maps or header/body checks, and mail delivery transports in master.cf with unique smtp_bind_address values. For example, let mail submitted by authenticated mail clients on a mail submission port go out on one IP address, then let mail from some trustworthy clients (small offices) with static addresses go out with a second IP address, and let the third IP address be used for everybody else. Eventually recipients may be able to assign reputations to each of your outgoing IP addresses, perhaps treating the first two more favourably or even whitelisting them, but certainly there will be less chance they end up on some blacklist. Mark
Re: SA on outgoing SMTP
At 13:49 16-02-10, Alexandre Chapellon wrote: Mostly not but thoose who are doing so make my mail servers being blacklisted from time to times. (And I don't really care about dyn IP adresses being on blacklists... for now) Your subnet will probably be blacklisted. As this is not the right venue to talk about escalation, I won't get into that. This is what i am doing... but I'd like to know if someone has done it too and how efficient it is. It can be quite efficient. If you are going to use a stock installation, it may not be as efficient. The efficiency also depends on the user-base. I don't want to set this up if It won't change my reputation and just cause some false positives. It won't change your reputation overnight. You will also have to overcome the growing pains if you have never used SpamAssassin. It definetly is when hitting the problem of false positive... I can't let a user thinking we sent his mail when we wrongly dropped it. I am not talking about dropping mail. False positives _will_ happen. Regards, -sm
Re: SA on outgoing SMTP
On Wed, 2010-02-17 at 02:07 +0100, Mark Martinec wrote: Look at grey-listing as well. It should be useful if it can distinguish between the user's MUA (or private MTA) and a bot. MUAs generally don't cope well with greylisting, as they lack good mechanisms for automatic retries - so I'm not sure that's a good advice. I wondered about that as I wrote it. IIRC I've seen the equivalent while I was working out how to set up my system. The likes of Evolution tend to report the error and leave the message sitting in the outbox. Thats a good indication of trouble provided you notice its still there. TC = terms and conditions. It's your call to set rules of the game. Tell the clients that for a little effort on their part turning on the SASL authentication and submitting through standard mail submission ports, they will be gaining a better service with more reliable acceptance rate by their recipients. I was also suggesting something along the lines of we'll still permit non-authenticated connections but we'll charge 100% more for that privilege. Martin
Re: SA on outgoing SMTP
Mark Martinec wrote: Look at grey-listing as well. It should be useful if it can distinguish between the user's MUA (or private MTA) and a bot. MUAs generally don't cope well with greylisting, as they lack good mechanisms for automatic retries - so I'm not sure that's a good advice. greylist-milter exempts auth-smtp senders, obviously this is a Sendmail thing, I don't know about other greylisting programs. Why on earth not? You control TC for your ISP and can change them. If necessary you can keep existing charges for authenticated connections and raise them for those who don't convert. My english is not good enough to understand this sorry :p TC = terms and conditions. It's your call to set rules of the game. Tell the clients that for a little effort on their part turning on the SASL authentication and submitting through standard mail submission ports, they will be gaining a better service with more reliable acceptance rate by their recipients. Here is another good incentive to use a mail submission service of a domain matching their From address: they gain a valid DKIM signature on their outgoing mail. For example: when using a gmail From address it pays off to submit mail to google on port 587 - the message gains a gmail signature. Sending directly from a home or small office machine and using a gmail or yahoo From address is likely to be treated as second-class mail by recipients (not trustworthy, likely to gain some spam score points). The same (but in reverse) applies to outgoing mail using your ISP's domain: it pays off to submit it to ISP's mail submission service, this is the only way to gain its DKIM signature. Increasing number of domains (like yahoo) treat mail with a valid DKIM signature favourably. Just keep in mind that he's in a guns-or-butter problem. He's making guns now (network wide open, causing customer problems, the upside is client configuration is simple) and he wants to make butter (network tight, no customer problems, at the cost of increased client configuration complexity) During the time that he's transitioning from the guns to the butter his network is doing both things - and so it has all of the bad problems of the gunmaking, (spammers) plus all of the downsides of the butter making (basically increased work to configure mail clients) yet he is getting none of the benefits of either the gunmaking (he's no longer getting easy client configuration) or the buttermaking (a tight network) It takes someone very strongly focused on the end result, who believes in what they are doing, and who has the support of their owners/upper managers, to make it through such a transition. And there will be scars. They WILL lose customers. Of course, doing nothing they lose customers too - but since the customer loss isn't coming as a result of anyone doing anything, (but rather of people failing to do something) it's hard for upper managers of the pointy-haired type to levy blame, so people in those situations tend to not get fired. Sometimes companies will hire sacrificial lambs This is common in government. For example a few years ago our local school district needed to close some schools (political suicide for anyone) due to declining enrollment, so they hired some $200K+ Harvard-educated, resume-as-long-as-my-dick type to come in and kick ass - and kick ass she did. She closed at least a dozen schools down before the losers managed to band together and toss her out. Of course, now the school district had the perfect excuse to NOT reopen the schools (too expensive to restart them because they had been closed for too long) and after the obligatory public chest-beating and wailing about how we are so sorry that your kid can't go to the school you went to 30 years ago when you were knee-high to a grasshopper, a few years later the losing parents had completed cycling their kids through the school system, and nowadays no parent with kids in the system even remembers the names of any of the closed schools, let alone where they were located. If his management won't let him do what it takes, he might need to hire a sacrificial lamb consulting firm, too. Ted
Re: SA on outgoing SMTP
On Tue, 2010-02-16 at 14:10 -1000, Alexandre Chapellon wrote: Le mardi 16 février 2010 à 23:54 +, Martin Gregorie a écrit : Where's the problem? You'll need to write some code to interpret SA's spam markers anyway, so it can easily add a log message to maillog. Then its trivial to extend logwatch to scan the maillog and generate messages to spamiferous users. Believe me I can't. If I reject mail, user have to be informed when I do it and not even 12 hours after. Surely that depends on the customer? For a normal customer (private, small company) a once a day reminder about spam may be good enough. Remember that undeliverable mail can and does get returned up to 4-5 days later. I have governemental customer, and they are really... demanding. If you normally configure your routers to block direct connections via port 25 you can equally configure the router to allow large or demanding customers with static IPs to use direct connections but you should make it quite clear that they are then responsible for their own outbound spam filtering and inbound filtering too, on the grounds that you don't want to be responsible for FPs interfering with their business. Martin 1) Martin
Re: SA on outgoing SMTP
Le mercredi 17 février 2010 à 01:38 +0100, Karsten Bräckelmann a écrit : On Tue, 2010-02-16 at 13:43 -1000, Alexandre Chapellon wrote: Le mardi 16 février 2010 à 23:07 +0100, Karsten Bräckelmann a écrit : Hmm, wait. Are you saying the bots are using your infrastructure, rather than the most common direct to MX? Or are you saying your customers are actively spamming themselves? If I take a look at the feedback loop i received I can see that some bots are sending directly to mx and somes other are sending to my mails relay (probably using outlook connectors or others) Authenticated!? The one using SMTP-AUTH to relay spam through my servers are most of the time IP address outside of my network... I imagine they have credentials sent by trojan or stuff like this. But I also have others that are machines inside my network using AUTH. If you want to take a look at it, I can forward one complaint. Also, do you care about those sending direct to MX? To track direct to MX I will monitor feedback loop and complaints (from spamcop and others) and send warning to my customers.. AFAIK bots still don't abuse MUA credentials on the infected machine to authenticate against the outbound SMTP. A policy change to offer SMTP only with auth and TLS in 3 months time should be easy to tell your customers. I already set up SMTP-AUTH few month ago but it's not mandatory yet and most of my users didn't configured it yet. This is a good time to have it mandatory in 2 months, don't you think? Either auth, or use some external SMTP. No excuse, no mercy. lol... I can't afford no excuse, no mercy... But I will do my best to make the life of people not using auth harder and harder every day. What blacklists are we talking about? I'd like to re-focused to my initial questions: I'd like to get an answer to the question. Not public blacklists but for example Yahoo!'s servers spends most of its days replying defered temporarily due user complaints' o our relays. Yes, the blacklist might make a hell of a difference. And the answer to this might even make a difference, if you really want to filter outbound mail through SA, or if there are other alternatives. does SA on outgoing smtp needs specific tweaks? Is it a good idea and does any body already set it up? Yes, it needs specific tweaks. As has been pointed out before. For starters, you do not want any PBL style blacklists. Given the bot infected picture of your customers you paint, you definitely don't want any XBL style blacklists either. Oh, and of course the yet-unnamed ones *you* are listed on... See? Good idea? Depends. For some, yes. Someone done it before? Definitely. Did you google or check this list's archives? Yes but if can find people saying i'm doing thing, I can't find feedback on how it worked ou... guenther
Re: SA on outgoing SMTP
Le mercredi 17 février 2010 à 02:07 +0100, Mark Martinec a écrit : Look at grey-listing as well. It should be useful if it can distinguish between the user's MUA (or private MTA) and a bot. MUAs generally don't cope well with greylisting, as they lack good mechanisms for automatic retries - so I'm not sure that's a good advice. Why on earth not? You control TC for your ISP and can change them. If necessary you can keep existing charges for authenticated connections and raise them for those who don't convert. My english is not good enough to understand this sorry :p TC = terms and conditions. It's your call to set rules of the game. Tell the clients that for a little effort on their part turning on the SASL authentication and submitting through standard mail submission ports, they will be gaining a better service with more reliable acceptance rate by their recipients. Here is another good incentive to use a mail submission service of a domain matching their From address: they gain a valid DKIM signature on their outgoing mail. For example: when using a gmail From address it pays off to submit mail to google on port 587 - the message gains a gmail signature. Sending directly from a home or small office machine and using a gmail or yahoo From address is likely to be treated as second-class mail by recipients (not trustworthy, likely to gain some spam score points). The same (but in reverse) applies to outgoing mail using your ISP's domain: it pays off to submit it to ISP's mail submission service, this is the only way to gain its DKIM signature. Increasing number of domains (like yahoo) treat mail with a valid DKIM signature favourably. This really sounds great. More reliable mail for my customer, and a cleaner network for me. Thank you Mark
Re: SA on outgoing SMTP
Le mercredi 17 février 2010 à 01:52 +, Martin Gregorie a écrit : On Tue, 2010-02-16 at 14:10 -1000, Alexandre Chapellon wrote: Le mardi 16 février 2010 à 23:54 +, Martin Gregorie a écrit : Where's the problem? You'll need to write some code to interpret SA's spam markers anyway, so it can easily add a log message to maillog. Then its trivial to extend logwatch to scan the maillog and generate messages to spamiferous users. Believe me I can't. If I reject mail, user have to be informed when I do it and not even 12 hours after. Surely that depends on the customer? For a normal customer (private, small company) a once a day reminder about spam may be good enough. Remember that undeliverable mail can and does get returned up to 4-5 days later. Yes but most of the time (here) undeliverable mails are undeliverable because of recipient over quota, wrong mx records on dst domain or things like this... I can explain this to my customer. By cons I cannot tell him we silently droped your mail this morning cause it looked like spam... at least I don't feel confortable with this. I have governemental customer, and they are really... demanding. If you normally configure your routers to block direct connections via port 25 you can equally configure the router to allow large or demanding customers with static IPs to use direct connections but you should make it quite clear that they are then responsible for their own outbound spam filtering and inbound filtering too, on the grounds that you don't want to be responsible for FPs interfering with their business. Martin 1) Martin
Re: SA on outgoing SMTP
I'd like to thank everybody for all the ideas spreaded around... This will give me good clues, differents axis of reflexion, and arguments for makers. Regards
