spamd sighup win32
Hi, does anybody know how to send a SIGHUP signal to spamd under win32? I already tried taskkill /IM (regarding to http://thehoneymonster.net/2009/08/kill-and-killall-for-windows/ equivalent to the unix SIGHUP) but the process didn't respond. taskkill /IM spamd /F kills the process but doesn't generate a log entry like it does when killed by Strg+C (info: spamd: server killed by SIGINT, shutting down). If Strg+C is able to shut down it properly, there must be a way to do this by console AND also to give it the command to restart for reloading the system-wide config files. Daniel JAM Software GmbH Gesch?ftsf?hrer: Joachim Marder Max-Planck-Str. 22 * 54296 Trier * Germany Tel: 0651-145-653 -0 * Fax: 0651-145-653 -29 Handelsregister Nr. HRB 4920 (AG Wittlich) http://www.jam-software.de
Re: MTX public blacklist implemented Re: MTX plugin functionally complete?
On 02/16, Charles Gregory wrote: You got it. Exactly. And that's why I gave up on MTX. Because the author was insisting that exactly that should happen. I have never recommended that the majority of people penalize email just because it doesn't get an MTX Pass, before wide spread adoption. In my initial posts I did focus too much on my hope that MTX will eventually be sufficiently widely adopted that such mail *can* safely be penalized. I also apologized for that communication failure on my part. Perhaps if you read the current version of the web page, you will be more comfortable with my intentions. It has changed quite a lot since my first post: http://www.chaosreigns.com/mtx/ -- Blessed are the cracked, for they shall let in the light. http://www.ChaosReigns.com
Re: spamd sighup win32
Daniel Lemke wrote on Tue, 16 Feb 2010 15:05:46 +0100: does anybody know how to send a SIGHUP signal to spamd under win32? I already tried taskkill /IM (regarding to http://thehoneymonster.net/2009/08/kill-and-killall-for-windows equivalent to the unix SIGHUP) but the process didn't respond. I think you need to signal to the running perl.exe process. Don't know if it can trap that signal and do something else than hanging up. Kai -- Get your web at Conactive Internet Services: http://www.conactive.com
MTX - How does it stop spam?
I'm looking over your MTX site and like SPF I don't understand how it stops spam. Thanks for at least addressing in part the email forwarding issue. In order to be a white list you have to do something spammers can't do. I don't see what prevents spammers from creating good MTX records like they do with SPF and whitelisting themselves. Since your idea also requires blacklists to counter this effect then I'm still not sure what this adds. As you know people register new domain names just to avoid being on any list so your idea would seem to be a white list for those who exploit that. As to penalizing those who don't participate, I already have enough headaches with SPF and others who want to inflict their personal standards on the whole of the email community. SPF. which has left me with a bad attitude, does nothing for me to catch spam or pass ham. But it does result in good email that I forward being blocked. I'm always looking for innovative ideas that actually work. I don't want to discourage you. But the actually works part is very important. I have had a lot of ideas that I got really excited about and after I implemented them I found out that the idea wasn't quite as good as I thought it would be. As to whitelisting - there's actually a far easier solution that I use. I do RDNS to get the host name. Then I forward confirm it to verify that it is valid. Spammers can't spoof that. Then I look it up in my host name white list of hosts who send nothing but good email. This actually works extremely well. But like everyone I'm always looking for more ideas especially for white rules because in y bustness one good email bounced is words that 100 spams not bounced.
Re: MTX public blacklist implemented Re: MTX plugin functionally complete?
dar...@chaosreigns.com wrote: In my initial posts I did focus too much on my hope that MTX will eventually be sufficiently widely adopted that such mail *can* safely be penalized. I also apologized for that communication failure on my part. I'm still waiting for RDNS to be widely adopted enough to penalize for that. There is a lot of good email that comes from misconfigured servers. If we can't get the world to do good RDNS I don't think we can get the world to do some other more complex scheme.
Increase spamassassin -r verbosity?
People, I'd appreciate a pointer how should spamassassin -r be made more verbose, so that it'd report also messages with priority info, but not dbg... signature.asc Description: This is a digitally signed message part.
Re: Increase spamassassin -r verbosity?
Kārlis, I'd appreciate a pointer how should spamassassin -r be made more verbose, so that it'd report also messages with priority info, but not dbg... spamassassin --debug area=noall -r msg Mark
Re: Increase spamassassin -r verbosity?
I'd appreciate a pointer how should spamassassin -r be made more verbose, so that it'd report also messages with priority info, but not dbg... spamassassin --debug area=noall -r msg Sorry, wrong syntax, should be: spamassassin --debug noall -r msg or spamassassin --debug info -r msg Mark
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: MTAmark (was: MTX plugin functionally complete?)
At 02:56 15-02-10, Per Jessen wrote: I went to google mtamark, and came across a few discussions on mailing lists (e.g. at www.sage.org) as well as an article in iX (German IT magazine) in 2005. The proposal was certainly discussed quite a bit, but it's not very clear what then happened. I also saw a few links to personal pages at space.net, but they're long gone. There is experimental support for MTAMARK in a well-known MTA. The proposal had less exposure than SPF. Regards, -sm
Re: MTX - How does it stop spam?
Marc Perkel wrote: ... Since your idea also requires blacklists to counter this effect then I'm still not sure what this adds. *nod* This is the biggest question I still see remaining; who maintains the blacklist? How many spams can come from an MTX-approved IP before it can/should be blacklisted? -kgd
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] Re: MTX - How does it stop spam?
On Tue, 16 Feb 2010, Kris Deugau wrote: *nod* This is the biggest question I still see remaining; who maintains the blacklist? How many spams can come from an MTX-approved IP before it can/should be blacklisted? Why do we need any new/special blacklist at all? If the spamming from a given IP is sufficiently large, the regular internet blacklists will capture this IP and do a far better job of blacklisting, managing removes, etc, etc. Why reinvent the wheel? - C
Re: MTX - How does it stop spam?
On 02/16, Marc Perkel wrote: I'm still waiting for RDNS to be widely adopted enough to penalize for that. There is a lot of good email that comes from misconfigured servers. If we can't get the world to do good RDNS I don't think we can get the world to do some other more complex scheme. If valid RDNS were a usefully unforgable way to detect spam, I like to think there would be more of a push to straighten it out. But spammers have quite a lot of IPs to use with valid RDNS already. So I think requiring it for something that has a better chance of blocking spam has a better chance of getting RDNS set up properly. On 02/16, Marc Perkel wrote: I'm looking over your MTX site and like SPF I don't understand how it stops spam. Thanks for at least addressing in part the email forwarding issue. To take an example off the end of my log file: You get an email delivered by 163.20.114.1. You look up the host name (PTR record) of that IP, it's: dns.mcjh.tpc.edu.tw. The IP and hostname make the MTX record: 1.114.20.163.mtx.dns.mcjh.tpc.edu.tw. You look up the value of that DNS A record. It comes back not found. That's an MTX Fail. So you check the MTX Policy on the domain. The MTX Policy record for that domain is named: policy.mtx.tpc.edu.tw. If that DNS A record had the value 127.0.0.2 (HardFail, no delegation), that would give this email an MTX HardFail, and you'd reject it. Does that answer your question? In order to be a white list you have to do something spammers can't do. That's why a blacklist of spammers using MTX is necessary. I believe maintaining it will be far easier than maintaining blacklists of all the spammer domains or IPs, since there are fewer opportunities where a spammer owns both the IP *and* uses a domain they own. As I said in the example, MTX will have problems in cases where the spammer owns the IP and uses a throwaway domain, one which they only use for a short burst of spam until the blacklists catch up with them. But I believe that subset of IPs will be easier to maintain a blacklist of, and if the spammers are pinned down that far, and all we have to focus our attention on is the problem of throwaway domains, I think it'll get handled. SPF does not require the spammer to own the IP. They can use somebody else's IP, use a domain they own in the MAIL FROM, which points to the SPF record on their own domain, in which they can include whatever IPs they want. this adds. As you know people register new domain names just to avoid being on any list so your idea would seem to be a white list for those who exploit that. *And* own the transmitting IP, yes. As to penalizing those who don't participate, I already have enough I don't recommend that. headaches with SPF and others who want to inflict their personal standards on the whole of the email community. SPF. which has left me with a bad attitude, does nothing for me to catch spam or pass ham. But it does result in good email that I forward being blocked. Yup. That's specifically why I made MTX. As to whitelisting - there's actually a far easier solution that I use. I do RDNS to get the host name. Then I forward confirm it to verify that it is valid. Spammers can't spoof that. Then I look it up in my host There are plenty of IPs configured to pass that available to spammers, but your next point covers that problem. name white list of hosts who send nothing but good email. This actually works extremely well. But like everyone I'm always looking for more Yup, that sounds good. DNSWL is a public whitelist intended for that kind of use, but based on IPs instead of host names. I assume you don't penalize email for not being on your whitelist? ideas especially for white rules because in y bustness one good email bounced is words that 100 spams not bounced. I think that's true for most people. It certainly shows in the non-spam / spam accuracy ratios SpamAssassin aims for when re-scoring the test set. -- Anarchy is based on the observation that since few are fit to rule themselves, even fewer are fit to rule others. -Edward Abbey http://www.ChaosReigns.com
Re: MTX - How does it stop spam?
On 02/16, Kris Deugau wrote: Marc Perkel wrote: ... Since your idea also requires blacklists to counter this effect then I'm still not sure what this adds. *nod* This is the biggest question I still see remaining; who maintains the blacklist? How many spams can come from an MTX-approved IP before it can/should be blacklisted? Because I believe it will be far easier to maintain a list of IPs and / or domains which spam *and* use MTX, due to significant reduction in IPs they can spam from. My last post went into more detail. The problem of deciding at which point you blacklist somebody is the reason why my blacklist implementation allows you to set an SA score for each domain. So hosts which send legitimate email *and* spam you can give a score which only negates the effect of the MTX Pass. The public blacklist implementation also allows for this distinction. -- Will I ever learn? I hope not, I'm having too much fun. - Brent Minime Avis, motorcycle.com http://www.ChaosReigns.com
Re: MTX - How does it stop spam?
Am 16.02.10 21:23, schrieb Kris Deugau: *nod* This is the biggest question I still see remaining; who maintains the blacklist? How many spams can come from an MTX-approved IP before it can/should be blacklisted? It does not necessarily or exclusively need to be a manually maintained blacklist. Domain-age- and usage-based blacklists would be useful in that context. -- Matthias
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; }}}
is bayes learning?
I've got a feeling that the spamassassin on my machine is improving in the way it recognises spam but I'd like to be sure it's not just my imagination. I did my first manual bayes learn about 2 weeks ago using 200 spams and 200 hams, the process appeared to go properly. I read that autolearn is enabled by default and kicks in after 200 emails learnt, but is there a way to tell whether bayes is actually learning? -- View this message in context: http://old.nabble.com/is-bayes-learning--tp27616380p27616380.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: is bayes learning?
Hi, [r...@freebsd ]# sa-learn --dump magic 0.000 0 3 0 non-token data: bayes db version 0.000 0 0 0 non-token data: nspam 0.000 0 22 0 non-token data: nham 0.000 0793 0 non-token data: ntokens 0.000 0 1266272147 0 non-token data: oldest atime 0.000 0 1266318121 0 non-token data: newest atime 0.000 0 0 0 non-token data: last journal sync atime 0.000 0 0 0 non-token data: last expiry atime 0.000 0 0 0 non-token data: last expire atime delta 0.000 0 0 0 non-token data: last expire reduction count [r...@freebsd /]# date -r 1266318121 Tue Feb 16 12:02:01 CET 2010 newsest atime should tell you when it last learned from a message. Yes, my system is new and not yet using bayes ... mvh On Wed, Feb 17, 2010 at 12:22 AM, tonjg t...@freeuk.com wrote: I've got a feeling that the spamassassin on my machine is improving in the way it recognises spam but I'd like to be sure it's not just my imagination. I did my first manual bayes learn about 2 weeks ago using 200 spams and 200 hams, the process appeared to go properly. I read that autolearn is enabled by default and kicks in after 200 emails learnt, but is there a way to tell whether bayes is actually learning? -- View this message in context: http://old.nabble.com/is-bayes-learning--tp27616380p27616380.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
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
getting different SA scores depending on which outgoing smtp is used, though same sender IP and SA
Hi SA peeps, I noticed that I was triggering RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC when sending mail through my own spamassassin, which is spamassassin-3.2.5-2 from the fc10 repo, configured via mimedefang and sendmail-milter. I decided to try sending through my ISP's smtp server instead, and it doesn't trigger the same rules, even though the content is the same, and the client IP address is the same. I have posted the headers below, I was hoping that someone could explain what the differences are that trigger the rules on the first set of headers...? This triggers; Return-Path: t...@limepepper.co.uk Received: from localhost.localdomain (cpc3-seve11-0-0-cust606.popl.cable.ntl.com [82.10.154.95]) (authenticated bits=0) by vs802.ecnow.co.uk (8.14.3/8.14.1) with ESMTP id o1GLrAwn032508 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for bad...@limepepper.co.uk; Tue, 16 Feb 2010 21:53:12 GMT Message-ID: 4b7b13d3.8090...@limepepper.co.uk Date: Tue, 16 Feb 2010 21:53:23 + From: Tom H t...@limepepper.co.uk User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-3.fc11 Lightning/1.0pre Thunderbird/3.0 MIME-Version: 1.0 To: bad...@limepepper.co.uk Subject: test X-Enigmail-Version: 1.0 OpenPGP: id=3B3F97D9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.83 (*) AWL,BAYES_40,HELO_LH_LD,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 209.135.157.202 This one not; Return-Path: t...@limepepper.co.uk Received: from mtaout01-winn.ispmail.ntl.com (mtaout01-winn.ispmail.ntl.com [81.103.221.47]) by vs802.ecnow.co.uk (8.14.3/8.14.1) with ESMTP id o1GMDWHb002121 for t...@limepepper.co.uk; Tue, 16 Feb 2010 22:13:32 GMT Received: from aamtaout04-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id 20100216221344.qbig4204.mtaout01-winn.ispmail.ntl@aamtaout04-winn.ispmail.ntl.com for t...@limepepper.co.uk; Tue, 16 Feb 2010 22:13:44 + Received: from localhost.localdomain ([82.10.154.95]) by aamtaout04-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id 20100216221344.behr22934.aamtaout04-winn.ispmail.ntl@localhost.localdomain for t...@limepepper.co.uk; Tue, 16 Feb 2010 22:13:44 + Message-ID: 4b7b1896.4060...@limepepper.co.uk Date: Tue, 16 Feb 2010 22:13:42 + From: Tom H t...@limepepper.co.uk User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-3.fc11 Lightning/1.0pre Thunderbird/3.0 MIME-Version: 1.0 To: t...@limepepper.co.uk Subject: test X-Enigmail-Version: 1.0 OpenPGP: id=3B3F97D9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=1ggfb5FlKZQUfF3vzm9UBYZ2uTfLsbs/8dSljwg5+mE= c=1 sm=0 a=nS36O97Bj3wUElCrIrAA:9 a=WSUfejPYnVaDIwHsvJh5HpFP3bwA:4 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 X-Spam-Score: 0.175 () AWL,BAYES_00,TVD_SPACE_RATIO X-Scanned-By: MIMEDefang 2.67 on 209.135.157.202 Thanks, Tom
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: is bayes learning?
On Wed, 17 Feb 2010 00:29:38 +0100 Mikael Syska mik...@syska.dk wrote: newsest atime should tell you when it last learned from a message. Token atimes get updated when you scan a mail. Watching nham, nspam counts is more meaningful.
Re: is bayes learning?
On Tue, 2010-02-16 at 15:22 -0800, tonjg wrote: I've got a feeling that the spamassassin on my machine is improving in the way it recognises spam but I'd like to be sure it's not just my imagination. I did my first manual bayes learn about 2 weeks ago using 200 spams and 200 hams, the process appeared to go properly. I read that autolearn is enabled by default and kicks in after 200 emails learnt, but is there a way to tell whether bayes is actually learning? Look at X-Spam-status message headers: X-spam-status: No, score=1.2 required=6.0 tests=BAYES_00,HELO_LOCALHOST, RCVD_IN_BSP_OTHER autolearn=ham version=3.2.5 or scan /var/log/maillog for spamd messages that report the results for each message: Feb 13 04:51:07 zoogz spamd[8924]: spamd: result: Y 15 - BAYES_80, EMPTY_MESSAGE,HELO_LOCALHOST,MG_IMAGEATT,MG_IMAGESUS,MG_JPEG,MG_VIAUKFSN, MISSING_SUBJECT,RCVD_IN_BL_SPAMCOP_NET,SHORT_HELO_AND_INLINE_IMAGE,TVD_SPACE_RATIO scantime=2.0,size=17758,user=getmail,uid=522,required_score=6.0, rhost=localhost.localdomain,raddr=127.0.0.1,rport=41130, mid=20100213044404.5698549saliva...@zavodzpr-sa.ba,bayes=0.873808,autolearn=spam In both places the autolearn clause tells you what, if any, learning was done from the message. The possible answers are ham,spam or no. The latter applies to messages with scores that are fairly close to zero and so were not automatically learned. Martin
Re: getting different SA scores depending on which outgoing smtp is used, though same sender IP and SA
On Wed, 17 Feb 2010 00:01:47 + Tom t...@ecnow.co.uk wrote: Hi SA peeps, I noticed that I was triggering RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC when sending mail through my own spamassassin, which is spamassassin-3.2.5-2 from the fc10 repo, configured via mimedefang and sendmail-milter. I decided to try sending through my ISP's smtp server instead, and it doesn't trigger the same rules, even though the content is the same, and the client IP address is the same. I have posted the headers below, I was hoping that someone could explain what the differences are that trigger the rules on the first set of headers...? That's how it should work. You should be sending through a proper smarthost, and SA is penalizing you when you don't. It doesn't know it's internal because you haven't set your internal network to include your own IP address. Generally local mail shouldn't go through SA so that's not an issue.
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: getting different SA scores depending on which outgoing smtp is used, though same sender IP and SA
On Wed, 2010-02-17 at 00:35 +, RW wrote:
On Wed, 17 Feb 2010 00:01:47 + Tom t...@ecnow.co.uk wrote:
I noticed that I was triggering
RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC when sending mail through
my own spamassassin, which is spamassassin-3.2.5-2 from the fc10 repo,
configured via mimedefang and sendmail-milter.
I decided to try sending through my ISP's smtp server instead, and it
doesn't trigger the same rules, even though the content is the same,
None of these rules are about content.
and the client IP address is the same. I have posted the headers
below, I was hoping that someone could explain what the differences
are that trigger the rules on the first set of headers...?
Think about it this way -- from your MX's perspective, what is the
handing-over IP?
In the first case, it's a dynamic dial-up IP, in a range flagged by your
ISP to not be permitted to do direct to MX delivery, cause it isn't an
SMTP. But a dial-up user, supposed to use his SMTP, which then delivers
into your network. Sounds familiar? Yeah, look at the rules triggered...
In the second case, it's an SMTP that is neither dynamic, nor prohibited
to send mail by policy.
All of these rules are supposed to *only* inspect the last external,
handing-over hop. No deep-inspection. Thus, the originating IP doesn't
matter to them.
That's how it should work. You should be sending through a proper
smarthost, and SA is penalizing you when you don't. It doesn't know it's
internal because you haven't set your internal network to include your
own IP address. Generally local mail shouldn't go through SA so
that's not an issue.
Yeah, have been discussing this very recently. Again. ;) This generally
is an issue, in case your MX is the same as your user-facing outbound
SMTP, *and* you are sending mail to yourself...
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
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: getting different SA scores depending on which outgoing smtp is used, though same sender IP and SA
On 17/02/10 00:35, RW wrote: It doesn't know it's internal because you haven't set your internal network to include your own IP address. Generally local mail shouldn't go through SA so that's not an issue. Hi, Thanks for that reply. What exactly do you mean by set your internal network to include your own IP address. ? Thanks, Tom
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: getting different SA scores depending on which outgoing smtp is used, though same sender IP and SA
On Wed, 17 Feb 2010, RW wrote:
On Wed, 17 Feb 2010 00:01:47 +
Tom t...@ecnow.co.uk wrote:
Hi SA peeps,
I noticed that I was triggering
RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC when sending mail through
my own spamassassin, which is spamassassin-3.2.5-2 from the fc10 repo,
configured via mimedefang and sendmail-milter.
I decided to try sending through my ISP's smtp server instead, and it
doesn't trigger the same rules, even though the content is the same,
and the client IP address is the same. I have posted the headers
below, I was hoping that someone could explain what the differences
are that trigger the rules on the first set of headers...?
That's how it should work. You should be sending through a proper
smarthost, and SA is penalizing you when you don't. It doesn't know it's
internal because you haven't set your internal network to include your
own IP address. Generally local mail shouldn't go through SA so
that's not an issue.
In the general case that is how it should work but not in Tom's particular
case.
If you look closely at that Received: from header in the instance
where those rules fired, there is a (authenticated bits=0) component.
Thus he was using an authenticated-SMTP connection so SA should -NOT-
have fired those rules.
So that says that there's something wrong with his SA install which is
keeping it from recognizing/honoring that authed header.
I seem to remember there was an issue with some milters not properly
passing SMTP-auth header info. Maybe Tom needs to investigate this
for his particular milter.
--
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 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
Re: MTX - How does it stop spam?
On Tue, Feb 16, 2010 at 03:36:53PM -0500, dar...@chaosreigns.com wrote: On 02/16, Kris Deugau wrote: Marc Perkel wrote: ... Since your idea also requires blacklists to counter this effect then I'm still not sure what this adds. *nod* This is the biggest question I still see remaining; who maintains the blacklist? How many spams can come from an MTX-approved IP before it can/should be blacklisted? Because I believe it will be far easier to maintain a list of IPs and / or domains which spam *and* use MTX, due to significant reduction in IPs they can spam from. My last post went into more detail. You keep believing without actually ever explaining anything in detail. How is it easier? You STILL need global traps/feeds to have reasonable data and reputation. Are you going to be the maintainer? I don't see how MTX would help for example Spamhaus. They list everything anyway and it works fine. Some people do maintain own lists, but I don't understand how MTX helps them blacklist either. The problem of deciding at which point you blacklist somebody is the reason why my blacklist implementation allows you to set an SA score for each domain. So hosts which send legitimate email *and* spam you can give a score which only negates the effect of the MTX Pass. The public blacklist implementation also allows for this distinction. I'm sure you know that SA is not the only software/appliance out there. Probably even the minority. Ijf you want to keep a list, it needs to be DNS based anyway. Do you really think once a day update is enough for data which can be old in matter of minutes?
