>Justin Mason wrote:
>
>>Eric A. Hall writes:
>>
>>
>>>SA 3.0.2 currently performs a handful of tests against HELO greetings that
>>>contain an IP address. These tests don't currently fire when an "address
>>>literal" is used in the HELO greeting, but they should.
>>>
>>>
>>
>>actually, that's deliberate -- compare the frequencies of an RFC-2821
>>address literal, vs. a raw address, and you'll notice that the latter
>>is much more prevalent in spam.
>>
>>
>>
>Do you mean it's deliberate to catch this (as a helo ip mismatch):
>
> Received: from unknown (HELO 212.27.42.19) (218.190.234.6)
>
>but not this
>
> Received: from unknown (HELO [212.27.42.19]) (218.190.234.6)
>
>I can see that the latter may hit ham (nat+no hostname). Is this the
>justification? (hit very few spam but hit some ham?)
>
Justin,
The first is simply invalid and illegal, the second is perfectly
allowable; In fact, RFC2821 recommends the second case for dynamically
assigned host addresses (e.g. DHCP from your ISP). It is also not clear
that the second case is NAT'd - It might just be DHCP directly. But since
it appears that the hostname "mrelay3-2.free.fr" is statically assigned,
using the hostname would be preferable, but either is legal. Spammer seem
to use the first case because it is so readily accepted; In fact, between
half and a third of the ones (in the first case) that I see, are trying to
use either my MX hosts or other addresses on my network.
Now, if the rule doesn't catch the second case, I would call that a
bug in SA. But again, RFC2821 has something to say:
RFC2821 Section 4.1.4
"...
The SMTP client MUST, if possible, ensure that the domain parameter
to the EHLO command is a valid principal host name (not a CNAME or MX
name) for its host. If this is not possible (e.g., when the client's
address is dynamically assigned and the client does not have an
obvious name), an address literal SHOULD be substituted for the
domain name and supplemental information provided that will assist in
identifying the client.
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.
..."
So as Eric has previously pointed out (not sure if it was on or
off list); You "MUST NOT" refuse mail because of the mismatch (i.e. the
SMTP conversation must not give a 4xx or 5xx code with that as a reason),
but however you chose to handle it locally is you own business and the RFCs
have nothing to say (nor do they care) about the matter: One can argue that
even if it were to contribute to a score high enough to locally "bit-bucket"
the message, it would go against the spirit of the "law" to do so, but to
mark it up a classify it certainly would not.
Now, one interesting case not yet discussed is what happens if a
multi-homed machine uses one address, but transmits using another - the
tests *really* need to do reverse lookups, following pointer records, then
back to forward and compare all possible "legal" cases. Your example is an
easy case, because the client address you used is unassigned - Again, but
what if it were the same host, just a different interface and maybe one or
both have to be traced through 'CNAME''s before the match can be recognized!
Also, because of the 'MX' clause, I would argue (and SA currently
does work this way), that if either is a valid 'MX' for the other, no rule
should trigger (look at the "masquarade" options for either of Postfix or
sendmail - both would cause that case to occur if used, and both are *very*
commonly used).
Paul Shupak
[EMAIL PROTECTED]
