> Just ensure you don't block the secondary and you should be OK - > tackling the junk by other means. (You could set up a third mx > pointing to your primary - that way you get the bots that go for the > highest mx while still giving genuine mtas a backup.)
Another trick which allows to obtain an effect similar to the one achieved with the greylisting (delaying) is to setup the so called "MX sandwich"; the idea is more or less the following; you will need to disable the greylisting and setup four DNS records which will look more or less as follows @ IN MX 10 invalid.example.com @ IN MX 20 mx1.example.com @ IN MX 30 mx2.example.com @ IN MX 40 fake.example.com where "invalid.example.com" will point to an IP on which there NO SMTP service at all, so the connection attempt will timeout; at this point, a regular, good SMTP server would retry connecting to the MX 20 where your ASSP is listening; in case the ASSP will then be offline for whatever reason, the "good SMTP" will move on to MX 30 where your ISP backup MX will get the email A bot, on the other hand, may try connecting to the "higher" MX, that is MX 40; on that IP you'll setup a "fake" mailserver which will always answer to ANY connection with a "4xx temporary failure" so no email will be ever accepted from that "fake" MX; now let's see what will happen to a bot connecting to MX 10; it will attempt to connect on port 25, the connection will time out (port filtered) so the bot will (they usually do, observed that) take the shortest path and jump straight to the MX 40 ... where it will get back the 4xx as seen above the result would be a tarpit to the bot due to the first "connection timeout" wait and a reject when it will go straight to the bottom MX :) on the other hand, if, by chance (Murphy is always there <g>) all the MX except the invalid and the fake one should be offline a "good SMTP" would try the MX 10 and fail, try the MX 20..30 and fail again, try MX 40, get back a "tempfail" and requeue the email for later delivery, so the email would then be delayed but won't be lost The whole setup may be further expanded by adding other MX records mixing them as needed or even by setting up the DNS so that the valid MX will be rotated from time to time Again, the above is just a "hack", but afaik there were/are some "big names" (not kidding) using it for their MX infrastucture; the whole idea has pros and cons against the regular greylisting; for example, if a sender uses a pool of sending SMTP servers the greylist may cause a message to be rejected if the attempts come from different IP addresses, on the other hand, using the "sandwich" this won't be an issue on the other hand, the greylisting can't be bypassed while the "sandwich" trick may be learned by the spammers and may be bypassed (although, rotating the MX hosts as I wrote above could help avoiding such an issue) ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Assp-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/assp-user
