>> >> There were 3 replies to my suggested rules. I am responding to those >> comments, plus giving statistics on what I've found in the spam & ham >> I've collected. >> >> >> Display name statistics: >> >> Since I haven't collected the data on the other local users for their >> display names, I looked only at the mail that had display names for my >> email address. "Standard display name" means the display name(s) that I >> use on outgoing mail. Non-standard display name means anything else >> where a display name is given. So, as you see by this mail, my standard >> display name is "Mabry Tyson". Mail without a display name is not >> considered. >> >> Note: SA has the NO_REAL_NAME test (score 0.1 - 0.3). This encourages >> spammers to put some display name in the from field, even if it is >> completely bogus. >> Likewise, the TO_ADDRESS_EQ_REAL rule (score 0 - 0.5) encourages >> spammers to put some display name in the To: field (or none), even if it >> is completely bogus. >> My suggested rules try to catch the use of a bogus display names and >> helps to make those rules not lose their value. >> >> A number of the sources of email addresses that are reaped by spammers >> may not have display names associated with them. It appears that the >> spammers have not been collecting (or at least have not used) display >> names for the addresses they use. Of course there are no valid display >> names for dictionary-based spam (to smith, jones, john, tom, aaa, aab, >> ...). Having a rule that uses display names would further minimize the >> value of old lists of email addresses. >>
>> I wouldn't recommend it, but for this sample, having the correct display >> name could be a whitelist. >> Clearly, having the wrong display name shouldn't be a blacklist, but I >> could imagine that it could have a positive score. >> >> As a rough guide, I could see having all correct display names for the >> local addresses (for which display names were given) in To/CC might >> contribute a score of -1 or -2, while having at least one incorrect >> display name for any local address might contribute a score of 1. >> (Those are maximum scores, not scores per correct/incorrect display >> name.) I would set the score for having a non-standard display name in >> the From: field as being at least 3. >> >> Your mileage may vary.... >> >> >> Note: a user can add a rule to easily check that the use of his address >> has his standard display name: >> Also, I'd like to detect someone sending mail to me with a display name >> of "John Smith" or "Jane Doe" but that is more cumbersome to do: >> (THESE ARE UNTESTED -- This is just for noting that this can be done for >> a single or few addresses.) >> >> header SOME_DISPLAY_NAME_FOR_ME ToCC =~ >> /[a-z0-9][^>]*<[EMAIL PROTECTED]>/i >> score SOME_DISPLAY_NAME_FOR_ME 1 >> header PROPER_DISPLAY_NAME_FOR_ME ToCC =~ /My >> Name[^>]*<[EMAIL PROTECTED]>/i >> score PROPER_DISPLAY_NAME_FOR_ME -3 I just noticed that some mail in today's or yesterday's list traffic happened to have the display name at the end, i.e. <[EMAIL PROTECTED]> "Joe Smith" >> >> Wolfgang Hamann: He has his MTA "refuse unauthenticated mails from >> local senders" (with exceptions for trusted relays). He states that >> the rejection of such mails does not cost bandwidth. Based on his >> statement about bandwidth, it appears he is only looking at the SMTP >> envelope address (MAIL FROM ...) rather than the From: line in the >> header (for which he'd have to get the entire message first). What he >> has done seems good and appropriate. However, it is not what my >> suggested rule #1 (and part of #3) covers. It also doesn't speak to >> rule #2. >> To clarify: if someone wants to send mail FROM [EMAIL PROTECTED] TO [EMAIL PROTECTED], the mail should either be sent from the local system (web forms), or from people who connect their mail clients to this server. These all have to authenticate for sending mail - consequently mail from [EMAIL PROTECTED] is considered invalid when it is just dropped at the mailgate Of course, this does not catch spam where the mail from looks valid >> >> is different than the From: address. Also, the From: address may be >> different because the user may be using, for instance, his home ISP but >> wants to send the mail with his work email address. etc. Thus you >> can't depend upon the MAIL FROM address matching the From: address. >> Filtering on the MAIL FROM address is not the same as filtering on the >> From: address. These users are encouraged to connect through their home isp's lines to the company mail server. In any case a certain portion of mails sent from home will not be delivered because the recipient might do DUL or SPF checks Wolfgang Hamann >> >> I am seeing mail with the From: address forged as a local address and >> the MAIL FROM address as something completely valid (but not local). >>
