Re: Whitelist IP Address
Of course Matt, any decent SMTP server allows you to configure it so that it refuses or lets through mail sent directly from certain IP hosts or subnets with addresses being taken from communication level (source of TCP connect request incoming to the server). When it comes to IP subnets of relays farther back in the chain you have to look at the headers. In simple words, when going backwards in the chain you need to find first relay that is "economical with the truth" as far as "Received from" header concerns, or refuses to cooperate. Then you want to blacklist it or its whole subnet if they are constantly moving the offender. I have yet to read whether this can be done at the user level. However, in my previous comment, I didn't express myself precisely enough. I didn't mean "block" or "let through" rather "execute test and set specified score if the test turns true" so that the final decision what to do with the mail could be affected by the other tests. Very often you also want to do something else than the simple block or pass, such as repackage and mark, give the user a hint but let him decide. AFAIK this you cannot do in an SMTP server. You also want to gather together all spam related work in one place. - Original Message - From: "Matt Kettler" <[EMAIL PROTECTED]> To: "Mikael Hakman" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; Sent: Thursday, March 10, 2005 5:25 PM Subject: Re: Whitelist IP Address At 05:39 AM 3/10/2005, Mikael Hakman wrote: Wouldn't you all agree that blocking or letting through emails sent from or relayed by specified IP addresses and subnets is quite a basic functionality? In a sense it is more basic than doing the same with DNS names and SMTP addresses because all those names ultimately resolve to IP numbers. All communication (routing) on the Internet is done by numbers not by names. Yes, so basic I would expect it to be implemented in whatever tool you're using to call spamassassin in the first place. MailScanner does it, Procmail can do it... Then why can't we have such a generic rule built-in into SA? I don't see why not. However, IMO all of the whitelisting features built into SA are bordering on being a hack anyway. They have their uses, but there's often better ways. 1) SA doesn't have good reliable access to envelope information, it relies on the MTA inserting clues and hints into the headers. Most tools that call SA have access to the envelope directly. 2) if you whitelist at a higher layer you have the option of not calling SA at all, in which case you save CPU. __ NOD32 1.1022 (20050309) Information __ This message was checked by NOD32 antivirus system. part000.txt - is OK http://www.nod32.com
Re: Whitelist IP Address
Wouldn't you all agree that blocking or letting through emails sent from or relayed by specified IP addresses and subnets is quite a basic functionality? In a sense it is more basic than doing the same with DNS names and SMTP addresses because all those names ultimately resolve to IP numbers. All communication (routing) on the Internet is done by numbers not by names. Then why can't we have such a generic rule built-in into SA? Creating custom header rules is ok as long as you want to recognize particular IP host addresses and subnets with IP ranges on whole byte boundary. In the general case however you have to do bitwise AND between address from SMTP header and a subnet mask and compare the result to the result of doing bitwise AND between subnet address and the same subnet mask. AFAIK this is not possible to do in SA custom header rules unless you find a way to express this as a Perl regular expression for pattern matching. Then why can't we have a test/rule, say, WHITELIST_NUMERIC_IP and BLACKLIST_NUMERIC_IP that take IP number and subnet mask as arguments and does this double AND operation and comparison against each IP number from Received headers? To all who do not understand why so many people want to work with IP numbers rather than with DSN names or SMTP addresses: When an SMTP server receives email it knows IP number of the sender (relay). It knows it from IP packet header source IP address. This number is independent of what sender's SMTP server says he is. This is because both SMTP and the underlying TCP require sending IP packets in both directions for this reception process to succeed. Therefore at the time an SMTP server receives email from an IP then it knows that this IP is real, it exists, and is world-reachable through the global routing system. Therefore it can be traced and you cannot forge it. Each IP number belongs to a range of IP addresses (subnet) managed by a known authority. Each such authority has received its IP range from yet another higher known authority etc. until you reach the top (RIPE etc). Contrary to DNS names you cannot simply buy or register an unrelated IP number and therefore IP numbers are much more difficult to forge and easier to trace than names. - Original Message - From: "Matt Kettler" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; Sent: Thursday, March 10, 2005 1:55 AM Subject: Re: Whitelist IP Address At 07:49 PM 3/9/2005, Mike Carlson wrote: How do you whitelist an IP address? I want to allow all email from a specific IP address to pass through the filter without being tagged as spam. I added all 4 IP addresses of the server to the trusted networks list, but that didnt seem to do it. Pretty much the only way I know of is to make a custom header rule that looks for a Received: header that came from that IP. __ NOD32 1.1022 (20050309) Information __ This message was checked by NOD32 antivirus system. part000.txt - is OK http://www.nod32.com
How to classify mail by numeric IP address of sender or relay?
How to classify (as spam or ham) mail sent from or relayed by a specified numeric IP address of a host or a subnet? Example: Received: from finklfan.com (unknown [222.111.110.107]) by rushmore.scorpionshops.com (Postfix) with SMTP id 1D8207355A for <[EMAIL PROTECTED]>; Sat, 5 Mar 2005 16:11:57 +0100 (CET) Received: from wamu.com (mtav004.erms-02.wamu.com [167.88.201.35]) by finklfan.com (Postfix) with ESMTP id 13F3E5F8C6 All mail from or relayed by hosts on 167.88.0.0/255.255.0.0 network should be classified (as ham or spam depending on the needs). Also, independently from previous, all mail from or relayed by hosts on 222.111.110.0/255.255.255.0 network should also be classified. Thanks/Mikael
