Re: report_header and use_terse_report errors
Hello, On Sun, 26 Aug 2007 12:18:46 -0700, "Loren Wilton" <[EMAIL PROTECTED]> wrote: >> How can I check it then? > > 1.How does mail get to spamd? In my MTA (exim) under FreeBSD I have spamd_address = 127.0.0.1 783 > 2.How does mail get from spamd to the users? When the check has been finished, mail is delivered by exim to an appropriate user. I used /usr/ports/mail/p5-Mail-SpamAssassin port to install it. Pretty much default settings. Thank you very much! -- Zbigniew Szalbot www.slowo.pl www.lcwords.com
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Marc Perkel wrote: Kai Schaetzl wrote: Duane Hill wrote on Sat, 25 Aug 2007 22:29:50 + (UTC): What happens if the remote MX is within a private IP range? Should I accept that message, knowing fully, the recipient would never be able to respond? This feature looks fine on first glance, but on second I think this is dangerous if it gets applied to all MX positions. For instance the two MX setup where one machine is behind a firewall and a gateway machine is first MX and forwards to the machine behind the firewall. This is an accepted setup. Couldn't I achieve the same thing without a firewall? The first MX gets another IP from a private range and the second is on private only. So, it's not reachable from outside, but the first MX can forward to it. "backup MXs (that don't exist)" doesn't mean a private range. You simply set it to an IP that doesn't have SMTP or one that points to nirvana, but still a valid public IP address. I don't use that technique and don't think I will need to use it in the near future, but I can't see anything bad in it, sorry. As John says only spammers or broken MTAs should have a problem with that. I also agree on SAV with John, it's almost as worse as challenge-response mechanisms. Kai If you have one MX and you create a fake low MX and a fake high MX (or many fake high MX) about 75% to 95% of your spam goes away. It's that simple. I've been following this discussion across all the threads. Mark's ideas are certainly out of the box, and some have merit, maybe all have merit. But I can report that depending on the client, some of the ideas would get me fired within a week, they would certainly get my client's howling into the phone. This is one such idea. While this idea sounds good, and it may work for you, it won't work for us. Unfortunately there are an abundant number of what I like to call "shrink wrap admins". They convince the PHB they can save money, save time, do cool things with their Blackberrys, if they manage their own mail server in house. So they pull a beige PIII out from under a desk, open the MSE box, insert the CD, and before the shrink wrap stops un-wadding itself on the floor they are already goofing up mail to my servers (my clients). Of course, it's my fault when that happens 8^( Examples, though they may not be relevant to the discussion, they are examples of why we cannot block mail using some of the more common or creative techniques. 1) I see thousands of corporate email connections a day from <[EMAIL PROTECTED]>, bad helo is not always a good indicator of a bot/spam/zombie. 2) Many of our client's do a lot of email with businesses that have a mail server running on a static cable IP that still has a dynamic reverse DNS. RDNS is not a good indicator of the legitimacy of a message. 3) We also have plenty of entries in our whitelist for greylisting, because the other server can't handle a temp fail. 4) I'll say it again though a lot of people have told me I am crazy, I see instances often of MS caching DNS for weeks at a time. The stupid server will only try to send to one IP, over, and over, and over. Some times that IP is only one of our MX's. We finally call them and insist they reboot their server. Then wala, it works. I dread taking down a MX for maint, even when the DNS has been expired for a month in advance. I hate spammers, hate 'em, hate 'em, hate 'em. They should be run out of town on a pole. A pole carefully located with a great deal of force. DAve -- Three years now I've asked Google why they don't have a logo change for Memorial Day. Why do they choose to do logos for other non-international holidays, but nothing for Veterans? Maybe they forgot who made that choice possible.
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
On Sun, 26 Aug 2007, Marc Perkel wrote:
> If you have one MX and you create a fake low MX and a fake high MX (or
> many fake high MX) about 75% to 95% of your spam goes away. It's that
> simple.
How do you deal with the false-positives, legit servers that are blocked
by this configuration?
--
Dave Funk University of Iowa
College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include
Better is not better, 'standard' is better. B{
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
--On Sunday, August 26, 2007 5:31 PM -0700 Marc Perkel <[EMAIL PROTECTED]> wrote: If you have one MX and you create a fake low MX and a fake high MX (or many fake high MX) about 75% to 95% of your spam goes away. It's that simple. I can do better. If I unplug my network cable, 100% of my spam goes away! :D
Re: sa-update stuck in July
Hmm, it seems there perhaps is little hope of updates for the current
release of spamassassin, as they changed the format:
< require_version @@VERSION@@
---
> require_version 3.003000
And as you mention, one would be crazy to download 3.003000.
So what might you recommend one do if one wants to have their spamassassin
keep abreast of current spam patterns?
(The above diff made with:)
set -ue 556472 569778
for v
do
mkdir /tmp/$v
cd /tmp/$v
wget http://daryl.dostech.ca/sa-update/asf/$v.tar.gz
tar xf $v.tar.gz
rm $v.tar.gz
done
diff -r /tmp/{$1,$2}
--
View this message in context:
http://www.nabble.com/sa-update-doesn%27t-connect-to-updates.spamassassin.org-tf4301586.html#a12340520
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: How to query the AWL at an earlier stage for Short Circuit?
OliverScott wrote: > I am playing with the Short Circuit plugin to speed up scanning (by skipping > Network Tests on obviously good emails) and wanted to be able to query the > AWL as part of this as I don't want to Short Circuit on BAYES_00 alone. > > > I presume that this is because the AWL which normally runs at a priority of > 1000 can't be accessed at an earlier stage? > That's done because AFAIK, right now there's a single "query and update" operation, which both queries the AWL, and updates it with new score information all at once. And besides this unusual application, querying the AWL before all the rules are done being scored is useless, as you won't get the right results out of it. The score assigned by the AWL rule is a function of both the current pre-AWL score, and the history. If you check the AWL before all the rules are done, that "current score" value isn't going to be accurate. However, in your case, you're not trying to query the AWL for scoring purposes, merely determine if a given sender has been seen at all before. Which isn't really what the AWL was designed to do. > I still want the AWL to do its normal job once the other scoring has > finished, so don't want to make its priority less than 1000, but was hoping > that there was a way to query its information earlier in the SpamAssasssin > process. > > Any ideas? > Modify the AWL plugin code? You'd essentially want a stripped-down version of "check_from_in_auto_whitelist" which really only checks to see if the address exists in the DB or not, and doesn't do any score calculation/update.
Can't resolve domain to addresses at /usr...
When I run sa-update, I have recently started to get this error which terminates the update run: [17894] dbg: channel: attempting channel updates.spamassassin.org [17894] dbg: channel: update directory /var/lib/spamassassin/3.001007/updates_spamassassin_org [17894] dbg: channel: channel cf file /var/lib/spamassassin/3.001007/updates_spamassassin_org.cf [17894] dbg: channel: channel pre file /var/lib/spamassassin/3.001007/updates_spamassassin_org.pre [17894] dbg: channel: metadata version = 555165 can't resolve "wa9als.com" to address at /usr/lib/perl5/Net/DNS/Resolver/Base.pm line 751. I've looked at that line in Base.pm, but I have no idea what might be going on. Can someone help point me in the right direction? As they say, "It used to work." SpamAssassin v3.1.7 on Debian, recently upgraded from sarge to etch, but I don't know if that correlates with this problem or not. Thanks, and try to keep it simple. - John
Re: Posioned MX is a bad idea - Challenge
Kai Schaetzl wrote: Marc Perkel wrote on Sat, 25 Aug 2007 13:51:43 -0700: I'm using it on 1600 domains and I've eliminated all my spam bot spam. Yeah, yeah, Marc, we know that, you don't have to repeat it each and every week :-) Kai While you guy all talk about it - I've done it. It seems to me that if you ignore reality with your theories that I'm proving wrong you're not as likely to succeed as listening to someone who has done it. For all you out there who don't believe that I can do this I can prove it. Anyone want to put it to the test and see if what I'm saying isn't true then contact me and you can see it happen yourself. The condition is that you have to come back here and report the results. So - who wan's to prove me wrong?
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Kai Schaetzl wrote: Duane Hill wrote on Sat, 25 Aug 2007 22:29:50 + (UTC): What happens if the remote MX is within a private IP range? Should I accept that message, knowing fully, the recipient would never be able to respond? This feature looks fine on first glance, but on second I think this is dangerous if it gets applied to all MX positions. For instance the two MX setup where one machine is behind a firewall and a gateway machine is first MX and forwards to the machine behind the firewall. This is an accepted setup. Couldn't I achieve the same thing without a firewall? The first MX gets another IP from a private range and the second is on private only. So, it's not reachable from outside, but the first MX can forward to it. "backup MXs (that don't exist)" doesn't mean a private range. You simply set it to an IP that doesn't have SMTP or one that points to nirvana, but still a valid public IP address. I don't use that technique and don't think I will need to use it in the near future, but I can't see anything bad in it, sorry. As John says only spammers or broken MTAs should have a problem with that. I also agree on SAV with John, it's almost as worse as challenge-response mechanisms. Kai If you have one MX and you create a fake low MX and a fake high MX (or many fake high MX) about 75% to 95% of your spam goes away. It's that simple.
How to query the AWL at an earlier stage for Short Circuit?
I am playing with the Short Circuit plugin to speed up scanning (by skipping Network Tests on obviously good emails) and wanted to be able to query the AWL as part of this as I don't want to Short Circuit on BAYES_00 alone. i.e. Short Circuit as HAM if both BAYES_00 & AWL fire. I tried this: priority USER_IN_WHITELIST -1000 priority ALL_TRUSTED-950 priority BAYES_00 -400 shortcircuit USER_IN_WHITELIST on shortcircuit ALL_TRUSTEDon # Add a high priority rule to check if the sender is in the AWL header __MY_AWL eval:check_from_in_auto_whitelist() describe __MY_AWL Sender has been seen before. priority __MY_AWL-300 meta MY_HAM_SC (( BAYES_00 + __MY_AWL ) > 1) describe MY_HAM_SC Clearly not SPAM. priority MY_HAM_SC -200 tflags MY_HAM_SCnice score MY_HAM_SC -50 shortcircuit MY_HAM_SC on However this does not work as messages which get BAYES_00 and AWL, do not get Short Circuited... I presume that this is because the AWL which normally runs at a priority of 1000 can't be accessed at an earlier stage? I still want the AWL to do its normal job once the other scoring has finished, so don't want to make its priority less than 1000, but was hoping that there was a way to query its information earlier in the SpamAssasssin process. Any ideas? -- View this message in context: http://www.nabble.com/How-to-query-the-AWL-at-an-earlier-stage-for-Short-Circuit--tf4332696.html#a12339661 Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Posioned MX is a bad idea
On 8/26/2007 11:36 PM, John D. Hardin wrote: On Sun, 26 Aug 2007, Nikolay Shopik wrote: Just parse received headers in attached message in backscatter. You can easily see what this message sent not by your server and you can reject such backscatter, because you never sent such messages. Not true any longer. The joe job I've been suffering from the last month has forged Received: headers that makes the spam appear to have been sent from my MX to the bot that actually originated it. After all, how hard is it to look up the MX for the domain you're forging as the sender? I you want to filter you'd need to keep a history of all the Message-ID values your MTA had processed and compare to that. And what else, you can announce your MTA not as it named in DNS. So you announce your system as mta.example.com but all DNS records claims what its mx.example.com. MX RR = mx.example.com -> 1.2.3.4 CNAME RR = mta.example.com -> mx.example.com (just for safety)
Re: Posioned MX is a bad idea
On 8/26/2007 11:36 PM, John D. Hardin wrote: On Sun, 26 Aug 2007, Nikolay Shopik wrote: Just parse received headers in attached message in backscatter. You can easily see what this message sent not by your server and you can reject such backscatter, because you never sent such messages. Not true any longer. The joe job I've been suffering from the last month has forged Received: headers that makes the spam appear to have been sent from my MX to the bot that actually originated it. After all, how hard is it to look up the MX for the domain you're forging as the sender? I you want to filter you'd need to keep a history of all the Message-ID values your MTA had processed and compare to that. Yeah Message-ID is works too. Lookup for ip address as well in received header.
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
--On Sunday, August 26, 2007 11:31 AM +0200 Kai Schaetzl <[EMAIL PROTECTED]> wrote: For instance the two MX setup where one machine is behind a firewall and a gateway machine is first MX and forwards to the machine behind the firewall. This is an accepted setup. Couldn't I achieve the same thing without a firewall? The first MX gets another IP from a private range and the second is on private only. So, it's not reachable from outside, but the first MX can forward to it. Publishing a private address in a public MX record can lose mail. If the outside sender is using the same private address for his own mail server, then that server will either see a routing loop (since it's being told by MX that it's responsible for that mail) or it will reject the mail because it's not configured to forward or deliver for that domain.
Re: Bouncing emails from certain countries
On Sat, 25 Aug 2007 [EMAIL PROTECTED] wrote: > And no wonder you don't seem to get many new customers from > elsewhere anyway, I bet. They can't get a word in edgewise. But > never mind. You won't see this message either. Whoa. Is anybody else getting a sense of Deja Vu here? -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174 pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- USMC Rules of Gunfighting #20: The faster you finish the fight, the less shot you will get. --- 2 days until Exercise Your Rights day
Re: Posioned MX is a bad idea
On Sun, 26 Aug 2007, Nikolay Shopik wrote: > Just parse received headers in attached message in backscatter. > You can easily see what this message sent not by your server and > you can reject such backscatter, because you never sent such > messages. Not true any longer. The joe job I've been suffering from the last month has forged Received: headers that makes the spam appear to have been sent from my MX to the bot that actually originated it. After all, how hard is it to look up the MX for the domain you're forging as the sender? I you want to filter you'd need to keep a history of all the Message-ID values your MTA had processed and compare to that. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174 pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- USMC Rules of Gunfighting #20: The faster you finish the fight, the less shot you will get. --- 2 days until Exercise Your Rights day
Re: report_header and use_terse_report errors
How can I check it then? 1.How does mail get to spamd? 2.How does mail get from spamd to the users? Loren
Re: report_header and use_terse_report errors
Hello, > That example content will NOT happen from the configuration you quoted. > In fact, that example CANNOT be made to happen in SA without > considerable effort. Period. > > Something other than SpamAssassin is generating your headers. How can I check it then? # ps ax |grep spamd 70930 ?? Ss 1:01.50 /usr/local/bin/spamd -c -Q -d -r /var/run/spamd/spamd 81093 ?? I 0:04.48 spamd child (perl5.8.8) 84208 ?? I 0:09.40 spamd child (perl5.8.8) # ps ax |grep spamc 81629 p0 S+ 0:00.00 grep spamc # spamd -V SpamAssassin Server version 3.2.3 running on Perl 5.8.8 with SSL support (IO::Socket::SSL 1.07) with zlib support (Compress::Zlib 2.004) Many thanks in advance! -- Zbigniew Szalbot www.slowo.pl www.lcwords.com
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Kai Schaetzl wrote: Michael Scheidell wrote on Sun, 26 Aug 2007 09:54:16 -0400: Look for 'bogusmx' blacklist. criteria are different. Indeed. reject != score. Moreover, I wouldn't put - MX => private IP - MX = "*.mx.*" - MX = CNAME or MX=IP at the same level. anyway, Michael has missed my first post in the thread (I said "google for bogusmx", which return rfci as the first link... ) BTW: please consider using a client that is not broken. Your client doesn't include threading information. That's what happens when using a proprietary intranet messaging system on the Open Internet (TM). It destroys "open" headers and inserts its own... I wonder if we need a meta rule - Subject has "Re:" - no In-Reply-To and References header ;-p
RE: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
> -Original Message- > From: Kai Schaetzl [mailto:[EMAIL PROTECTED] > Sent: Sunday, August 26, 2007 12:31 PM > To: users@spamassassin.apache.org > Subject: Re: Posioned MX is a bad idea [Was: Email forwarding > and RBL trouble] > > > Michael Scheidell wrote on Sun, 26 Aug 2007 09:54:16 -0400: > > > Look for 'bogusmx' blacklist. > > criteria are different. > > BTW: please consider using a client that is not broken. Your client > doesn't include threading information. > No, could you use a brain that isn't broken? _ This email has been scanned and certified safe by SpammerTrap(tm). For Information please see http://www.spammertrap.com _
Re: Bouncing emails from certain countries
DA> I used IP::Country::Fast to block everything except canada and usa... DA> I've only had to add one company to an allow list because they are in Italy... DA> I don't think its that bad of a solution, DA> depending on where your companies customers are located.. And no wonder you don't seem to get many new customers from elsewhere anyway, I bet. They can't get a word in edgewise. But never mind. You won't see this message either.
Re: Posioned MX is a bad idea
On 8/26/2007 4:57 AM, Rob McEwen wrote: Marc, Overall good answers... but about six months ago, one of my users was joe jobbed in "biblical proportions"... in this case, the spammer chose this one "real" address and that spammer must have either sent the bots this info, or pre-programmed the bots. When the spam run started, this particular user was then the "from" address in many spams sent from many different IPs and, as a result, he received hundreds of incoming outscatter per day (The vast majority of which were were blocked by my spam filter). The outscatter often showed the headers of the original spam and from that I was able to determine that this was originating from an army of bots... NOT merely one IP. Because the outscatter I saw was mail returned from that fraction of a percent of mail servers which are misconfigured, the actual spam run must have been in the 10s of thousands... or even millions per day. Combine this with the fact that I highly doubt that anyone else's implemenation of SAV would be as surgically targetted as yours, no matter how hard they try, and my mail server might have been brought to its knees had all the major ISPs used SAV at that time! It would be interesting if there were a central "clearinghouse" server which could do the SAV one time (with each new request not yet in the DB) and then cache the results for everyone else to do some kind of DNS query to this one server. But this is not feasible because if random aliases are used in the FROM address then the database for this server could grow unbelievably large to a point where it would be rendered useless. Also, this would also be a valuable resource for spammers to verify addresses in their own address lists! So... forget that idea! Rob McEwen PowerView Systems [EMAIL PROTECTED] Rob, Just parse received headers in attached message in backscatter. You can easily see what this message sent not by your server and you can reject such backscatter, because you never sent such messages.
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
On 8/26/2007 12:08 AM, John Rudd wrote: mouss wrote: Kai Schaetzl wrote: Rense Buijen wrote on Wed, 22 Aug 2007 16:43:19 +0200: I didn't know that a backup MX can lead to more trouble then having just one Unfortunately, backup MXes attract spammers :-(. You could at least add some more backup MXs (that don't exist) on top of that, that may help to reduce the influx on the real one. Using bogus MX records is a very bad idea. Google for bogusmx and for check_sender_mx_access. So, how exactly does "using bogus MX records" differ from "nolisting"? Because, the latter does seem to generally be thought of as a rather good anti-spam technique (it only catches spammers and a few very odd non-RFC compliant MTAs that don't check all MX records). If you have a one or more valid MX records, and one or more non-responsive MX records, then only non-RFC complaint MTAs will have a problem with that. We shouldn't care about the cases which break non-RFC compliant MTAs, as they're only used by morons. Further, how does check_sender_mx_access differ from Sender Address Verification (SAV)? (where SAV is an INCREDIBLY bad idea, and a blight upon the internet) (meaning: if check_sender_mx_access is just the postfix name for SAV, then we not only shouldn't avoid techniques that break check_sender_mx_access, we should all openly adopt techniques that break check_sender_mx_access as a means to further remove the SAV blight from the internet) Why you so against SAV? I don't see big problem with that, just because it's not in RFC doesn't mean it shouldn't be there. SMTP need some kind verification of senders for decades already.
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Michael Scheidell wrote on Sun, 26 Aug 2007 09:54:16 -0400: > Look for 'bogusmx' blacklist. criteria are different. BTW: please consider using a client that is not broken. Your client doesn't include threading information. Kai -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
> On Sat, 25 Aug 2007, Dave Pooser wrote: >> >> So do you run your servers with VRFY enabled? > > Yes. If you are verifying addresses at RCPT time, which you must to avoid > spam blowback, then there's no point disabling VRFY. Except that I can verify addresses after checking blacklists, RDNS and other checks to make dictionary attacks harder on the spammers. It may be possible to put ACLs on VRFY in Exim, but I haven't looked into it. My larger point: If another server operator has disabled VRFY on his server, by what right do I attempt to circumvent his policy decision by using sender address verification? -- Dave Pooser Cat-Herder-in-Chief, Pooserville.com "In our family, happy usually involves gunfire and at least two patrol cars showing up." --SomethingPositive.net
RE: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
> -Original Message- > From: mouss [mailto:[EMAIL PROTECTED] > Sent: Saturday, August 25, 2007 3:52 PM > To: users@spamassassin.apache.org > Subject: Re: Posioned MX is a bad idea [Was: Email forwarding > and RBL trouble] > > sure, which may lead to the creation of a dedicated blacklist. Which is called www.rfc-ignorant.org. And already has SA rule and score. Look for 'bogusmx' blacklist. _ This email has been scanned and certified safe by SpammerTrap(tm). For Information please see http://www.spammertrap.com _
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Kai Schaetzl wrote: Duane Hill wrote on Sat, 25 Aug 2007 22:29:50 + (UTC): What happens if the remote MX is within a private IP range? Should I accept that message, knowing fully, the recipient would never be able to respond? This feature looks fine on first glance, but on second I think this is dangerous if it gets applied to all MX positions. For instance the two MX setup where one machine is behind a firewall and a gateway machine is first MX and forwards to the machine behind the firewall. This is an accepted setup. Couldn't I achieve the same thing without a firewall? The first MX gets another IP from a private range and the second is on private only. So, it's not reachable from outside, but the first MX can forward to it. - There is no need for MX in local networks. most MTAs support explicit transport/routing configurations. - you can still use multiple DNS servers (or views) - you can exclude your own domains from whatever check you want Allowing an outsider to access one of your private boxes he was not supposed to access is generally considered a hole. consider this: - one of your users is running an smtp server on his box, IP=10.1.2.3 - an outsider buys a domain, and sets his MX to 10.1.2.3 - he sends you mail using that domain in the sender address - for some reason, the mail gets a reply (real reply by luser, out of quota/disk, system error, vacation, MUA confirmation ... whatever). your MTA will send the reply to 10.1.2.3 so the outsider has managed to reach the smtp server on 10.1.2.3. That smtp server may be an unprotected/unpatched/misconfigured exchange/whatever, a trojan, ... Yes, you can track all internal smtp servers, all MUAs that send confirmations/..., all auto-responders, ... all traojans, ... but why would you accept mail from an unkown domain claiming to have an MX that is unreachable from the public network? More generally, except under known circumstances, there is no reason to accept mail with a sender address that is unreachable. If they don't wanna be reached, they should use the empty address (<>). Here is a domain used as sender in a recent spam: $ host -t mx yheweathernetwork.com yheweathernetwork.com mail is handled by 0 *.mx.*. "backup MXs (that don't exist)" doesn't mean a private range. You simply set it to an IP that doesn't have SMTP or one that points to nirvana, but still a valid public IP address. This is not what I call a "bogus MX". but this may still be detected after some time (well, it will be detected that you have an MX that did not work over a long period of time). not sure whether spammers will list these and avoid them. You may want to randomly "ignore" clients (send a TCP RST to be nice to legitimate MTAs). But if you use a real MTA, you should also "whitelist" known good clients. I don't use that technique and don't think I will need to use it in the near future, but I can't see anything bad in it, sorry. As John says only spammers or broken MTAs should have a problem with that. I also agree on SAV with John, it's almost as worse as challenge-response mechanisms. Kai
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
John Rudd wrote: mouss wrote: Kai Schaetzl wrote: Rense Buijen wrote on Wed, 22 Aug 2007 16:43:19 +0200: I didn't know that a backup MX can lead to more trouble then having just one Unfortunately, backup MXes attract spammers :-(. You could at least add some more backup MXs (that don't exist) on top of that, that may help to reduce the influx on the real one. Using bogus MX records is a very bad idea. Google for bogusmx and for check_sender_mx_access. So, how exactly does "using bogus MX records" differ from "nolisting"? Because if you set the MX to point to 10.1.2.3 and if I don't reject your mail, then replies may go to a private MTA in my network. Because, the latter does seem to generally be thought of as a rather good anti-spam technique (it only catches spammers and a few very odd non-RFC compliant MTAs that don't check all MX records). It causes an additional connection attempts. so it's not completely "safe". if you can redirect "known good" clients to a real MTA (with a NAT redirect for example), then it's better. If you have a one or more valid MX records, and one or more non-responsive MX records, then only non-RFC complaint MTAs will have a problem with that. We shouldn't care about the cases which break non-RFC compliant MTAs, as they're only used by morons. By bogus MX, I don't mean a non-responsive MX. I really mean the record is bogus and can be seen without any SMTP connection. An MX that points to private IP or unallocated IP space is such one, and I don't ignore this, because it indicates one of the following - the site does not want to receive mail (there are better ways, but...). if the address is used, then it is probably a forgery. - a miscreant (spammer, cracker, ...) is trying to do something nasty. I don't need to know what he is trying to achieve. - a DNS misconfiguration. but this is a big one, so the site may have other problems. better to block him so that he does little harm. - a stupid registrar giving silly replies for parked domains. If you get a message claiming to be from <[EMAIL PROTECTED]>, you can reject it now. no point to check the content. Further, how does check_sender_mx_access differ from Sender Address Verification (SAV)? (where SAV is an INCREDIBLY bad idea, and a blight upon the internet) check_sender_mx_access compares the MX with a list of records you put in a file. for each record, you can decide to reject, tempfail, greylist, or whatever. This involves no smtp probe. (meaning: if check_sender_mx_access is just the postfix name for SAV, then we not only shouldn't avoid techniques that break check_sender_mx_access, we should all openly adopt techniques that break check_sender_mx_access as a means to further remove the SAV blight from the internet) under postfix, SAV is reject_unverified_sender. but this is not recommended as you say.
Re: Bayes DB file locations help
got2go wrote: > Hello all, > > I am trying to get Bayes working on CentoS 4.3 with Postfix, MailScanner, > IMP (with Spam reporting feature). > Check your /etc/mail/spamassassin/mailscanner.cf. (if you don't have one, your MailScanner is ancient) If you've got this line: bayes_path /var/spool/MailScanner/spamassassin/bayes Then that's what you're using for everything. If it's commented out, then MailScanner should be using /root/.spamassassin/. IMP might be using /var/www If you have no /etc/mail/spamassassin/mailscanner.cf, and a REALLY old mailscanner, check your spam.assassin.prefs.conf, for a bayes_path. If that's the case then: locally logged in as root is using /root/.spamassassin IMP might be using /var/www/ MailScanner is probably using spam.assassin.prefs.conf, which probably has the /var/spool/MailScanner bayes_path.
Re: Combine whitelist_to and whitelist_from
[EMAIL PROTECTED] a écrit : Matus UHLAR - fantomas a écrit : On 24.08.07 13:46, [EMAIL PROTECTED] wrote: imagin a newsletters or order mail sent by an seller website with the from address : [EMAIL PROTECTED] I have in my mail system an address like [EMAIL PROTECTED] With that, I can trace where my emails are sent in order to trace spam and site that sell my email. So, only [EMAIL PROTECTED] can send me mail on [EMAIL PROTECTED] (theorical) The problem is that on a mailing list, the [EMAIL PROTECTED] is used by spamer and they send me spam on [EMAIL PROTECTED] Is it possible to combine whitelist_from and whitelist_to in order to tag "no spam" mails with 2 conditions : whitelist_from [EMAIL PROTECTED] AND whitelist_to [EMAIL PROTECTED] OK So, if a spammer [EMAIL PROTECTED] send me a mail on [EMAIL PROTECTED], the second conditions will be OK but not the first and spamassassin will considere it as spam ! the from address can be as easily faked as the to address. I have seen on this mailing list many reports from users whitelisting their own address somehow and thus getting false positives. What you are searching for, is whitelist_from_rcvd which combined from address with address of mailserver the mail was received from, or better, whitelist_auth, if the outgoing domain supports SPF (sellermail.com does not...) -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; 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. Your mouse has moved. Windows NT will now restart for changes to take to take effect. [OK] Hummm, thanks, I saw that and try but severals website send for example : [EMAIL PROTECTED] send a mail to me on [EMAIL PROTECTED] from the provider.com or webhosted.com that are internet or server hosted provider. The probleme in this case is that type of seller can change their sender server. Meanwhile, it won't change the from or or to address (rarely). So the from and to combinated are best that test on headers rcvd (for me) Yves
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Marc Perkel wrote on Sat, 25 Aug 2007 13:51:43 -0700: > I'm using it on 1600 domains and I've eliminated all > my spam bot spam. Yeah, yeah, Marc, we know that, you don't have to repeat it each and every week :-) Kai -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Marc Perkel wrote on Sat, 25 Aug 2007 15:33:46 -0700: > You have to do SAV right. I It doesn't matter what you do to reduce the load of SAV, this doesn't eliminate the basic problem with SAV at all. > And - more importantly - spammers don't use my donains to spam others > because my servers are SAV friendly and spammer prefer using domains > that either pass everything. I doubt this matters at all. I have a client whose domain got so heavily joe-jobbed years ago that we had to take his domain from dns for years. Trying after two or three years of non-resolution if it is usable again still drove in several ten-thousand non-delivery notices within a day. In other words: spammers don't care. Kai -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
On Sat, 25 Aug 2007, Dave Pooser wrote: > > So do you run your servers with VRFY enabled? Yes. If you are verifying addresses at RCPT time, which you must to avoid spam blowback, then there's no point disabling VRFY. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Duane Hill wrote on Sat, 25 Aug 2007 22:29:50 + (UTC): > What happens if the remote MX is within a private IP range? Should I > accept that message, knowing fully, the recipient would never be able to > respond? This feature looks fine on first glance, but on second I think this is dangerous if it gets applied to all MX positions. For instance the two MX setup where one machine is behind a firewall and a gateway machine is first MX and forwards to the machine behind the firewall. This is an accepted setup. Couldn't I achieve the same thing without a firewall? The first MX gets another IP from a private range and the second is on private only. So, it's not reachable from outside, but the first MX can forward to it. "backup MXs (that don't exist)" doesn't mean a private range. You simply set it to an IP that doesn't have SMTP or one that points to nirvana, but still a valid public IP address. I don't use that technique and don't think I will need to use it in the near future, but I can't see anything bad in it, sorry. As John says only spammers or broken MTAs should have a problem with that. I also agree on SAV with John, it's almost as worse as challenge-response mechanisms. Kai -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
Bayes DB file locations help
Hello all, I am trying to get Bayes working on CentoS 4.3 with Postfix, MailScanner, IMP (with Spam reporting feature). I cant seem to figure out how the make one central location for the bayes database files. It seems they are in different places, all being utilized at some point. [EMAIL PROTECTED] ~]# locate bayes /usr/share/spamassassin/23_bayes.cf /etc/MailScanner/bayes /root/.spamassassin/bayes_toks /root/.spamassassin/bayes_journal /root/.spamassassin/bayes /root/.spamassassin/bayes/bayes_toks /root/.spamassassin/bayes/bayes_journal /root/.spamassassin/bayes/bayes_seen /root/.spamassassin/bayes_seen /root/.spamassassin/bayes.mutex /var/www/.spamassassin/bayes_toks /var/www/.spamassassin/bayes_seen /var/www/.spamassassin/bayes.mutex /var/spool/MailScanner/spamassassin/bayes_toks /var/spool/MailScanner/spamassassin/bayes_journal /var/spool/MailScanner/spamassassin/bayes_seen /var/spool/MailScanner/spamassassin/bayes.mutex Can anybody shed some light into this ? Thanks in advance! -- View this message in context: http://www.nabble.com/Bayes-DB-file-locations-help-tf4330318.html#a12332781 Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
