Re: fake MX records
On 8/15/07, Wil Hatfield - HyperConX <[EMAIL PROTECTED]> wrote: > > > > This is the biggest problem with "fake" MX records for me. If your > > primary MX is not available, you will simply lose mail from some > > senders. It's entirely their "fault" for violating the RFCs but the > > mail is still lost, and it isn't easy to explain whats going on to > > your users/customers. Greylisting gives me about the same effect but > > it works with a bigger percentage of borken servers and I can easily > > exclude broken mailservers if needed. > > > > Aaron, so what greylisting techniques are working best for you? > > Wil Hatfield > > I use SQLgrey (http://sqlgrey.sourceforge.net/) with a backend mysql server shared between all MX nodes. SQLgrey works very well and has many smart features beyond basic greylisting that help reduce problems. By sharing the database, you gain some coherence which SQLgrey takes advantage of well. I had tried some other greylisting daemons in the past and couldn't deal with the support load they created, but I've been very pleased with this setup for some months now. With a couple RBLs, greylisting, and the UCE checks built in to Postfix, I can drop about 80% of mail on a good day with very few complaints. For some domains it's much higher, I have a couple that I reject over 99% of their mail and they love it :) When I try to get more aggressive it generally increases support calls, so I let SA take care of the rest. -Aaron > >
RE: fake MX records
> > This is the biggest problem with "fake" MX records for me. If your > primary MX is not available, you will simply lose mail from some > senders. It's entirely their "fault" for violating the RFCs but the > mail is still lost, and it isn't easy to explain whats going on to > your users/customers. Greylisting gives me about the same effect but > it works with a bigger percentage of borken servers and I can easily > exclude broken mailservers if needed. > Aaron, so what greylisting techniques are working best for you? Wil Hatfield
Re: fake MX records
On 8/15/2007 11:46 AM, Marc Perkel wrote: Daryl C. W. O'Shea wrote: On 8/14/2007 5:52 PM, Marc Perkel wrote: Kai Schaetzl wrote: Marc Perkel wrote on Tue, 14 Aug 2007 07:13:16 -0700: I'm using it on 1600 domains and it definitely works. I get not bot spam at all. I doubt that this is because you have a fake low MX. Kai So what do you attribute my success in getting rid of all bot spam to? Perhaps to the other "hundreds or tricks" that you've repeatedly claimed you use to block 99% of spam before it gets to SpamAssassin? Maybe I have a better idea about what's working on my servers than you do. Having fake high and low MX records will get rid of almost all of your bot spam. It's that easy. Maybe, if you weren't just trying to troll, you wouldn't ask for what others "attribute your success to" and then get all pissy when they respond. Regardless, if you really believe that you never fail to receive mail from others attempting to send mail to your customers you're (i) lying to yourself or simply lack understanding of the reality of the MTA landscape and (ii) are doing your customers a huge disservice -- more of a disservice than if you still used a "fake MX" but at least realized the reality of the consequences that you continuously deny. Daryl
Re: fake MX records
John D. Hardin wrote: On Wed, 15 Aug 2007, Richard Frovarp wrote: Michael Scheidell wrote: Yes, and some systems might not ever send you email (they violate RFC's) We've had one issue with this. ... There was on weird mailer that is being used that doesn't try other MXs. We were able to get past this by opening up the firewall to this small business to accept their mail. Just for the record, what MTA were they using that behaved that way? Workgroup Mail by Softalk
Re: fake MX records
On Wed, 15 Aug 2007, Richard Frovarp wrote: > Michael Scheidell wrote: > > > Yes, and some systems might not ever send you email (they violate > > RFC's) > > We've had one issue with this. ... There was on weird mailer that > is being used that doesn't try other MXs. We were able to get past > this by opening up the firewall to this small business to accept > their mail. Just for the record, what MTA were they using that behaved that way? -- 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 --- Users mistake widespread adoption of Microsoft Office as the development of a standard document format. --- Today: The 62nd anniversary of the end of World War II
Re: fake MX records
On 15 Aug 2007, Marc Perkel uttered the following: > I'm doing it and I'm not losing email from any senders. How can you possibly tell? You mean `none of the senders who I may have lost email from have noticed it and complained, or at least none have been able to get through to me to complain'. That's all you can ever say.
Re: fake MX records
Michael Scheidell wrote: -Original Message- From: ram [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 14, 2007 6:07 AM To: users@spamassassin.apache.org Subject: fake MX records http://wiki.apache.org/spamassassin/OtherTricksthis page mentions setting up fake MXes Is this method relevant today too with a lot of spam being relayed through proper smtp channels The page says the primary MX should not be accepting connections at all. Has anyone else tried this , will this cause delay in my mail Yes, and some systems might not ever send you email (they violate RFC's) We've had one issue with this. Our primary MX is firewalled off so that it only accepts mail from our large networks and therefor local mail doesn't have to compete with spam. There was on weird mailer that is being used that doesn't try other MXs. We were able to get past this by opening up the firewall to this small business to accept their mail.
Re: fake MX records
Aaron Wolfe wrote: On 8/14/07, Michael Scheidell <[EMAIL PROTECTED]> wrote: -Original Message- From: ram [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 14, 2007 6:07 AM To: users@spamassassin.apache.org Subject: fake MX records http://wiki.apache.org/spamassassin/OtherTricksthis page mentions setting up fake MXes Is this method relevant today too with a lot of spam being relayed through proper smtp channels The page says the primary MX should not be accepting connections at all. Has anyone else tried this , will this cause delay in my mail Yes, and some systems might not ever send you email (they violate RFC's) This is the biggest problem with "fake" MX records for me. If your primary MX is not available, you will simply lose mail from some senders. It's entirely their "fault" for violating the RFCs but the mail is still lost, and it isn't easy to explain whats going on to your users/customers. Greylisting gives me about the same effect but it works with a bigger percentage of borken servers and I can easily exclude broken mailservers if needed. -Aaron I'm doing it and I'm not losing email from any senders.
Re: fake MX records
Daryl C. W. O'Shea wrote: On 8/14/2007 5:52 PM, Marc Perkel wrote: Kai Schaetzl wrote: Marc Perkel wrote on Tue, 14 Aug 2007 07:13:16 -0700: I'm using it on 1600 domains and it definitely works. I get not bot spam at all. I doubt that this is because you have a fake low MX. Kai So what do you attribute my success in getting rid of all bot spam to? Perhaps to the other "hundreds or tricks" that you've repeatedly claimed you use to block 99% of spam before it gets to SpamAssassin? Maybe I have a better idea about what's working on my servers than you do. Having fake high and low MX records will get rid of almost all of your bot spam. It's that easy.
Re: fake MX records
Aaron Wolfe wrote: On 8/14/07, Michael Scheidell <[EMAIL PROTECTED]> wrote: -Original Message- From: ram [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 14, 2007 6:07 AM To: users@spamassassin.apache.org Subject: fake MX records http://wiki.apache.org/spamassassin/OtherTricksthis page mentions setting up fake MXes Is this method relevant today too with a lot of spam being relayed through proper smtp channels The page says the primary MX should not be accepting connections at all. Has anyone else tried this , will this cause delay in my mail Yes, and some systems might not ever send you email (they violate RFC's) This is the biggest problem with "fake" MX records for me. If your primary MX is not available, you will simply lose mail from some senders. It's entirely their "fault" for violating the RFCs but the mail is still lost, and it isn't easy to explain whats going on to your users/customers. It's trivial to explain: Your correspondents have defective email servers run by idiots. Until they fire the idiots and get real email admins with real email servers, they'll have trouble sending you email. That doesn't mean they'll like the explanation, but the explanation itself is pretty easy and straight forward. That said, I'm not really a fan of "no-listing" either (no-listing being the name of the technique in question). Greylisting gives me about the same effect but it works with a bigger percentage of borken servers and I can easily exclude broken mailservers if needed. Greylisting also has problems. Some greylisting implementations also trigger bugs in some MTAs (IIRC, if you reject at the RCPT-TO stage, exchange may not retry that recipient ever), and depending on what you set the retry window to, your users may end up seeing message delays in the hours range (which some will vocally complain about as well).
Re: fake MX records
On 8/14/07, Michael Scheidell <[EMAIL PROTECTED]> wrote: > > > > -Original Message- > > From: ram [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, August 14, 2007 6:07 AM > > To: users@spamassassin.apache.org > > Subject: fake MX records > > > > > > http://wiki.apache.org/spamassassin/OtherTricksthis page mentions > > setting up fake MXes > > > > Is this method relevant today too with a lot of spam being > > relayed through proper smtp channels > > > > The page says the primary MX should not be accepting > > connections at all. Has anyone else tried this , will this > > cause delay in my mail > > Yes, and some systems might not ever send you email (they violate RFC's) This is the biggest problem with "fake" MX records for me. If your primary MX is not available, you will simply lose mail from some senders. It's entirely their "fault" for violating the RFCs but the mail is still lost, and it isn't easy to explain whats going on to your users/customers. Greylisting gives me about the same effect but it works with a bigger percentage of borken servers and I can easily exclude broken mailservers if needed. -Aaron
Re: fake MX records
Marc Perkel wrote on Tue, 14 Aug 2007 14:52:22 -0700: > So what do you attribute my success in getting rid of all bot spam to? As I don't know your setup this would be pure speculation. However, as *I* am not using fake MXs, but several other MTA techniques and see not much Botnet spam either I would suspect that it's rather the other techniques that cut it. On the other hand, I wonder how you can collect so much spam or spammer IPs (as you claim and I believe it) if no Botnet spam reaches you. Please, don't use HTML on mailing lists, thanks! Kai -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
Re: fake MX records
On 8/14/2007 5:52 PM, Marc Perkel wrote: Kai Schaetzl wrote: Marc Perkel wrote on Tue, 14 Aug 2007 07:13:16 -0700: I'm using it on 1600 domains and it definitely works. I get not bot spam at all. I doubt that this is because you have a fake low MX. Kai So what do you attribute my success in getting rid of all bot spam to? Perhaps to the other "hundreds or tricks" that you've repeatedly claimed you use to block 99% of spam before it gets to SpamAssassin?
Re: fake MX records
Kai Schaetzl wrote: Marc Perkel wrote on Tue, 14 Aug 2007 07:13:16 -0700: I'm using it on 1600 domains and it definitely works. I get not bot spam at all. I doubt that this is because you have a fake low MX. Kai So what do you attribute my success in getting rid of all bot spam to?
Re: fake MX records
Marc Perkel wrote on Tue, 14 Aug 2007 07:13:16 -0700: > I'm using it on 1600 domains and it definitely works. I get not bot spam > at all. I doubt that this is because you have a fake low MX. Kai -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
Re: fake MX records
Kshatriya wrote: On Tue, 14 Aug 2007, ram wrote: The page says the primary MX should not be accepting connections at all. Has anyone else tried this , will this cause delay in my mail It almost doesn't work anymore. Better try adaptive greylisting, with some whitelists so you don't notice too much of delays. K. I'm using it on 1600 domains and it definitely works. I get not bot spam at all. I didn't even know what PDF spam was untill I was it discussed here.
Re: fake MX records
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kshatriya schrieb: > On Tue, 14 Aug 2007, ram wrote: > >> The page says the primary MX should not be accepting connections at all. >> Has anyone else tried this , will this cause delay in my mail > > It almost doesn't work anymore. Better try adaptive greylisting, with > some whitelists so you don't notice too much of delays. > > K. > fake mx do work, but dont expect to much, as most of the bots learned to come again to defend greylisting , they also learned fake mx. you will have a delay with fake mx but its very small. In my case i was bombed with connects and fake mx reduced them about 10 percent , i think these are very old spam bot variants who still agressing against my very old three letter domain. I would say fake mx are nice to have , but its not a must have in antispam these days, I includedreject_unknown_reverse_client_hostname in my postfix ,this, it seems is very efficient , in my case,i noticed to block spam mail in early client stage. Also fail2ban does a good job with dictionary attacks, for sure you should have all other recommended antispam settings like reject_unknown_sender_domain etc including greylisting, policy_weight, spf, dkim in your mail server. - -- Mit freundlichen Gruessen Best Regards Robert Schetterer Germany/Bavaria/Munich -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGwa/jfGH2AvR16oERAsbJAJ9iRo0H+YesZN1+fjMXu3iqpL1wFQCdHlUZ 82eAcB03SfJP4j7xuh9NbiU= =mMcc -END PGP SIGNATURE-
Re: fake MX records
On Tue, 14 Aug 2007, ram wrote: The page says the primary MX should not be accepting connections at all. Has anyone else tried this , will this cause delay in my mail It almost doesn't work anymore. Better try adaptive greylisting, with some whitelists so you don't notice too much of delays. K.
RE: fake MX records
> -Original Message- > From: ram [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 14, 2007 6:07 AM > To: users@spamassassin.apache.org > Subject: fake MX records > > > http://wiki.apache.org/spamassassin/OtherTricksthis page mentions > setting up fake MXes > > Is this method relevant today too with a lot of spam being > relayed through proper smtp channels > > The page says the primary MX should not be accepting > connections at all. Has anyone else tried this , will this > cause delay in my mail Yes, and some systems might not ever send you email (they violate RFC's) Also, many spammers go for the SECONDARY mx first. _ This email has been scanned and certified safe by SpammerTrap(tm). For Information please see http://www.spammertrap.com _
fake MX records
http://wiki.apache.org/spamassassin/OtherTricksthis page mentions setting up fake MXes Is this method relevant today too with a lot of spam being relayed through proper smtp channels The page says the primary MX should not be accepting connections at all. Has anyone else tried this , will this cause delay in my mail Thanks Ram
