[milters] Archive

Lists Index Date Thread Search

Article: 678
From: Anthony Howe
Date: 2005-08-02 10:47:19 -0400
Subject: Re: sender question

Removal...........: milters-request@milter.info?subject=remove
More information..: http://www.milter.info/#Support
--------------------------------------------------------

barryc wrote:
> I'd noticed that of the mail coming into my mailservers, I could fairly easily 
> distinguish an enormous volume of the SPAM from the real messages by looking 
> only at the Received: headers. ( Specifically the lines that read: "Received 
> from ... by ..." If it doesn't show both machines involved in the SMTP 
> transaction, you can ignore it.)
> 
> For example:
> 
> If there was only one of these headers, (received from .... by [MY_MAILSERVER]) 
> then one of three things is ALWAYS true:

When a milter is called to process a header, I don't think the server's 
own Received header has yet been added. As I recall, I had to specailly 
fake a Received: header for milter-spamc and the data feed to spamd.

> 1) The message was sent by a SMTP-AUTH authenticated client.

All my milters accept SMPT-AUTH messages, unless it doesn't make sense 
to do so like milter-report.

> 2) The message came from a host specified in /etc/mail/relay-domains

In which case you want to start with the first Received: from the 
incoming client connection and check for a "by host..." that match the 
client_addr / client_name of the connecting client. A mismatch would not 
be a clear sign, since outbound SMTP and inbound SMTP don't have to be 
the same machines (think AOL, Gmail, etc.).

> 3) The message is SPAM sent by a zombie computer.

Again. Take care. Consider a business with several SMTP servers behind a 
  firewall or NAT router. The MX and outbound SMTP could have different 
IPs on their network, yet both will appear to come from the IP of the 
firewall. The Received headers wouldn't make sense here unless the 
admin. is clever enough to properly configure the MTA to insert the 
current IP, name, etc.

> Further tests can be performed on messages with multiple Received lines. Here 
> are a couple examples:
> 
> 1) Locality: Any time that I receive email where there are two blocks of 
> Received headers separated by other random headers, the second block is ALWAYS 
> forged.  Is it coincidence that legitimate Received headers are always 
> contiguous, or is it specified by the RFC? Or, another way to ask the question: 
> Is it conceivable that a properly-behaving mailserver may insert other headers 
> before prepending its own Received header?

Yes. You can have multiple Resent-* blocks between Received: blocks. 
They insert like trace headers. See RFC 2822.

> 2) Sanity: Consider the following two hypothetical adjacent headers:
> Received: from (mailserver.domain1.com[69.215.194.218]) by (...) ...
> Received: from (...) by mailserver.domain2.com ...
> 
> And mailserver.domain2.com resolves to 162.140.64.107.

I think this thought is incomplete. What I'm I looking for in this case?
Are you thinking the from-by in adjacent headers should match?

Consider the case where one server has several processes like an 
AV-gateway, a spam filter, and an MTA. I would see three different 
Received headers possibly with different name/IP for the host. Also some 
sites, like a university will relay through a smart host, which might 
not have a public IP address.

Received header testing is tricky. One of the reasons I leave it to 
SpamAssassin to do it since they've added many heuristics that 
contribute to the scoring. Rejecting solely on the basis of Received: 
headers might be trouble. I'm thinking though that SPF could be used in 
conjunction to validate the route to build a confidence value. Still not 
accurate though.

-- 
Anthony C Howe                                 +33 6 11 89 73 78
http://www.snert.com/       ICQ:
7116561         AIM: Sir Wumpus

Sendmail Anti-Spam Solutions           http://www.snertsoft.com/
                                             We Serve Your Server

Lists Index Date Thread Search