>...
>List-Id: <users.spamassassin.apache.org>
>Delivered-To: mailing list users@spamassassin.apache.org
>Delivered-To: [EMAIL PROTECTED]
>...
>Date: Tue, 01 Mar 2005 19:32:22 -0500
>From: "Eric A. Hall" <[EMAIL PROTECTED]>
>User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
>X-Accept-Language: en-us, en
>MIME-Version: 1.0
>To: Justin Mason <[EMAIL PROTECTED]>
>Cc: [EMAIL PROTECTED]
>Subject: Re: another request for RECEIVED[x] array
>References: <[EMAIL PROTECTED]>
>In-Reply-To: <[EMAIL PROTECTED]>
>Content-Type: text/plain; charset=ISO-8859-1
>Content-Transfer-Encoding: 7bit
>X-Virus-Checked: Checked
>
>
>On 3/1/2005 12:37 PM, Justin Mason wrote:
>
>> actually, there is such a thing in SpamAssassin 3.0.x ;) e.g.:
>
>> debug: metadata: X-Spam-Relays-Untrusted: [ ip=199.172.62.20
>> rdns=europe.std.com helo=europe.std.com by=mail.netnoteinc.com ident=
>> envfrom= intl=0 id=392E1114061 auth= ]
>
>This doesn't record the 'with' parameter (as in "with SMTP" or "with
>ESMTP"), or any TLS info.
>
>> I want to have available to me are:
>>>
>>> 1) Check for a reverse-DNS match
>>>
>>> 2) Check for HELO (versus EHLO)
>>>
>>> 3) Check for TLS
>
>I already have a reverse-DNS rule coded up but I'd like to consolidate it
>with the other two, but again, I really need a better view into the
>transfer protocol from inside SA.
>
>--
>Eric A. Hall http://www.ehsco.com/
>Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
>
Eric,
Please note that is section 4.1.4 of RFC2821 it says:
"...
An SMTP server MAY verify that the domain name parameter in the EHLO
command actually corresponds to the IP address of the client.
However, the server MUST NOT refuse to accept a message for this
reason if the verification fails: the information about verification
failure is for logging and tracing only.
..."
The capitalization is in the original, not added. Reference from:
ftp://ftp.isi.edu/in-notes/rfc2821.txt page 38, 6th paragraph of section 4.1.4
On the other hand, both sendmail and postfix can be configured to
refuse messages if there is no rDNS at all for the HELO/EHLO or if the
client address doesn't have any rDNS. I *would* recommend these, but
since the most common MTAs already have the capability, there shouldn't
be any need for SA to duplicate it. Also, the number of FPs if you attempt
to enforce an exact match would be *very* high; Whenever a MTA hosts multiple
domains, only one could possibly pass the test - but it is reasonable for
any host which is an 'MX' for a domain to use that domain as an argument to
the HELO/EHLO (and possibly - definititely allowed - for any host in a domain
to use the domain name as the argument to the HELO/EHLO) . Also, note that
an 'A' record isn't required (though it is recommended) - see section 4.1.1.1
and note that both sendmail and postfix will accept a "resolvable" domain as
defined there (i.e. at least one 'MX' or 'A' record, and it need not match
the actual client's IP address).
You also have the problem of dealing with IP literals, and users
running dynamic DNS which still has stale DNS data (so the response should
be a 4xx code not a 5xx code, if you do something like this). If you use
an SA rule, the score should be fairly low. As an example, recent mail I
have exchanged with [EMAIL PROTECTED] has used escalate.hk.outblaze.com
as the argument to EHLO, but the rDNS resolves to escalate.outblaze.com, and
they *certainly* are not spammers (notice also, that both names resolve in
different ways, but to the same IP address).
Paul Shupak
[EMAIL PROTECTED]
