>...
>Date: Sat, 12 Mar 2005 18:46:52 -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: users@spamassassin.apache.org
>Subject: Re: SA addr tests
After considering all the discussion, I've filed these three bugs:
4188--RCVD_HELO_IP_MISMATCH should check address literals (this was
argued against by Justin, but I'm convinced it's spam-sign)
4186--RCVD_NUMERIC_HELO does not test "reserved" addresses (they are
still 'numer
On 3/11/2005 3:42 PM, Theo Van Dinter wrote:
> On Fri, Mar 11, 2005 at 03:25:06PM -0500, Eric A. Hall wrote:
>
>> Extending the problem report--it seems that these rules don't fire in
>> some instances. I haven't really checked this out yet, but addresses
>> with a leading octet of 111, 123, and
On Fri, Mar 11, 2005 at 03:25:06PM -0500, Eric A. Hall wrote:
> Extending the problem report--it seems that these rules don't fire in some
> instances. I haven't really checked this out yet, but addresses with a
> leading octet of 111, 123, and some others at or below ~130 seem to get
> skipped ent
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric A. Hall writes:
> On 3/9/2005 1:38 PM, Eric A. Hall wrote:
>
> > I think the four affected rules are RCVD_HELO_IP_MISMATCH,
> > RCVD_NUMERIC_HELO, RCVD_ILLEGAL_IP, RCVD_BY_IP
>
> Extending the problem report--it seems that these rules don't fir
On 3/9/2005 1:38 PM, Eric A. Hall wrote:
> I think the four affected rules are RCVD_HELO_IP_MISMATCH,
> RCVD_NUMERIC_HELO, RCVD_ILLEGAL_IP, RCVD_BY_IP
Extending the problem report--it seems that these rules don't fire in some
instances. I haven't really checked this out yet, but addresses with a
You already got a couple of responses but let me pile on.
On 3/10/2005 3:17 AM, [EMAIL PROTECTED] wrote:
> However, I still believe it is perfectly legal to refuse mail if
> - the HELO matches my own MX, or lists one of my IPs
I do this too. My local networks get an immediate exception to all
>>>...
>>> ..."
>>>
>Now, these are the rules
>
>However, I still believe it is perfectly legal to refuse mail if
>- the HELO matches my own MX, or lists one of my IPs
>or
>- the MAIL FROM pretends to be one of my users
>
>I am currently refusing this stuff at the MTA level and suggest to
>au
Now, these are the rules
However, I still believe it is perfectly legal to refuse mail if
- the HELO matches my own MX, or lists one of my IPs
I guess you mean at the MTA level, not by checking Received headers.
or
- the MAIL FROM pretends to be one of my users
This isn't always appropriate:
-
>>
>> 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 assigne
>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'
On 3/9/2005 6:08 PM, Justin Mason wrote:
> mouss writes:
>
>>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)
> yes.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
mouss writes:
> 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 c
On 3/9/2005 5:17 PM, List Mail User wrote:
> Postfix option "reject_invalid_hostname" will reject bare
> IPs (when used in the "smtpd_helo_restrictions" section of main.cf).
Good to hear this was fixed. I filed a bug report on it in May '04 but
didn't get much of a response. I'll have to u
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 fre
>
>
>On 3/9/2005 3:29 PM, List Mail User wrote:
>
>>> See section 3.6 of RFC 2821:
>>>
>>> | - The domain name given in the EHLO command MUST BE either a
>>> primary |host name (a domain name that resolves to an A RR) or,
>>> if the host |has no name, an address literal as described in
>>
On 3/9/2005 3:29 PM, List Mail User wrote:
>> See section 3.6 of RFC 2821:
>>
>> | - The domain name given in the EHLO command MUST BE either a
>> primary |host name (a domain name that resolves to an A RR) or,
>> if the host |has no name, an address literal as described in
>> section 4
On 3/9/2005 4:01 PM, Justin Mason wrote:
>>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 th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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 de
Eric,
I believe that you have misinterpreted (and only partially quoted)
RFC2821. A more correct interpretation (or at least different) and a fuller
set of quotations is below.
>
>SA 3.0.2 currently performs a handful of tests against HELO greetings that
>contain an IP address. T
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.
See section 3.6 of RFC 2821:
| - The domain name given in the EHLO command MUST BE either a
21 matches
Mail list logo
