Re: [suse-security] Banning dynamic IPs (Was: *SPAM* Tuerkei in die EU)
El 2005-05-23 a las 12:27 +0200, Rainer Duffner escribió:
Carlos,
it's not about blocking dynamic ips sending mail (or surfing the web). Just dynamic ips sending mail without going through a mailserver that is not an MX!
Dana Hudes said just that, block all traffic: |> Your issue is permanent blocking. This is controversial. |> The idea has been to exert pressure on ISPs whose users complain. |> This is of limited success. the idea is that if dialup and dhcp (cable, |> dsl) users found they could not access major portions of the internet |> -- not just for e-mail but web browsing as well -- then they would be |> motivated to complain to their ISPs who would act more forcefully and |> quickly against spammers etc. . If somoene could get yahoo and hotmail |> and google to "sign on" to such a program then yes there would be a |> dramatic amount of complaints.
Normaly, it should go like this:
| customer with dyn.IP|------>|MX of provider/hoster/whoever|------>|my | MX|<-----|me myself via IMAP on dynamic IP|
(SMTP)................................(SMTP)
I myself do SMTP-AUTH to allow relaying.
OK, so I have my own mailserver - but if I didn't have that, I'd subscribe to some online mail-service that allowed me to relay through their MX via SMTP-AUTH.
The problem, or problems, are several. For one thing, the smtp relay servers my ISPs provide are not reliable: they may fail to send an email, and worse, they don't inform me of that, or they do several days late. But even if I use the relay, they have policies that impede my use of them seriously, like only accepting email with a "From" address of theirs. Therefore, I can not send all my email through only one relay server, or not at all for redirection accounts (like sourceforge). Unfortunately, Postfix transport file does not has rules to select which relay server to choose based on the FROM address, only on the TO part. I need that feature. I was told (thanks, Arjen) to try 'esmtp' (http://esmtp.sourceforge.net/) - I've downloaded it, waiting for compilation -but a comment I read makes me afraid that it will not work well with non permanent connections. Thus, I have no alternative (yet?) but to use Postfix for direct sending. In my opinion, the best solution would be a method to really identify who is sending, regardless of the type of IP he is using. A cryptographic signature, probably, for the "FROM" header, not the contents (signing the contents is a problem with domainkeys with lists like SuSE's) At least in Spain, with a court order, it is possible to identify the spammer with the IP, because there are listings correlating each IP and timestamp to the phone used, and thus, the person responsible.
Please don't cc to the SuSE-list.
Ein? You mean, email you direct, without a CC to the list? :-o I'll try, but I'm sure your server will reject my dynamic IP server. [...] Impossible, it rejected me: (host mail.** [*.*.*.26] said: 451 Dynamic IP Addresses See: http://www.dnsbl.sorbs.net/lookup.shtml?213.94.2.24 (in reply to RCPT TO command)) Thus, I resend to the list instead. Sorry. -- Saludos Carlos Robinson
I am not sure I understand what the issue here is? Subscribe your mail service to a range of RBL's. Don't use one, use many. If you ARE on a dynamic IP address, make sure your provider has a secure SMTP Auth relay server for you to use and tunnel ALL of your outbound through this smart host. Sure a few lines extra of configuration, but weeks at a time of lowered frustration. There are many stringent reasons for blocking mail, if you had to choose the RFC Ignorant RBL, you would be blocking ALL mail from Germany and South Africa (among others). Why? Becuae the whois services provided by their ccTLD's do not follow strictly the whois RFC. Whats that got to do with mail? Nothing. But there are people who use these lists. So make sure you keep your very own headache levels down by accepting the fact that the world we live in is NOT a nice place and that you have to take certain measures that others will be taking for granted.
Carlos E. R. schreef:
The problem, or problems, are several. For one thing, the smtp relay servers my ISPs provide are not reliable: they may fail to send an email, and worse, they don't inform me of that, or they do several days late.
The fact that they don't inform you immediately, is quite normal. Most MTA's are configured to try to deliver a message for a couple of days before reporting a delivery error. You don't want to be informed about every transient error in delivery.
But even if I use the relay, they have policies that impede my use of them seriously, like only accepting email with a "From" address of theirs.
Their servers, their rules.
Therefore, I can not send all my email through only one relay server, or not at all for redirection accounts (like sourceforge).
In that case, chances are that you need to configure these upstream hosts in your MUA, instead of your MTA. I'm sure KMail (which you appear to be using) has no problem with multiple upstream hosts. Why are you so determined to want to run your own MTA? The fact that you can't send e-mail with a sourceforge.net adress, is because the sourceforge.net SPF record doesn't approve that. Regardless of the ISP, you can't fix that. By sending these messages yourself, won't change that and likely will cause many rejects from systems that check SPF records.
Unfortunately, Postfix transport file does not has rules to select which relay server to choose based on the FROM address, only on the TO part. I need that feature.
The feature is there in Postfix since version 2.0 was released (sender_based_routing = yes), but the author recommends against using it. It will cause all kinds of nasty issues, for instance when the sender is not so clear (the null sender adress for NDN's).
I was told (thanks, Arjen) to try 'esmtp' (http://esmtp.sourceforge.net/) - I've downloaded it, waiting for compilation -but a comment I read makes me afraid that it will not work well with non permanent connections.
Do you mean you have a dialup (modem) connection? In that case you have no business running a mailserver. In all other cases, you're already having problems now, how much worse can it be?
Thus, I have no alternative (yet?) but to use Postfix for direct sending.
You still don't seem to understand that you're figthing an uphill battle. The problems you're suffering from right now will only increase, rather than decrease. ISP's are getting more strict in who is allowed to relay through their systems, who is allowed to use their domain names and from which systems these messages should be delivered. SPF is just one of the ways to enforce this and is being deployed now (by 'terra.es' for instance, although their (pretty lenient) SPF record will not allow to reject messages).
In my opinion, the best solution would be a method to really identify who is sending, regardless of the type of IP he is using. A cryptographic signature, probably, for the "FROM" header, not the contents (signing the contents is a problem with domainkeys with lists like SuSE's)
Good luck. Maybe in twenty years time, but for the foreseeable future I think we are pretty much stuck with the system as it is right now. Anything that requires massive changes in MUA's (like DomainKeys) is likely to take many years.
At least in Spain, with a court order, it is possible to identify the spammer with the IP, because there are listings correlating each IP and timestamp to the phone used, and thus, the person responsible.
This doesn't work on a global scale. As a non-resident I can't possibly get a court order and sue a spammer abroad. And as you already told, many ISP's are not that responsive when it comes to complaints. So while it may be technically and legally possible to find a spammer, practically it is of little use. Besides this, the main reason for not allowing residential customers (even on static IP's) to send e-mail directly is virusses, not spam (although some virusses act as a spamrelay, so the difference is not clear cut). Regards, Arjen
participants (3)
-
Arjen de Korte -
Barry Gill -
Carlos E. R.