hdatma commented 9 years ago

Hello,

The following address sent spam today, and it does not occur in the list: 77.47.47.237.dynamic.cablesurf.de

As keeping the list up to date is impossible, I suggest you replace individual entries with a common pattern. For example, the following rules replace about 320 individual entries, they automatically include similar new entries, and help speedup postfix's filtering:

I also suggest removing the "static" addresses: offices get those, and some host their own well-configured e-mail servers.

stevejenkins commented 8 years ago

I'm going to give some thought to the request and ask for some feedback.

On the static addresses, are those rules actually rejecting the connections, or simply prepending the X-GenericStaticHELO of the primary host?

stevejenkins commented 8 years ago

Received this feedback via email from Noel Jones of the Postfix Users list:

The greatest feature of fqrdns.pcre is its goal of zero false positives. Don't break that. Remember, you're deciding for everyone what what mail they won't receive. Individual users are still free to add their own stricter rules.

Adding generalized rules that may block more spam at the expense of more possible false positives should be avoided. Individual users are still free to add their own local rules if they find these rules too permissive. Experience has shown generalized blocking of dyn/dial/dhcp/wifi/etc. PTRs is not 100% safe, which is why those rules aren't in the list already.

stevejenkins commented 8 years ago

There hasn't been a lot of feedback on this issue so far, but Noel's argument is a convincing one. One of the primary goals of this list is to avoid false positives. But I'll leave this issue open for more comments.

hdatma commented 8 years ago

If you wish to receive e-mail from yet another dynamic address with malicious payloads, a forensic network traceroute you can use to play the national lottery on Christmas Eve, and a bogus contact detail of the sending server's owner, then follow Noel's argument. Although you can certainly add the new dynamic address to fqrdns.pcre, the damage has already occurred, and there is no one else to blame in court other than yourself.

Concerning myself, I demand from my server a more general solution to this problem. I removed all dynamic addresses from my fqrdns.pcre, and replaced them with a few general regular expressions. If someone wants to send e-mail to our server, they must use a forensically sound traceroute of static addresses.

stevejenkins commented 8 years ago

Your argument makes sense, @hdatma. But this file is not meant to be the only weapon in the fight against spam. It's supposed to be a very conservative one, and should avoid false positives, even if that means letting a few slip through to be caught by other tools. Of course, you (and all other admins) are free to add more restrictive rules, as desired.

While this is being discussed and considered, I'd at least like to immediately update the file to catch cablesurf.de dynamic hosts. Can you confirm that the following line would have worked in your case?

/^([12]?[0-9]{1,2}\.){4}dynamic\.cablesurf\.de$/ REJECT Dynamic - Please relay via ISP (cablesurf.de)

hdatma commented 8 years ago

I have neither said nor hinted that fqrdns.pcre is "the only weapon" agains spam. However, in the specific case of mail from dynamic domains, fqrdns.pcre helps a lot. No one should fear the "false positives" here, since dynamic domains are not supposed host mail servers anyway. To put is bluntly, if you cannot send mail to them, why would you want to receive it from the same? Dynamic domains are for clients, not servers.

hdatma commented 8 years ago

Besides, if a false positive occurs, the sender can always read the bounch message and re-post using a reputable server. I prefer this case to the case of unsolicited junk and malware, which is what you get 99.99% of the times.

stevejenkins commented 8 years ago

@hdatma: Please check the newly created "develop" branch of this project. I would very much appreciate your thoughts.

I'd also appreciate you verifying that the general patterns you proposed in the OP are correct in the fqrdns-max.pcre file. Thanks!

hdatma commented 8 years ago

I (would) keep a single call to a single fqrdns.pcre with a few general rules on top and a handful of ad-hoc rules in the bottom. The following is a possible list of general rules. My version includes supporting evidence for each rule. The approach is the following: one first collects evidence, then uses the collection to draw patterns as regular expressions. New evidence is useful to improve the patterns. Of course, this is not science but "mere" engineering, and therefore it would be really useful if ISPs across the planet would spare us from the guesswork, for example by agreeing on a standard nomenclature for dynamic addresses or, more simply, by using a single standard "dyn-" prefix to whatever name they want to use...

+++++ dynamic.regexp +++++

/([0-9]{1,3}[.-]){2,4}.[.-]d[iy]namic[ao]/ REJECT Dynamic - Please relay via your ISP /d[iy]n(amic|amicIP|adsl|dsl|ip|pool)?[.-]?._[0-9]{0,3}[.-]/ REJECT Dynamic - Please relay via your ISP /dial(in|up|-up|ip|pool|bs)?[0-9]?[.-]/ REJECT Dynamic - Please relay via your ISP /dhcp[0-9]?[.-]/ REJECT Dynamic - Please relay via your ISP /(wireless|wifi|wimax|.mobileonline)[.-]/ REJECT Dynamic - Please relay via your ISP

stevejenkins / hardwarefreak.com-fqrdns.pcre

+1 (infinite loop) #3

+++++ dynamic.regexp +++++