http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5374
------- Additional Comments From [EMAIL PROTECTED] 2007-03-19 07:59 ------- (In reply to comment #0) > * pbl - end-user IP address ranges which should not be delivering > unauthenticated SMTP email to any Internet mail server except those provided > for > specifically by an ISP > - We don't want to check the final IP against this, because we actually expect > it to be in the PBL note that "authenticated" also means "authorized to relay by MTA", e.g.: customers sitting in the ISP's own IP space that are allowed to relay without authentication by default, whether they use SMTP-Auth or not. > > * njabl-dul - includes dynamic assigned ip-addresses (DHCP) of ADSL and Cable > which stops even unknown trojan cold > - We don't want to check the final IP against this, because we actually expect > it to be in the njabl-dul With the launch of PBL, the "dynablock.njabl.org" zone (127.0.0.3 code), which is also present in the combined.njabl.org zone (127.0.0.3 code) has become one and the same as the PBL. NJABL-DUL in this context was the former "dynablock.easynet.nl" zone, that evolved substantially since the original DUL shut down. > For the pbl/njabl-dul, we have a problem. How do we tell the difference > between: > > user ip -> isp/3rd party smtp -> receiver > zombie user ip -> forwarder -> receiver You can't. Webhoster 'mail forwarder' type of MTAs are probably the single worst problem for large email receivers (ISPs) today: They are often poorly or not at all spam-filtered (often with intent, and with the excuse of "our customers have the right to receive all mail sent to their email addresses"!), with spam:ham ratios reaching 90% (at least reasonably filtered forwarders reach 50-60%) - basically offloading spamfiltering to the receiving MTAs where it hurts most: post-mail-acceptance content scanning (CPU intensive). And yet, unless you are a SORBS-using moron of a MTA-admin, you will not deny these forwarder's traffic at the front door, because your own customers have hosted (and mail-forwarded) accounts there. > > There may be information in the Received headers that it was an authenticated > SMTP session, but that can't be guaranteed, so I think that you can't use > dialup > RBLs in these cases, it's impossible to accurately tell the difference. Both SMTP-Auth'd and relay-permitted-by-IP situations exist concurrently, even on the same MTA, so you can't tell the difference. Do not attempt to use the PBL for this purpose. It'll even be troublesome to use XBL for behind-MTA Received header checks, with a noticeable FP rate, but I would suggest further testing for this, as it'll probably hit the guilty people and poorly managed ISPs (and their poorly managed, non-SMTP-filtered dynamic ranges) quite disproportionally. > > Also if you try and use a dialup RBL in this case: > > zombie user ip -> receiver > > It also breaks this: > > internal ip -> sme mail router (on adsl connection) -> receiver > > And if you have internally delivered email, it might break this case as well: > > user ip -> 3rd party auth smtp -> same 3rd party recipient > > In that case, if your mail server doesn't add something to the header to note > it's an authenticated SMTP session, we'd lookup the DUL against the user ip, > even though they used auth smtp. > > Unfortunately I don't think there's an easy solution that allows the use of > DUL/Dynablock type RBLs consistently and accurately. I think DUL type > blocklists > should only be used if: > > 1. You only check against the first noninternal IP (quite possibly different > to > first nontrusted IP if you have a bigger trust algorithm like the one from BUG 5373) > 2. If you accept SMTP auth mail for local users, your mail server does add the > appropriate Received header that parse_received_line can detect as an > authenticated SMTP session > 3. You're willing to penalise SME type customers that run their own mail > servers > on DSL/dialup lines > > I think there should be a pretty much global switch to enable/disable these > dynablock/dul type lists that people can change if they are sure their system > conforms to the above requirements ISPs (and other institutions) must not use DNSBLs to deny service to their own customers - that's particularly true for their own IP space, but also customers sending mail via SMTP-Auth+Submit from other locations. Whether they use DNSBLs to flag accounts or rate-limit them, is up to then, but it has to work by default. The only clean solution is to separate incoming MTAs (SMTP from world) from outgoing/relaying MTAs (SMTP-Auth+Submit or permit local IP space), and apply different SA rulesets on both. On combined servers, this can get VERY messy - and SA admins most certainly will have to make their own IP space used by their customers "trusted", and with it disable all DNSBL rules against those IPs. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
