* On 23/06/06 17:36 +0100, Chris Lightfoot wrote:
| On Fri, Jun 23, 2006 at 07:21:07PM +0300, Odhiambo G. Washington wrote:
| > * On 22/06/06 19:10 +0100, Chris Lightfoot wrote:
| > | On Thu, Jun 22, 2006 at 08:37:01PM +0300, Odhiambo G. Washington wrote:
| > | > Hello pple,
| > | >
| > | > I have have a server which is where all deliveries are done. This server
| > | > is not advertised "anymore" in DNS, but spammers are still sending to
| > | > it in defiance of my TTL from DNS configuration.
| > | > I know that most of my clients who use this server are located within
| > | > my country (damn Kenya!).
| > | >
| > | > I now want to block all connections to this server which originate
| > | > outside my country.
| > | >
| > | > I have hit google hard and found two projects that were geared towards
| > | > introducing the complexities (yes) of using GeoIP within Exim.
| > | >
| > | > http://botanicus.net/dw/exim-python/exim-4.60py1.html
| > | > http://pookey.co.uk/exim-geoip.xml
| > | >
| > | > One seems recent enough, but both seem like they are un-maintained.
| > | > I am running Exim 4.62 on all my servers.
| > | >
| > | > Is there anyone out there using another variant of GeoIP blocking with
| > | > Exim that they'd be willing to share with the community (me ;))?
| > |
| > | this strikes me as a really bad idea, but as with many
| > | really bad ideas, it's trivial to implement in perl. grab
| > | the Geo::IP perl module, and then put
| > |
| > | use Geo::IP;
| > |
| > | sub get_country_code_from_ip ($) {
| > | my $ip = shift;
| > | our $geoip;
| > | $geoip ||= new Geo::IP(GEOIP_STANDARD);
| > | return $geoip->country_code_by_addr($ip);
| > | }
| > |
| > | in your startup perl module, then use,
| > |
| > | ${perl{get_country_code_from_ip}{$host_address}}
| > |
| > | to obtain the country code in a string expansion.
| >
| >
| > How bad an idea is it. Chris?
|
| three completely general issues -- firstly, be suspicious
| of any IP-address-based anti-spam scheme;
It's not critical on this box ;)
| secondly, IP-to-country data are notoriously inaccurate
I did not know about that angle of inclination ;)
| (do you want to have to deal with the support calls?);
Yes, we have some folks sitting here only waiting to take
calls, so it's not a problem, although I am also not sure
how many calls this will generate. I can rescind it if they
prove too much though.
| thirdly, this is a big database of stuff under somebody
| else's control, so if it produces the `wrong' answer
| fixing it is a problem.
Ah, who controls GeoIP? I need to hit the page again and
read further. I must admit I only thought about using it,
not who controls it, nor how! I'll take that seriously now.
| I don't think I fully understand the situation you've
| described, though -- you have some machine which is a
| message-submission SMTP server, which is no longer
| advertised in DNS, but which certain of your customers are
| still using (presumably having recorded its literal IP
| address)?
I can explain. The server used to be advertised as MX for hundreds
of domains I host. Then I decided to hide the box (DNS changes).
Instead I advertised another box, but which I configured to do
manual routing for these domains to the now "hidden" box.
Spammers, in their hundreds, are still connecting to this hidden
box despite a TTL of 24 hours. This is what I am grappling with.
Call it "playing with".
My customers still access the box either by NAME or by IP (for
the dumb cases), but even so, they only access it using a subdomain
of their own domains names, not by the FQDN of the box.
And my customers are mostly located in Kenya.
| What would be wrong with one of the following:
|
| - refuse all connections with an explanatory error
| message (``this machine is now out of service, change
| the SMTP server setting in your software to
| new.name.of.machine'');
At what level do I do that? I am asking this because my customers
still use the "hidden" box for their outgoing SMTP and also as their
POP3/IMAP server. I only want to keep out _anyone_ else who does
not have any auth credentials on this box.
| - forward traffic from the old to the new IP; or
There is a new IP (MX to be precise) which is where spammers and
"outsiders" (non-customers) should be connecting, according to my
new MX records for the domains hosted on the "hidden" box.
| - try to contact all the legitimate users based on the
| logged senders, then do the first.
They are not the problem here. They legitimately connect to the
hidden box. The subdomain (gw.THEIRDOMAIN.ext) is mapped to the
hidden box. What I want is to reduce the processing consequent
upon spammer transaction, because again, I have disabled spam
filtering on the hidden box, instead doing it on the new MX. That
new MX is listed as the "highest priority", so everyone delivering
mail by MX should be connecting to it.
| But I don't understand why this is a spam problem? Does
| the machine accept both outgoing (submission) connections
| from your customers and incoming (delivery) connections
| from the spammers?
Yes, but it should not be handling the later.
| If so, and if the machine is no longer listed in DNS as an
| incoming relay, why not just use an ACL to prohibit any relaying
| from external IPs?
All my customers are not in the same IP class. Those from outside
my IP assignment use ASMTP when sending out mail via this box.
| I've clearly missed something here, since I don't understand
| what IP-to-country mapping has to do with it.
Yes you do. If I was hosting your domain and offering you e-mail
services, you'd have an account (they are all virtual, in MySQL)
and you'd be free to use the box as your SMTP server, via ASMTP
from anywhere, as well it will be your POP3/IMAP server. Your
gw.ex-parrot.com would be pointing to this box! However, MX-wise,
there will be no mention of this box in the zone file for ex-parrot.com,
if you allow me to use that familiar example.
Here is a typical zone file for a domain being hosted on the "hidden"
server:
-----------------------------8<-----------------------------------------
$TTL 86400
@ IN SOA ns1.wananchi.com. hostmaster.wananchi.com. (
2006062301 ; Serial
8H ; Refresh
2H ; Retry
1W ; Expire
1D) ; Minimum
@ IN MX 5 genie.wananchi.com.
IN MX 10 mail.wananchi.com.
IN MX 20 longonot.wananchi.com.
IN NS ns2.wananchi.com.
IN NS bak.wananchi.com.
IN A 62.8.64.6
webmail IN A 62.8.64.11
gw IN A 62.8.64.11
pop IN CNAME gw
www IN A 62.8.64.6
-------------------------------8<-----------------------------------------
If this was the zone file for ex-parrot.com, you will use
gw.ex-parrot.com as your SMTP server (in OutHouse) as well as your
POP3/IMAP server. Anyone "out there" sending mail to you should be
connecting to, obviously, the highest priority MX.
I want to stop them from ever getting to the "gw" as it's not one of
the things they should be knowing about when sending mail. You
understand now? ;)
cheers
- wash
+----------------------------------+-----------------------------------------+
Odhiambo Washington . WANANCHI ONLINE LTD (Nairobi, KE) |
wash () WANANCHI ! com . 1ere Etage, Loita Hse, Loita St., |
GSM: (+254) 722 743 223 . # 10286, 00100 NAIROBI |
GSM: (+254) 733 744 121 . (+254) 020 313 985 - 9 |
+---------------------------------+------------------------------------------+
"Oh My God! They killed init! You Bastards!"
--from a /. post
