You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Robert Boyl <ro...@gmail.com> on 2016/05/01 15:20:09 UTC
understanding HELO_DYNAMIC_IPADDR
Hi, everyone
Ive seen some discussion in Spamassassin's bugzilla about this
HELO_DYNAMIC_IPADDR rule, some unanswered over years.
It says in description: # (require an alpha first, as legit
HELO'ing-as-IP-address is hit otherwise)
Is it talking about the host that first appears, that sent the email
authenticated to his ISP or the host/ISP that delivers to our server?
Because see the beginning when email is sent by @ig.com.br (legit Brazilian
provider)
Received: from webmail.ig.com.br (localhost [127.0.0.1])
by mike0032.ig.correio.biz (Postfix) with ESMTP id 4A7955FB70;
Wed, 6 Apr 2016 10:02:09 -0300 (BRT)
Received: from 187-57-222-55.dsl.telesp.net.br ([187.57.222.55])
via 187-57-222-55.dsl.telesp.net.br ([187.57.222.55])
by webmail.ig.com.br
with HTTP (HTTP/1.1 POST); Wed, 06 Apr 2016 10:02:09 -0300
Ok, the first host that appears bottom up does start with a number
187-57... but thats the users ADSL dynamic IP which sent mail using IG's
webmail, but it sent AUTHENTICATED SMTP via their ISP "ig.com.br".
This is the host that delivered mail to my ISP:
Received: from webmail-201.76.63.163.ig.com.br (
webmail-201.76.63.163.ig.com.br [201.76.63.163]) by mx3.myisp.com with
ESMTP id rDrGtcYe1PdHDBfh; Wed, 06 Apr 2016 09:02:10 -0400 (EDT)
X-Barracuda-Envelope-From: some-sender@ig.com.br
And it scores high:
HELO_DYNAMIC_IPADDR 3.24
I dont understand, since IMHO it shouldnt matter the host that sent mail to
its ISP, if its dynamic or not. IMHO what should matter is the ISP sending
mail to our ISP and in that case, the host does NOT start with a number.
Please advise.
Thanks.
Robert
Re: TTL on DNS records (was Re: understanding HELO_DYNAMIC_IPADDR)
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On Tue, 17 May 2016 21:42:15 +0200
Reindl Harald <h....@thelounge.net> wrote:
> discuss that with the pople of SOBRS
Aren't we just a ray of fucking sunshine?
Luckily, I have http://search.cpan.org/~dskoll/Mail-ThreadKiller/
to help me out.
Regards,
Dianne.
Re: TTL on DNS records (was Re: understanding HELO_DYNAMIC_IPADDR)
Posted by Reindl Harald <h....@thelounge.net>.
Am 17.05.2016 um 20:19 schrieb Dianne Skoll:
> On Tue, 17 May 2016 18:50:29 +0200
> Reindl Harald <h....@thelounge.net> wrote:
>
>>>> NOBODY is talking about BACKLIST short TTL
>>>> it's all about de-listing when you got blacklisted for good reasons
>
>>> IMO, the TTL is a completely irrelevant factor when considering
>>> whether or not to blacklist an IP. I do not believe there's any
>>> correlation between TTL and reputation of an IP address
>
>> interesting that you quoted me where i said *exactly the same*
>
> I worded my response incorrectly. I meant to say:
then you responded to the wrong mail
> TTL should be a completely irrelevant factor when considering whether
> or not to de-list an IP. After all, if it's not relevant for putting
> an IP on a list, how is it possibly relevant for taking it off the
> list?
discuss that with the pople of SOBRS
Re: TTL on DNS records (was Re: understanding HELO_DYNAMIC_IPADDR)
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On Tue, 17 May 2016 18:50:29 +0200
Reindl Harald <h....@thelounge.net> wrote:
> >> NOBODY is talking about BACKLIST short TTL
> >> it's all about de-listing when you got blacklisted for good reasons
> > IMO, the TTL is a completely irrelevant factor when considering
> > whether or not to blacklist an IP. I do not believe there's any
> > correlation between TTL and reputation of an IP address
> interesting that you quoted me where i said *exactly the same*
I worded my response incorrectly. I meant to say:
TTL should be a completely irrelevant factor when considering whether
or not to de-list an IP. After all, if it's not relevant for putting
an IP on a list, how is it possibly relevant for taking it off the
list?
Regards,
Dianne.
Re: TTL on DNS records (was Re: understanding HELO_DYNAMIC_IPADDR)
Posted by Reindl Harald <h....@thelounge.net>.
Am 17.05.2016 um 17:25 schrieb Dianne Skoll:
> On Tue, 17 May 2016 17:14:37 +0200
> Reindl Harald <h....@thelounge.net> wrote:
>
>> NOBODY is talking about BACKLIST short TTL
>> it's all about de-listing when you got blacklisted for good reasons
>
> IMO, the TTL is a completely irrelevant factor when considering whether
> or not to blacklist an IP. I do not believe there's any correlation
> between TTL and reputation of an IP address
interesting that you quoted me where i said *exactly the same*
Re: TTL on DNS records (was Re: understanding HELO_DYNAMIC_IPADDR)
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On Tue, 17 May 2016 17:14:37 +0200
Reindl Harald <h....@thelounge.net> wrote:
> NOBODY is talking about BACKLIST short TTL
> it's all about de-listing when you got blacklisted for good reasons
IMO, the TTL is a completely irrelevant factor when considering whether
or not to blacklist an IP. I do not believe there's any correlation
between TTL and reputation of an IP address.
Regards,
Dianne.
Re: TTL on DNS records (was Re: understanding HELO_DYNAMIC_IPADDR)
Posted by Reindl Harald <h....@thelounge.net>.
Am 16.05.2016 um 16:24 schrieb jdebert:
> On Mon, 16 May 2016 12:25:10 +0100
> Dominic Benson <do...@lenny.cus.org> wrote:
>
>>> Accepting that not all ISPs are as helpful as they might be, I can't
>> easily think of a legitimate reason for needing the TTL on the PTR of
>> a mail server to be small, so if a blacklist operator finds it an
>> effective way to manage request volume then that doesn't seem
>> unreasonable.
>
> Aren't short TTL's also indicative of load balancing and
> "cloud" systems? If this is truly the case it would seem a legitimate
> practice which makes blacklisting short TTL seems quite unreasonable
NOBODY is talking about BACKLIST short TTL
it's all about de-listing when you got blacklisted for good reasons
Re: TTL on DNS records (was Re: understanding HELO_DYNAMIC_IPADDR)
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 16 May 2016, at 10:24, jdebert wrote:
> On Mon, 16 May 2016 12:25:10 +0100
> Dominic Benson <do...@lenny.cus.org> wrote:
>
>>> Accepting that not all ISPs are as helpful as they might be, I can't
>> easily think of a legitimate reason for needing the TTL on the PTR of
>> a mail server to be small, so if a blacklist operator finds it an
>> effective way to manage request volume then that doesn't seem
>> unreasonable.
>>
>
> Aren't short TTL's also indicative of load balancing and
> "cloud" systems? If this is truly the case it would seem a legitimate
> practice which makes blacklisting short TTL seems quite unreasonable.
Short TTLs are an indispensable feature of DNS-based load balancing for
email servers, but only on the MX and (sometimes) A records. Short TTLs
on PTR records are not operationally significant because no widely used
standardized protocol depends on PTRs technically. It is possible to get
decent load balancing out of just having multiple short-TTL MX records
of the same weight that never actually change, if you have a DNS server
that randomizes the order of the records it sends in answers so that
senders try them in randomized order (usually...)
"Cloud system" is such a vaguely defined phrase (fitting, I guess...)
that I expect something that someone slaps that label on relies on short
"forward" TTLs, but again there's no concrete reason to make PTRs
short-lived because essentially nothing uses them them. Also, the only
point of short TTLs for cloud systems would be to allow for dynamic IP
assignment, making them entirely reasonable for listing on blacklists of
dynamically assigned IPs.
> ISTR that this is an ancient topic and there should be plenty of
> archived discussion. (No, I won't research it for you. Sorry.)
It's been discussed in various fora for about 17 years, starting around
when Gordon Fecyk started his DUL DNSBL. As a practical matter, default
TTLs have dropped over time because the reliability of the Internet has
gotten much better and the computers acting as nameservers much more
capable, while the nuisance level of having to reduce a 1-day TTL 2 days
in advance of a DNS change has remained constant.
Re: TTL on DNS records (was Re: understanding HELO_DYNAMIC_IPADDR)
Posted by jdebert <jd...@garlic.com>.
On Mon, 16 May 2016 12:25:10 +0100
Dominic Benson <do...@lenny.cus.org> wrote:
>> Accepting that not all ISPs are as helpful as they might be, I can't
> easily think of a legitimate reason for needing the TTL on the PTR of
> a mail server to be small, so if a blacklist operator finds it an
> effective way to manage request volume then that doesn't seem
> unreasonable.
>
Aren't short TTL's also indicative of load balancing and
"cloud" systems? If this is truly the case it would seem a legitimate
practice which makes blacklisting short TTL seems quite unreasonable.
ISTR that this is an ancient topic and there should be plenty of
archived discussion. (No, I won't research it for you. Sorry.)
Re: TTL on DNS records (was Re: understanding HELO_DYNAMIC_IPADDR)
Posted by Dominic Benson <do...@lenny.cus.org>.
On 16/05/16 12:10, Dianne Skoll wrote:
> On Mon, 16 May 2016 09:12:54 +0200
> Matus UHLAR - fantomas <uh...@fantomas.sk> wrote:
>
>> short ttl's are more likely on abusers' DNS. good for refusing
>> delisting.
> I would love to see data on the correlation. I think it's pretty
> mild. A few random tests on consumer cable IPs reveals TTLs for the
> reverse DNS ranging from a couple of hours to a day. For example,
> 24.34.32.22 => c-24-34-32-22.hsd1.ma.comcast.net. has a TTL of two
> hours while 24.44.32.22 => ool-182c2016.dyn.optonline.net. has a TTL
> of a day.
>
> The reverse-DNS of our server, roaringpenguin.com, which we do not
> control has a TTL of only one hour:
>
> 70.38.112.54 => roaringpenguin.com
>
> but the A record going the other way has a TTL of 86400.
>
> Regards,
>
> Dianne.
I don't think that the purpose of the policy is really related to
dynamic IP PTRs, but rather to make it infeasible for a spammer to both
request delisting from blacklists and to cycle through domains while
maintaining FCRDNS.
As I recall, the comment was only about blacklist maintainer policies
regarding delist requests, not about treating low-TTL reverse zones as a
spam indicator in its own right.
Accepting that not all ISPs are as helpful as they might be, I can't
easily think of a legitimate reason for needing the TTL on the PTR of a
mail server to be small, so if a blacklist operator finds it an
effective way to manage request volume then that doesn't seem unreasonable.
Dominic
Re: TTL on DNS records (was Re: understanding HELO_DYNAMIC_IPADDR)
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On Mon, 16 May 2016 09:12:54 +0200
Matus UHLAR - fantomas <uh...@fantomas.sk> wrote:
> short ttl's are more likely on abusers' DNS. good for refusing
> delisting.
I would love to see data on the correlation. I think it's pretty
mild. A few random tests on consumer cable IPs reveals TTLs for the
reverse DNS ranging from a couple of hours to a day. For example,
24.34.32.22 => c-24-34-32-22.hsd1.ma.comcast.net. has a TTL of two
hours while 24.44.32.22 => ool-182c2016.dyn.optonline.net. has a TTL
of a day.
The reverse-DNS of our server, roaringpenguin.com, which we do not
control has a TTL of only one hour:
70.38.112.54 => roaringpenguin.com
but the A record going the other way has a TTL of 86400.
Regards,
Dianne.
Re: TTL on DNS records (was Re: understanding HELO_DYNAMIC_IPADDR)
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>> >That seems a little aggressive, IMO.
>On Sun, 15 May 2016 18:08:31 +0200
>Matus UHLAR - fantomas <uh...@fantomas.sk> wrote:
>> I don't think so. If you have a mail server, you don't change its DNS
>> records very often.
On 15.05.16 20:47, Dianne Skoll wrote:
>Maybe, but the TTL on the DNS records has nothing to do with whether or
>not an address is part of a dynamic pool. I mean, you could give your
>dynamic addresses names that never change and set a TTL of a week, which
>wouldn't make the assignment of those addresses to customers any less
>dynamic.
short ttl's are more likely on abusers' DNS. good for refusing delisting.
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Due to unexpected conditions Windows 2000 will be released
in first quarter of year 1901
Re: TTL on DNS records (was Re: understanding HELO_DYNAMIC_IPADDR)
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On Sun, 15 May 2016 18:08:31 +0200
Matus UHLAR - fantomas <uh...@fantomas.sk> wrote:
> >That seems a little aggressive, IMO.
> I don't think so. If you have a mail server, you don't change its DNS
> records very often.
Maybe, but the TTL on the DNS records has nothing to do with whether or
not an address is part of a dynamic pool. I mean, you could give your
dynamic addresses names that never change and set a TTL of a week, which
wouldn't make the assignment of those addresses to customers any less
dynamic.
Regards,
Dianne.
Re: TTL on DNS records (was Re: understanding HELO_DYNAMIC_IPADDR)
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>On Sun, 15 May 2016 13:25:34 +0200
>Matus UHLAR - fantomas <uh...@fantomas.sk> wrote:
>> Note that the TTL is 3600 for both reverse and forward records.
>> There are blacklists that won'd delist your IP if your TTL is this
>> short, e.g. sorbs requirs at least 14400.
On 15.05.16 09:51, Dianne Skoll wrote:
>What, really? What's the rationale for that requirement? That a short
>TTL is "too dynamic"?
I guess they consider it suspect, if you can easily change it that many
times a day.
>That seems a little aggressive, IMO.
I don't think so. If you have a mail server, you don't change its DNS
records very often.
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
(R)etry, (A)bort, (C)ancer
Re: TTL on DNS records (was Re: understanding HELO_DYNAMIC_IPADDR)
Posted by Reindl Harald <h....@thelounge.net>.
Am 16.05.2016 um 02:26 schrieb Bill Cole:
> On 15 May 2016, at 9:51, Dianne Skoll wrote:
>
>> On Sun, 15 May 2016 13:25:34 +0200
>> Matus UHLAR - fantomas <uh...@fantomas.sk> wrote:
>>
>>> Note that the TTL is 3600 for both reverse and forward records.
>>> There are blacklists that won'd delist your IP if your TTL is this
>>> short, e.g. sorbs requirs at least 14400.
>
> According to http://www.sorbs.net/delisting/dul.shtml:
>
> Also, the Times to Live of the PTR records need to be 43200
> seconds or more. This is an arbitrary limit chosen by SORBS.
>
>> What, really? What's the rationale for that requirement? That a short
>> TTL is "too dynamic"?
>>
>> That seems a little aggressive, IMO.
>
> It's also VERY unevenly enforced. Amazon SES and Office365/Outlook.com
> outbounds emit substantial spam, have names that embed their last 1 or 2
> octets, and PTR TTL's of 900 and 3600 respectively. The MS sewer outlets
> HELO with names that resolve to IPs other than those they actually use,
> and the PTR on the IPs used typically resolve to a names with a zero
> TTL. SORBS will list these as spam sources but not as dynamic, so
> there's clearly some subjective judgment in use
easy to understand - the "dul.dnsbl.sorbs.net" is much heigher weighted
in most setups - here it has a postscreen-reject-score and a host there
needds to be on a least one common DNSWL to have any chance
well, and they are not dynamic machines - the distinction is not only
dynamic - the point is ENDUSER-MACHINE which has not point to connect to
a public MX at all (independent of how often the word static appear in
the PTR, a office-machine is not a mailserver and has no business on
port 25) versus a server
Re: TTL on DNS records (was Re: understanding HELO_DYNAMIC_IPADDR)
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 15 May 2016, at 9:51, Dianne Skoll wrote:
> On Sun, 15 May 2016 13:25:34 +0200
> Matus UHLAR - fantomas <uh...@fantomas.sk> wrote:
>
>> Note that the TTL is 3600 for both reverse and forward records.
>> There are blacklists that won'd delist your IP if your TTL is this
>> short, e.g. sorbs requirs at least 14400.
According to http://www.sorbs.net/delisting/dul.shtml:
Also, the Times to Live of the PTR records need to be 43200
seconds or more. This is an arbitrary limit chosen by SORBS.
> What, really? What's the rationale for that requirement? That a
> short
> TTL is "too dynamic"?
>
> That seems a little aggressive, IMO.
It's also VERY unevenly enforced. Amazon SES and Office365/Outlook.com
outbounds emit substantial spam, have names that embed their last 1 or 2
octets, and PTR TTL's of 900 and 3600 respectively. The MS sewer outlets
HELO with names that resolve to IPs other than those they actually use,
and the PTR on the IPs used typically resolve to a names with a zero
TTL. SORBS will list these as spam sources but not as dynamic, so
there's clearly some subjective judgment in use.
TTL on DNS records (was Re: understanding HELO_DYNAMIC_IPADDR)
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On Sun, 15 May 2016 13:25:34 +0200
Matus UHLAR - fantomas <uh...@fantomas.sk> wrote:
> Note that the TTL is 3600 for both reverse and forward records.
> There are blacklists that won'd delist your IP if your TTL is this
> short, e.g. sorbs requirs at least 14400.
What, really? What's the rationale for that requirement? That a short
TTL is "too dynamic"?
That seems a little aggressive, IMO.
Regards,
Dianne.
Re: understanding HELO_DYNAMIC_IPADDR
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
On 13.05.16 13:42, Robert Boyl wrote:
>Thanks a lot for your answer, sorry for confusion.
>
>But why add such a high score of 3,24 just before the host that sent my
>server mail is webmail-201.76.63.163.ig.com.br ?
>
>Its considered a dynamic IP? It isnt, its IGs server sending mail to our
>server.
163.63.76.201.in-addr.arpa. 3600 IN PTR webmail-201.76.63.163.ig.com.br.
webmail-201.76.63.163.ig.com.br. 3600 IN A 201.76.63.163
Note that the TTL is 3600 for both reverse and forward records.
There are blacklists that won'd delist your IP if your TTL is this short,
e.g. sorbs requirs at least 14400.
There are mailservers who have their own way of checking for generic DNS
(and ip.ip.ip.ip is sometimes one of them...)
Seems someone has done really bad job setting these DNS records.
You can blame spamassassin if you want, but the real way to fix this problem
is changing DNS records. You really should blame your ISP or hostmaster
instead of spamassassin.
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Christian Science Programming: "Let God Debug It!".
Re: understanding HELO_DYNAMIC_IPADDR
Posted by John Hardin <jh...@impsec.org>.
On Sat, 14 May 2016, Bill Cole wrote:
> 4. The fact that SA is probably not alone in detecting that as a dynamic name
> is no excuse. Note the relevant rule definition:
>
> meta HELO_DYNAMIC_IPADDR (__HELO_DYNAMIC_IPADDR && !HELO_STATIC_HOST)
>
> So a framework is already in place by which exceptions are made to the
> blanket arbitrary commandment that "Thou Shalt Not Embed IPs In Outbound Mail
> Server Names!" Currently that's trivial: there's one exception, for
> cmr-[IP].rogers.com names. I see no reason not to add an exception for
> webmail-[IP].ig.com.br names,
...or even webmail-.*
I expect no ISP is going to use "webmail" for their dynamic IP pool.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Democrats '61: Ask not what your country can do for you,
ask what you can do for your country.
Democrats '16: Ask not what your country can do for you,
demand it!
-----------------------------------------------------------------------
144 days since the first successful real return to launch site (SpaceX)
Re: understanding HELO_DYNAMIC_IPADDR
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 13 May 2016, at 15:29, Daniel J. Luke wrote:
> On May 13, 2016, at 2:26 PM, Kim Roar Fold�y Hauge <ki...@samfunnet.no>
> wrote:
>> This is NOT a practical solution. You can't expect administrators to
>> know about this problem, some styles of hostnames not playing well
>> with SA.
>
> Note that this isn't just a 'spamassassin' issue. You will likely
> experience delivery problems to many hosts as long as your dns or rdns
> 'looks like' a dynamic system.
>
> While you are at it, make sure your forward and reverse dns match.
1. Use of generic 2nd person is really inappropriate here. The DNS
involved isn't under the control of anyone in the conversation, so even
if we stipulate that something about the naming is bad and/or wrong,
there's no "you" here responsible for any error.
2. The original case in question of webmail-201.76.63.163.ig.com.br has
a perfectly find A record resolving to 201.76.63.163, which has a PTR
resolving back to webmail-201.76.63.163.ig.com.br. So the HELO name is
perfectly consistent with DNS. Nothing to fix there.
3. Yes, as a practical matter a mail system architect should be aware of
the fact that names which obviously embed IP addresses are viewed with
suspicion and avoid them. That's not an issue of principle, it is an
issue of recognizing the pragmatic fact that Sturgeon's Law applies to
the population of people deploying heuristic spam filters. A competing
pragmatic constraint: devising a scalable simple naming scheme for a
complex mail system with functionally identical machines whose only
obvious differentiator is each one's unique IP address.
4. The fact that SA is probably not alone in detecting that as a dynamic
name is no excuse. Note the relevant rule definition:
meta HELO_DYNAMIC_IPADDR (__HELO_DYNAMIC_IPADDR &&
!HELO_STATIC_HOST)
So a framework is already in place by which exceptions are made to the
blanket arbitrary commandment that "Thou Shalt Not Embed IPs In Outbound
Mail Server Names!" Currently that's trivial: there's one exception, for
cmr-[IP].rogers.com names. I see no reason not to add an exception for
webmail-[IP].ig.com.br names, as there is clearly an intent by whoever
created HELO_DYNAMIC_IPADDR to make it smarter than your average random
mail admin writing regexes.
Re: understanding HELO_DYNAMIC_IPADDR
Posted by David Jones <dj...@ena.com>.
>From: Daniel J. Luke <dl...@geeklair.net>
>Sent: Friday, May 13, 2016 3:42 PM
>To: David Jones
>Cc: Vincent Fox; users@spamassassin.apache.org
>Subject: Re: understanding HELO_DYNAMIC_IPADDR
>On May 13, 2016, at 4:24 PM, David Jones <dj...@ena.com> wrote:
>> This is a very simple concept and yet most mail admins don't know it or follow it.
>indeed.
>I haven't measured in a while, but the equivalent of postfix's 'reject_unknown_client_hostname' was the single >most-effective anti-spam measure I ever took (I had to stop using it to outright reject mail because of too many false >positives, though).
I did the same thing and it was wonderful but I too had to disable it
due to too many false positives. You would think that an informative
Postfix bounce message would be very clear to the sender so they
would contact their own IT person to get it fixed. But no, it was my
fault because I rejected the message.
Now I score RDNS_NONE high (~2 to 3 points) in SA which does almost
the same thing but allows for other negative scores to bring it back
down below the block threshold. This seems to be a pretty reliable
compromise.
>--
>Daniel J. Luke
Re: understanding HELO_DYNAMIC_IPADDR
Posted by "Daniel J. Luke" <dl...@geeklair.net>.
On May 13, 2016, at 4:24 PM, David Jones <dj...@ena.com> wrote:
> This is a very simple concept and yet most mail admins don't know it or follow it.
indeed.
I haven't measured in a while, but the equivalent of postfix's 'reject_unknown_client_hostname' was the single most-effective anti-spam measure I ever took (I had to stop using it to outright reject mail because of too many false positives, though).
--
Daniel J. Luke
Re: understanding HELO_DYNAMIC_IPADDR
Posted by Vincent Fox <vb...@ucdavis.edu>.
On 05/13/2016 01:24 PM, David Jones wrote:
> This is a very simple concept and yet most mail admins don't know it
> or follow it.
I know right? IMO network/firewall backgrounds are worse though.
They are used to thinking in IP all day and DNS is just this
optional convenience.
Cheers.
Re: understanding HELO_DYNAMIC_IPADDR
Posted by David Jones <dj...@ena.com>.
>________________________________________
>From: Vincent Fox <vb...@ucdavis.edu>
>Sent: Friday, May 13, 2016 2:57 PM
>To: users@spamassassin.apache.org
>Subject: Re: understanding HELO_DYNAMIC_IPADDR
>On 05/13/2016 12:29 PM, Daniel J. Luke wrote:
>>
>> While you are at it, make sure your forward and reverse dns match.
>>
>At least weekly, I get someone bickering with me that reverse DNS is not any
>kind of requirement to be a legitimate server.
>Often it comes from well-paid network administrators.
>It's Friday, time to go have a beer and forget about how
>conventions and basic internet plumbing are TOO HARD
>for some people.
Think of the PTR record on a mail server like caller ID. If your PTR record
doesn't match an A record, then most mail servers will penalize your
mail to some degree because it looks like "caller blocked" or "unknown
caller". Do you answer phone calls like these? I don't.
My mail servers send millions of emails a week out to the Internet and
have some very spammy looking stuff coming from some of our customers
because the software they are using to send emails is horrible with
missing headers, bad timestamps, no unsubscribe process, etc. But
I don't have any issues with recipient mail servers blocking or rejecting
because I have proper FCrDNS (PTR and A record complements). This is
a very simple concept and yet most mail admins don't know it or follow it.
I often have to work around incoming mail problems because the sending
mail server isn't setup properly to be trusted by the Internet.
http://multirbl.valli.org/lookup (See FCrDNS)
https://www.rackaid.com/blog/email-dns-records/
https://senderscore.org/lookup.php
Dave
Re: understanding HELO_DYNAMIC_IPADDR
Posted by Vincent Fox <vb...@ucdavis.edu>.
On 05/13/2016 12:29 PM, Daniel J. Luke wrote:
>
> While you are at it, make sure your forward and reverse dns match.
>
At least weekly, I get someone bickering with me that reverse DNS is not any
kind of requirement to be a legitimate server.
Often it comes from well-paid network administrators.
It's Friday, time to go have a beer and forget about how
conventions and basic internet plumbing are TOO HARD
for some people.
Re: understanding HELO_DYNAMIC_IPADDR
Posted by "Daniel J. Luke" <dl...@geeklair.net>.
On May 13, 2016, at 2:26 PM, Kim Roar Foldøy Hauge <ki...@samfunnet.no> wrote:
> This is NOT a practical solution. You can't expect administrators to know about this problem, some styles of hostnames not playing well with SA.
Note that this isn't just a 'spamassassin' issue. You will likely experience delivery problems to many hosts as long as your dns or rdns 'looks like' a dynamic system.
While you are at it, make sure your forward and reverse dns match.
--
Daniel J. Luke
Re: understanding HELO_DYNAMIC_IPADDR
Posted by Reindl Harald <h....@thelounge.net>.
Am 14.05.2016 um 04:14 schrieb Kim Roar Foldøy Hauge:
> On Sat, 14 May 2016, Reindl Harald wrote:
>
>> Am 13.05.2016 um 20:26 schrieb Kim Roar Foldøy Hauge:
>>> On Fri, 13 May 2016, Joe Quinn wrote:
>>> > The solution is to give your mail servers better hostnames that clue
>>> > into the narrower scope of their purpose.
>>>
>>> This is NOT a practical solution. You can't expect administrators to
>>> know about this problem, some styles of hostnames not playing well
>>> with SA
>>
>> then they *really* should not call themself mail-administrators
>
> I administer mail, web and other things. I do not have control over
> reverse dns. Not every mail admin can change the reverse dns of their
> servers.
but your ISP can and if your ISP refuses to do so it's just the wrong
ISP for running a public mail sever
there is not much to discuss
a proper A-record matching the PTR matching your "smtp_helo_name" is the
first thing you verify for a proper mailserver *before* you consider
sending mails out to the world and that is common sense for at least 10
years now
Re: understanding HELO_DYNAMIC_IPADDR
Posted by Kim Roar Foldøy Hauge <ki...@samfunnet.no>.
On Sat, 14 May 2016, Reindl Harald wrote:
>
>
> Am 13.05.2016 um 20:26 schrieb Kim Roar Fold�y Hauge:
>> On Fri, 13 May 2016, Joe Quinn wrote:
>> > The solution is to give your mail servers better hostnames that clue
>> > into the narrower scope of their purpose.
>>
>> This is NOT a practical solution. You can't expect administrators to
>> know about this problem, some styles of hostnames not playing well with SA
>
> then they *really* should not call themself mail-administrators
>
I administer mail, web and other things. I do not have control over
reverse dns. Not every mail admin can change the reverse dns of their
servers.
>
>
>
>
--
Kim Roar Fold�y Hauge
Event:Presse - The Gathering 2016
webmaster@samfunnet.no
Root@HC,HX,JH,LZ,OT,P,VH
Re: understanding HELO_DYNAMIC_IPADDR
Posted by Reindl Harald <h....@thelounge.net>.
Am 13.05.2016 um 20:26 schrieb Kim Roar Foldøy Hauge:
> On Fri, 13 May 2016, Joe Quinn wrote:
>> The solution is to give your mail servers better hostnames that clue
>> into the narrower scope of their purpose.
>
> This is NOT a practical solution. You can't expect administrators to
> know about this problem, some styles of hostnames not playing well with SA
then they *really* should not call themself mail-administrators
Re: understanding HELO_DYNAMIC_IPADDR
Posted by Kim Roar Foldøy Hauge <ki...@samfunnet.no>.
On Fri, 13 May 2016, Joe Quinn wrote:
> SA uses IP-in-name as a machine-decidable definition of a dynamic IP, since you can't really automate it otherwise. This heuristic holds
> in the vast majority of cases, and is effective against a huge class of spam that comes from public ISPs who don't block port 25.
>
It fails in this case, so a fix should be implemented if possible.
> An ISP's customers are generally going to have hosts like ipXXX-XXX-XXX-XXX.city.region.isp.net, and the name includes their IP because
> simply being an IP address is that host's purpose. That same ISP's mail servers are going to have hostnames like mail-15.isp.net. It's
> more specific because the list of mail servers is far smaller than the list of IPs, and this is the 15th of them.
>
> The solution is to give your mail servers better hostnames that clue into the narrower scope of their purpose.
>
This is NOT a practical solution. You can't expect administrators to know
about this problem, some styles of hostnames not playing well with SA.
A possible remedy for this specific case would be to add a check if the
hostname also contains the strings "webmail[-.]" or "mail[.-]".
This fixes this specific case, and possibly other cases. Does anyone know
about any hostnames with such string in them that aren't mail servers?
--
Kim Roar Fold�y Hauge
Event:Presse - The Gathering 2016
webmaster@samfunnet.no
Root@HC,HX,JH,LZ,OT,P,VH
Re: understanding HELO_DYNAMIC_IPADDR
Posted by Joe Quinn <jq...@pccc.com>.
SA uses IP-in-name as a machine-decidable definition of a dynamic IP,
since you can't really automate it otherwise. This heuristic holds in
the vast majority of cases, and is effective against a huge class of
spam that comes from public ISPs who don't block port 25.
An ISP's customers are generally going to have hosts like
ipXXX-XXX-XXX-XXX.city.region.isp.net, and the name includes their IP
because simply being an IP address is that host's purpose. That same
ISP's mail servers are going to have hostnames like mail-15.isp.net.
It's more specific because the list of mail servers is far smaller than
the list of IPs, and this is the 15th of them.
The solution is to give your mail servers better hostnames that clue
into the narrower scope of their purpose.
On 5/13/2016 12:42 PM, Robert Boyl wrote:
> Thanks a lot for your answer, sorry for confusion.
>
> But why add such a high score of 3,24 just before the host that sent
> my server mail is webmail-201.76.63.163.ig.com.br
> <http://webmail-201.76.63.163.ig.com.br> ?
>
> Its considered a dynamic IP? It isnt, its IGs server sending mail to
> our server.
>
> Can I ask Spamassassin folks to improve this?
>
> Thanks
>
> 2016-05-01 11:06 GMT-03:00 RW <rwmaillists@googlemail.com
> <ma...@googlemail.com>>:
>
> On Sun, 1 May 2016 10:20:09 -0300
> Robert Boyl wrote:
>
> > Hi, everyone
> >
> > Ive seen some discussion in Spamassassin's bugzilla about this
> > HELO_DYNAMIC_IPADDR rule, some unanswered over years.
> >
> > It says in description: # (require an alpha first, as legit
> > HELO'ing-as-IP-address is hit otherwise)
> >
> > Is it talking about the host that first appears, that sent the email
> > authenticated to his ISP or the host/ISP that delivers to our
> server?
>
> The latter.
>
> > This is the host that delivered mail to my ISP:
> >
> > Received: from webmail-201.76.63.163.ig.com.br
> <http://webmail-201.76.63.163.ig.com.br> (
> > webmail-201.76.63.163.ig.com.br
> <http://webmail-201.76.63.163.ig.com.br> [201.76.63.163
> <tel:%5B201.76.63.163>]) by mx3.myisp.com <http://mx3.myisp.com> with
> > ESMTP id rDrGtcYe1PdHDBfh; Wed, 06 Apr 2016 09:02:10 -0400 (EDT)
> > X-Barracuda-Envelope-From: some-sender@ig.com.br
> <ma...@ig.com.br>
> >
>
> > I dont understand, since IMHO it shouldnt matter the host that sent
> > mail to its ISP, if its dynamic or not. IMHO what should matter is
> > the ISP sending mail to our ISP and in that case, the host does NOT
> > start with a number.
>
> It not about whether it start with number. The comment you quoted is
> "require an alpha first", and alpha means a letter.
>
>
> webmail-201.76.63.163.ig.com.br
> <http://webmail-201.76.63.163.ig.com.br> starts with a letter and
> contains an IP
> address.
>
>
Re: understanding HELO_DYNAMIC_IPADDR
Posted by Robert Boyl <ro...@gmail.com>.
Thanks a lot for your answer, sorry for confusion.
But why add such a high score of 3,24 just before the host that sent my
server mail is webmail-201.76.63.163.ig.com.br ?
Its considered a dynamic IP? It isnt, its IGs server sending mail to our
server.
Can I ask Spamassassin folks to improve this?
Thanks
2016-05-01 11:06 GMT-03:00 RW <rw...@googlemail.com>:
> On Sun, 1 May 2016 10:20:09 -0300
> Robert Boyl wrote:
>
> > Hi, everyone
> >
> > Ive seen some discussion in Spamassassin's bugzilla about this
> > HELO_DYNAMIC_IPADDR rule, some unanswered over years.
> >
> > It says in description: # (require an alpha first, as legit
> > HELO'ing-as-IP-address is hit otherwise)
> >
> > Is it talking about the host that first appears, that sent the email
> > authenticated to his ISP or the host/ISP that delivers to our server?
>
> The latter.
>
> > This is the host that delivered mail to my ISP:
> >
> > Received: from webmail-201.76.63.163.ig.com.br (
> > webmail-201.76.63.163.ig.com.br [201.76.63.163]) by mx3.myisp.com with
> > ESMTP id rDrGtcYe1PdHDBfh; Wed, 06 Apr 2016 09:02:10 -0400 (EDT)
> > X-Barracuda-Envelope-From: some-sender@ig.com.br
> >
>
> > I dont understand, since IMHO it shouldnt matter the host that sent
> > mail to its ISP, if its dynamic or not. IMHO what should matter is
> > the ISP sending mail to our ISP and in that case, the host does NOT
> > start with a number.
>
> It not about whether it start with number. The comment you quoted is
> "require an alpha first", and alpha means a letter.
>
>
> webmail-201.76.63.163.ig.com.br starts with a letter and contains an IP
> address.
>
Re: understanding HELO_DYNAMIC_IPADDR
Posted by RW <rw...@googlemail.com>.
On Sun, 1 May 2016 10:20:09 -0300
Robert Boyl wrote:
> Hi, everyone
>
> Ive seen some discussion in Spamassassin's bugzilla about this
> HELO_DYNAMIC_IPADDR rule, some unanswered over years.
>
> It says in description: # (require an alpha first, as legit
> HELO'ing-as-IP-address is hit otherwise)
>
> Is it talking about the host that first appears, that sent the email
> authenticated to his ISP or the host/ISP that delivers to our server?
The latter.
> This is the host that delivered mail to my ISP:
>
> Received: from webmail-201.76.63.163.ig.com.br (
> webmail-201.76.63.163.ig.com.br [201.76.63.163]) by mx3.myisp.com with
> ESMTP id rDrGtcYe1PdHDBfh; Wed, 06 Apr 2016 09:02:10 -0400 (EDT)
> X-Barracuda-Envelope-From: some-sender@ig.com.br
>
> I dont understand, since IMHO it shouldnt matter the host that sent
> mail to its ISP, if its dynamic or not. IMHO what should matter is
> the ISP sending mail to our ISP and in that case, the host does NOT
> start with a number.
It not about whether it start with number. The comment you quoted is
"require an alpha first", and alpha means a letter.
webmail-201.76.63.163.ig.com.br starts with a letter and contains an IP
address.