Saturday, August 3, 2002, 7:03:30 PM, R. Scott Perry <[EMAIL PROTECTED]> wrote: [SNIP]
>>This is only a potential problem when checking beyond HOP 0 >>against RBL and RBL+. RSP> ... and any other spam test that blacklists those IPs (I don't know offhand RSP> if any do, but it is likely). O.K. It is only a potential problem when checking above HOP 0. [SNIP] >>So, that's not a very good solution. I can whitelist addresses >>after the fact, but that means the customer had called and complained >>or I caught it by accident. Also, not so good. RSP> That IS good. People who are making the spam problem worse really should RSP> go through that inconvenience (in my opinion). If they set up their RSP> networks properly, the mail would have gone through, and the spam problem RSP> would be easier for you to deal with. I would agree except it is not my customer's network and they hear from the sender or the sender's admin (those who can't spell DNS, either) that it is their ISP's (my) problem, because they are only having this problem with us (me). It's the old hardware vs. software loop, again. That was O.K. with Open Relays, but this is a different scenario. RSP> I'm not sure if it is worth the extra effort to help these people that are RSP> making the spam problem worse. You have to take a stand somewhere (like RSP> people did with open relays, which are RFC-compliant). RSP> Note that RFC1918 -- the very one that gives the "safe" private IPs -- RSP> specifies that if you want to use other ones, you are required to obtain RSP> them from an Internet registry. RSP> There are other problems with people using these invalid IPs -- for RSP> example, their routing information can leak out to their ISP. I generally agree and we took a stand WRT Open Relays and our customers generally understood or eventually got over it. However, Open Relay is applicable to Hop 0 and we're talking about checking Hop 1 and above. HOP 1 and above can easily be the IP of the internal LAN, which was the instant case. You recognized that potential when you added the RFC1918 exclusion to Declude. I don't think I'm going to get away with telling someone (particularly one who can't spell DNS) that they have to renumber their internal network in order for our customer to receive e-mail from them. I'm good, but I don't think I'm that good, and I really don't want to find out either. I probably would get a few laughs, though, but I doubt it would be me who was laughing. >>We're only talking about testing MAPS (RBL and RBL+) for HOPs which >>are greater than zero. Correction. We're only talking about testing above Hop 0 (Hop 1 & Up). RSP> Have you asked MAPS about this? If not blocking reserved IPs is a good RSP> solution, wouldn't it be better for MAPS to take out those IPs from their RSP> database? RSP> -Scott I think them having the IANA Reserved addresses in the database is great WRT Hop 0. I'd also encourage them to add the RFC1918 addresses for the same reason (hop 0). The difference is that Declude already knows to ignore the RFC1918 addresses when checking higher than Hop 0 but it doesn't know to ignore the IANA addresses. I sent an e-mail to MAPS (bcc to your private address) asking if they pass anything special or would be willing to add something for the IANA Reserved space. I also asked why the RFC 1918 space wasn't blackholed, as well. Maybe they will answer in our lifetime. I recognize that you would rather not program this into the code and that you don't want to have the responsibility to change code when IANA releases a reserved block. I further recognize that it almost puts you in a position of having to monitor IANA. The other thing, too, is what if we find out some other list has included these reserved addresses, when we have only solved it with MAPS - more special coding. I understand from your point of view and don't blame you a bit. So, how about making it user configurable? Put the CIDRs for all reserved addresses to ignore for hop 1 and above in a section of the global.cfg. It's then up to the user to maintain it and it's a one time change for you to program. In addition, I think that both Reserved space (IANA and RFC1918) should get blackholed when hop 0 and inbound from the Internet. Does my BlackIP list get used for all hops or only for hop 0? I'm hoping it is used for all hops. If so, then how to best handle the blackhole for only hop 0? Thanks, ---- Don Brown - Dallas, Texas USA Internet Concepts, Inc. [EMAIL PROTECTED] http://www.inetconcepts.net PGP Key ID: 04C99A55 (972) 788-2364 Fax: (972) 788-5049 Providing Internet Solutions Worldwide - An eDataWeb Affiliate ---- --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
