From: Anthony Howe
Date: 2005-08-02 10:47:19 -0400
Subject: Re: sender question
More information..: http://www.milter.info/#Support
> 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[220.127.116.11]) by (...) ...
> Received: from (...) by mailserver.domain2.com ...
> And mailserver.domain2.com resolves to 18.104.22.168.
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
Anthony C Howe +33 6 11 89 73 78
7116561 AIM: Sir Wumpus
Sendmail Anti-Spam Solutions http://www.snertsoft.com/
We Serve Your Server
Copyright 2009, 2012 by SnertSoft. All rights reserved.