On Tue, 17 May 2016 21:42:15 +0200
Reindl Harald 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.
Am 17.05.2016 um 20:19 schrieb Dianne Skoll:
On Tue, 17 May 2016 18:50:29 +0200
Reindl Harald 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 no
On Tue, 17 May 2016 18:50:29 +0200
Reindl Harald 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 be
Am 17.05.2016 um 17:25 schrieb Dianne Skoll:
On Tue, 17 May 2016 17:14:37 +0200
Reindl Harald 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
On 16 May 2016, at 10:24, jdebert wrote:
On Mon, 16 May 2016 12:25:10 +0100
Dominic Benson 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 f
On Tue, 17 May 2016 17:14:37 +0200
Reindl Harald 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
Am 16.05.2016 um 16:24 schrieb jdebert:
On Mon, 16 May 2016 12:25:10 +0100
Dominic Benson 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 f
On Mon, 16 May 2016 12:25:10 +0100
Dominic Benson 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 re
On 16/05/16 12:10, Dianne Skoll wrote:
> On Mon, 16 May 2016 09:12:54 +0200
> Matus UHLAR - fantomas 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
On Mon, 16 May 2016 09:12:54 +0200
Matus UHLAR - fantomas 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 rangin
>That seems a little aggressive, IMO.
On Sun, 15 May 2016 18:08:31 +0200
Matus UHLAR - fantomas 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 wi
On Sun, 15 May 2016 18:08:31 +0200
Matus UHLAR - fantomas 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 o
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 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,
On 15 May 2016, at 9:51, Dianne Skoll wrote:
On Sun, 15 May 2016 13:25:34 +0200
Matus UHLAR - fantomas 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.
Accordin
On Sun, 15 May 2016 13:25:34 +0200
Matus UHLAR - fantomas 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? W
On Sun, 15 May 2016 13:25:34 +0200
Matus UHLAR - fantomas 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 require
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.
16
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 ex
calable 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_
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 t
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 c
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 prob
>From: Daniel J. Luke
>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 wrote:
>> This is a very simple concept and yet most mail
On May 13, 2016, at 4:24 PM, David Jones 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
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.
>
>From: Vincent Fox
>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 sur
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.
On May 13, 2016, at 2:26 PM, Kim Roar Foldøy Hauge 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 pr
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 bloc
this?
Thanks
2016-05-01 11:06 GMT-03:00 RW <mailto:rwmailli...@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,
this?
Thanks
2016-05-01 11:06 GMT-03:00 RW :
> 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.
> &g
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
> HEL
On Thu, 2010-10-28 at 11:25 +0200, Angel L. Mateo wrote:
> We are having a problema with one of our users that all his email was
> marked as spam. The problem is that all his emails has the
> HELO_DYNAMIC_IPADDR (or HELO_DYNAMIC_IPADDR2) check, because
> spamassassin thinks that th
most-human-readable way to represent them. It is valid to
represent an IPv4 address as a 32-bit hex value.
On 08.11.10 11:51, Angel L. Mateo wrote:
I know this, but is '72d07e260c444a7' an IP address? Not for me, but
for HELO_DYNAMIC_IPADDR it is.
Are you sure it's the
ost-human-readable way to represent them. It is valid to
represent an IPv4 address as a 32-bit hex value.
I know this, but is '72d07e260c444a7' an IP address? Not for me, but
for HELO_DYNAMIC_IPADDR it is.
...good point. A valid IPv4 would only be 8 hex digits.
--
John
readable way to represent them. It is valid to
>> represent an IPv4 address as a 32-bit hex value.
On 08.11.10 11:51, Angel L. Mateo wrote:
> I know this, but is '72d07e260c444a7' an IP address? Not for me, but
> for HELO_DYNAMIC_IPADDR it is.
Are you sure it's t
valid to
represent an IPv4 address as a 32-bit hex value.
I know this, but is '72d07e260c444a7' an IP address? Not for me, but
for HELO_DYNAMIC_IPADDR it is.
--
Angel L. Mateo Martínez
Sección de Telemática
Área de Tecnologías de la Información _o)
y las Comunicaciones Aplica
On Thu, 28 Oct 2010, Angel L. Mateo wrote:
Is there any reason for this pattern being so general? Or this is a
bug?
IPv4 addresses are numbers (uint4 to be precise), dotted quad notation is
just the most-human-readable way to represent them. It is valid to
represent an IPv4 address as a 32-
Hello,
We are having a problema with one of our users that all his email was
marked as spam. The problem is that all his emails has the
HELO_DYNAMIC_IPADDR (or HELO_DYNAMIC_IPADDR2) check, because
spamassassin thinks that the connection used the IP address in the helo
commando, but not
Matus UHLAR - fantomas a écrit :
>>> On 19.08.09 00:48, mouss wrote:
The name of the rule is worng, but the result is ok. Instead of
"dynamic", I suggest: "UMO" for "Unidentifiable Mailing Object". whether
static-ip- is static or not doesn't matter. a lot of junk comes from
> > On 19.08.09 00:48, mouss wrote:
> >> The name of the rule is worng, but the result is ok. Instead of
> >> "dynamic", I suggest: "UMO" for "Unidentifiable Mailing Object". whether
> >> static-ip- is static or not doesn't matter. a lot of junk comes from
> >> such hosts, and we can't report/c
Matus UHLAR - fantomas a écrit :
>> Bob Proulx a écrit :
>>> The following header line:
>>>
>>> Received: from static-96-254-126-11.tampfl.fios.verizon.net
>>> [96.254.126.11] by
>>> windows12.uvault.com with SMTP; Wed, 12 Aug 2009
> Bob Proulx a écrit :
> > The following header line:
> >
> > Received: from static-96-254-126-11.tampfl.fios.verizon.net
> > [96.254.126.11] by
> > windows12.uvault.com with SMTP; Wed, 12 Aug 2009 08:26:40 -0400
> >
> > Hits the HE
Michael Scheidell wrote:
> if this is a client of yours, you might help them get a VALID RDNS and
> setup the FQDN for their mail server.
> (more likely, its a zombie spambot anyway, )
Not related to me in any way. The mail message generated from there
was legitimate. It came *to* a client of
Bob Proulx a écrit :
> The following header line:
>
> Received: from static-96-254-126-11.tampfl.fios.verizon.net [96.254.126.11]
> by
> windows12.uvault.com with SMTP; Wed, 12 Aug 2009 08:26:40 -0400
>
> Hits the HELO_DYNAMIC_IPADDR rule. I tested it this w
On Tue, 18 Aug 2009 16:51:46 +0200
Per Jessen wrote:
> Matus UHLAR - fantomas wrote:
>
> > another serious question: should IPs with statically assigned IP
> > addresses get the same processing as if they were dynamically
> > assigned?
>
> Probably not, but there's no guaranteed way of telling
> Matus UHLAR - fantomas wrote:
> > another serious question: should IPs with statically assigned IP
> > addresses get the same processing as if they were dynamically
> > assigned?
On 18.08.09 16:51, Per Jessen wrote:
> Probably not, but there's no guaranteed way of telling them apart.
there is
Matus UHLAR - fantomas wrote:
> another serious question: should IPs with statically assigned IP
> addresses get the same processing as if they were dynamically
> assigned?
Probably not, but there's no guaranteed way of telling them apart.
> Of course it's much better to have personalised DNS n
> Bob Proulx wrote:
>> The following header line:
>>
>> Received: from static-96-254-126-11.tampfl.fios.verizon.net
>> [96.254.126.11] by
>> windows12.uvault.com with SMTP; Wed, 12 Aug 2009 08:26:40 -0400
>>
>> Hits the HELO_DYNAMIC_IPADD
Bob Proulx wrote:
The following header line:
Received: from static-96-254-126-11.tampfl.fios.verizon.net
[96.254.126.11] by
windows12.uvault.com with SMTP; Wed, 12 Aug 2009 08:26:40 -0400
Hits the HELO_DYNAMIC_IPADDR rule. I tested it this way:
$ perl -le 'if ("sta
The following header line:
Received: from static-96-254-126-11.tampfl.fios.verizon.net [96.254.126.11] by
windows12.uvault.com with SMTP; Wed, 12 Aug 2009 08:26:40 -0400
Hits the HELO_DYNAMIC_IPADDR rule. I tested it this way:
$ perl -le 'if ("static-96-
de (most clients will use
> the local hostname for the HELO), or check your MTA or mail client
> program docs for how to explicitly specify what it says in the HELO.
>
> That said, I would observe that HELO_DYNAMIC_IPADDR probably shouldn't
> fire on a HELO containing the
you should either verify that
your hostname is set to server.marcelkorte.de (most clients will use
the local hostname for the HELO), or check your MTA or mail client
program docs for how to explicitly specify what it says in the HELO.
That said, I would observe that HELO_DYNAMIC_IPADDR probably should
hosteurope.de".
But still. I don´t understand where that might come frome since nslookup
87.230.7.51 shows the correct hostname server.marcelkorte.de.
Daryl C. W. O wrote:
>
> DogMatz wrote:
>> Emails from one of my accounts often get the HELO_DYNAMIC_IPADDR but I
>> can´t
DogMatz wrote:
Emails from one of my accounts often get the HELO_DYNAMIC_IPADDR but I can´t
see why!
Nor can we since you didn't include the headers from the actual message
scanned, rather just the report_safe encapsulation headers.
Daryl
Check this mail:
Received: from localho
Emails from one of my accounts often get the HELO_DYNAMIC_IPADDR but I can´t
see why!
Check this mail:
Received: from localhost by webbox413.server-home.net
with SpamAssassin (version 3.1.3);
Tue, 08 May 2007 15:52:01 +0200
From: Marcel Korte <[EMAIL PROTECTED]>
To:
Wolfgang Jeltsch wrote:
> Am Montag, 2. April 2007 17:09 schrieb Scott Lockwood:
>
>> On Mon, 2007-04-02 at 17:01 +0200, Wolfgang Jeltsch wrote:
>>
>>> I’m sending my mails via my DSL provider’s SMTP server.
>>>
>> Which puts in the headers that it came from a node in it's network,
>
tion as sending the
mail via my DSL provider’s SMTP server.
Meanwhile I realized that not every mail I send the way I described suffers
from the HELO_DYNAMIC_IPADDR problem but the mail I attached to my other
message to this list does. Can anyone figure out what the problem with
exactly this
On Mon, 2007-04-02 at 17:01 +0200, Wolfgang Jeltsch wrote:
> I’m sending my mails via my DSL provider’s SMTP server.
Which puts in the headers that it came from a node in it's network,
which makes the machine the mail originated from, you guessed it, one
that has a dynamic IP address.
Your best b
Am Montag, 2. April 2007 17:01 schrieb Wolfgang Jeltsch:
> Hello,
>
> what does HELO_DYNAMIC_IPADDR mean? Why is it rated that high?
>
> The reason behind my question is that most of my e-mails seem to get
> HELO_DYNAMIC_IPADDR assigned to them.
Okay, maybe not most of them.
Hello,
what does HELO_DYNAMIC_IPADDR mean? Why is it rated that high?
The reason behind my question is that most of my e-mails seem to get
HELO_DYNAMIC_IPADDR assigned to them. In the From: field, I typically use an
address which belongs to a domain registered by me and pointing to my own
John Andersen wrote:
On Thursday 23 November 2006 00:32, Nigel Frankcom wrote:
t's worth hassling your ISP. If they want to sell 'business' packages
then an rDNS *should* be part of the deal (imo). If your current ISP
won't do it, switch to one that will, they are out there. I'm
surprised none s
On Thursday 23 November 2006 00:32, Nigel Frankcom wrote:
> t's worth hassling your ISP. If they want to sell 'business' packages
> then an rDNS *should* be part of the deal (imo). If your current ISP
> won't do it, switch to one that will, they are out there. I'm
> surprised none seem to use it as
On Thu, 23 Nov 2006 00:15:16 -0900, John Andersen <[EMAIL PROTECTED]>
wrote:
>On Wednesday 22 November 2006 22:04, Bob Proulx wrote:
>> But in this case it is an example of poor form for the forward and
>> reverse dns not to match. If you are running a mail server this is
>> one of the things tha
On Wednesday 22 November 2006 22:04, Bob Proulx wrote:
> But in this case it is an example of poor form for the forward and
> reverse dns not to match. If you are running a mail server this is
> one of the things that should be set up properly for it. When that is
> fixed then the rule won't trig
wrote:
> | messju mohr wrote:
> | > mails from our host 80.237.202.55
> (ds80-237-202-55.dedicated.hosteurope.de)
> | > are tagged as HELO_DYNAMIC_IPADDR. Said IP is not dynamic, it's a
> | > dedicated server hosted at german ISP (Host Europe GmbH).
> |
| messju mohr wrote:
| > Hello,
| >
| > mails from our host 80.237.202.55 (ds80-237-202-55.dedicated.hosteurope.de)
| > are tagged as HELO_DYNAMIC_IPADDR. Said IP is not dynamic, it's a
| > dedicated server hosted at german ISP (Host Europe GmbH).
| >
| > How can we get
messju mohr wrote:
> Hello,
>
> mails from our host 80.237.202.55 (ds80-237-202-55.dedicated.hosteurope.de)
> are tagged as HELO_DYNAMIC_IPADDR. Said IP is not dynamic, it's a
> dedicated server hosted at german ISP (Host Europe GmbH).
>
> How can we get our hos
On Wed, Nov 22, 2006 at 03:39:43PM +, Justin Mason wrote:
>
> messju mohr writes:
> > mails from our host 80.237.202.55 (ds80-237-202-55.dedicated.hosteurope.de)
> > are tagged as HELO_DYNAMIC_IPADDR. Said IP is not dynamic, it's a
> > dedicated server hosted at
messju mohr writes:
> mails from our host 80.237.202.55 (ds80-237-202-55.dedicated.hosteurope.de)
> are tagged as HELO_DYNAMIC_IPADDR. Said IP is not dynamic, it's a
> dedicated server hosted at german ISP (Host Europe GmbH).
>
> How can we get our host removed from the
Hello,
mails from our host 80.237.202.55 (ds80-237-202-55.dedicated.hosteurope.de)
are tagged as HELO_DYNAMIC_IPADDR. Said IP is not dynamic, it's a
dedicated server hosted at german ISP (Host Europe GmbH).
How can we get our host removed from the list of DYNAMIC_IPS?
thanks in advance
messju
Steven Dickenson wrote:
On Oct 18, 2006, at 11:47 AM, Ugo Bellavance wrote:
This should be fixed, as many Videotron clients purchase a static IP
address to have their own mail server. This service also comes with
all ports open (dynamic has port 25 blocked in/out), so they are
almose telling
On Oct 18, 2006, at 11:47 AM, Ugo Bellavance wrote:
This should be fixed, as many Videotron clients purchase a static
IP address to have their own mail server. This service also comes
with all ports open (dynamic has port 25 blocked in/out), so they
are almose telling their clients to deli
Hi,
An ISP in canada, Videotron, hits this rule with the RDNS of their new
offering: Static IP addresses on cable modem.
RDNS:
Dynamic:
modemcable002.152-81-70.mc.videotron.ca.
Static:
modemcable014.58-70-69.static.videotron.ca
This should be fixed, as many Videotron clients purchase a st
On Thu, 17 Aug 2006, Chris Thielen wrote:
So it seems the root of my problem is that users are connecting to the office
smtp server (also our primary MX) without authentication. That seems to be a
legitimate hit for the dynamic ip lists. However it is also the only
legitimate smtp server for
Chris Thielen wrote:
So it seems the root of my problem is that users are connecting to the
office smtp server (also our primary MX) without authentication. That
seems to be a legitimate hit for the dynamic ip lists. However it is
also the only legitimate smtp server for these people to use.
Oooh, reply to multiple emails at once? I so crzy!
jdow wrote:
For brute force solutions you could use whitelist_from_rcvd. But even
that
is "awkward". Is your office server on your trusted list?
Yeah, I tried with and without the office server on the trusted list
with no apparent chang
Chris Thielen wrote:
Thanks for the response.
Benny Pedersen wrote:
1.4 SPF_SOFTFAIL SPF: sender does not match SPF record
(softfail)
[SPF failed: Please see
http://spf.pobox.com/why.html?sender=blahblahblah]
update Mail::SPF::Query
domain is not pobox but openspf
duly noted
mail server (office) <-- fetchmail (home) <--
spamassassin
When a message of this sort is retrieved, I get these rule hits:
4.2 HELO_DYNAMIC_IPADDRRelay HELO'd using suspicious hostname (IP addr
1)
1.4 SPF_SOFTFAIL SPF: sender does not match SPF
Thanks for the response.
Benny Pedersen wrote:
1.4 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
[SPF failed: Please see http://spf.pobox.com/why.html?sender=blahblahblah]
update Mail::SPF::Query
domain is not pobox but openspf
duly noted... I am using debian
On Wed, August 16, 2006 18:16, Chris Thielen wrote:
> CoWorker (dialup) --> mail server (office) <-- fetchmail (home) <--
you can make fetchmail so it does not add the its own recieved headers
> 1.4 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
> [SPF failed: Please se
massassin
When a message of this sort is retrieved, I get these rule hits:
4.2 HELO_DYNAMIC_IPADDRRelay HELO'd using suspicious hostname (IP addr
1)
1.4 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
[SPF failed: Please see http://spf.pobo
Matt Kettler wrote:
Received: from FOOBAR (adsl-xx-xx-xx-xx.dsl.pltn13.pacbell.net
[xx.xx.xx.xx]) by
> mail1..com with SMTP; Tue, 18 Oct 2005 15:36:54 -0600
It doesn't like it when the HELLO is
adsl-xx-xx-xx-xx.dsl.pltn13.pacbell.netWhy?
Because a trusted host shouldn't be recei
Mark London wrote:
> Hi - spamassassin is running on psfcsv1.psfc.mit.edu (has been for
> several years, with same configuration)/
Ok, does psfcsv1.psfc.mit.edu resolve psfcsv1.psfc.mit.edu to a reserved IP?
>I don't use trusted_networks.
Ok, so you use the auto-guessed trusted_networks list.
Thanks for the info!
Daryl C. W. O'Shea wrote:
Mark London wrote:
Mark London wrote:
Mark London wrote:
Hi - We are receiving mail from a site that includes the headers:
This causes spamassassin to flag it with:
HELO_DYNAMIC_DHCP HELO_DYNAMIC_HCC HELO_DYNAMIC_IPADDR
Rec
Mark London wrote:
Mark London wrote:
Mark London wrote:
Hi - We are receiving mail from a site that includes the headers:
This causes spamassassin to flag it with:
HELO_DYNAMIC_DHCP HELO_DYNAMIC_HCC HELO_DYNAMIC_IPADDR
Received: from mail1.easyasphosting.com
t 2005 18:07:52 -0400
Received: from adsl-xx-xx-xx-xx.dsl.pltn13.pacbell.net [xx.xx.xx.xx] by
mail1..com with SMTP; Tue, 18 Oct 2005 15:36:54 -0600
This causes spamassassin to flag it with:
HELO_DYNAMIC_DHCP HELO_DYNAMIC_HCC HELO_DYNAMIC_IPADDR
This easily causes a very high spam
it with:
HELO_DYNAMIC_DHCP HELO_DYNAMIC_HCC HELO_DYNAMIC_IPADDR
1) do you have a trusted_networks setting? If so, does it include
"mail1.xxx.com"? If so, are you sure you what to?
2) If you don't have a trusted_networks setting, what would the spamassassin
system resolve the IP address o
ue, 18 Oct 2005 18:07:52 -0400
> Received: from adsl-xx-xx-xx-xx.dsl.pltn13.pacbell.net [xx.xx.xx.xx] by
> mail1..com with SMTP; Tue, 18 Oct 2005 15:36:54 -0600
>
> This causes spamassassin to flag it with:
>
> HELO_DYNAMIC_DHCP HELO_DYNAMIC_HCC HELO_DYNAMIC_IPADDR
1) do
-0400
Received: from adsl-xx-xx-xx-xx.dsl.pltn13.pacbell.net [xx.xx.xx.xx] by
mail1..com with SMTP; Tue, 18 Oct 2005 15:36:54 -0600
This causes spamassassin to flag it with:
HELO_DYNAMIC_DHCP HELO_DYNAMIC_HCC HELO_DYNAMIC_IPADDR
This easily causes a very high spam score. I've never
-xx-xx-xx.dsl.pltn13.pacbell.net [xx.xx.xx.xx] by
mail1..com with SMTP; Tue, 18 Oct 2005 15:36:54 -0600
This causes spamassassin to flag it with:
HELO_DYNAMIC_DHCP HELO_DYNAMIC_HCC HELO_DYNAMIC_IPADDR
This easily causes a very high spam score. I've never seen these
tests
In an older episode (Saturday, 27. August 2005 19:24), Robert Menschel wrote:
> If you can send me the full email, with headers, so I can compose a
> whitelist_from_rcvd rule for it, and if you are personally certain
> they do not send spam from that From address, I'll add an entry for
> them into
Hello wolfgang,
Saturday, August 27, 2005, 3:50:20 AM, you wrote:
w> we received a Duden newsletter (duden is *the* spelling
w> rules/grammar/dictionary publisher in germany) with the header:
Wolfgang,
If you can send me the full email, with headers, so I can compose a
whitelist_from_rcvd rule
de (DesyMail_In_27) with ESMTP id 3B5D6FB90A
>for ; Fri, 26 Aug 2005 17:00:38 +0200 (MEST)
>
>It got, among others, the scores
>4.4 HELO_DYNAMIC_IPADDR
>2.2 DCC_CHECK
>2.4 MIME_HTML_ONLY_MULTI
>
>This makes me wonder if HELO_DYNAMIC_IPADDR should get a lower score in
3B5D6FB90A
for ; Fri, 26 Aug 2005 17:00:38 +0200 (MEST)
It got, among others, the scores
4.4 HELO_DYNAMIC_IPADDR
2.2 DCC_CHECK
2.4 MIME_HTML_ONLY_MULTI
This makes me wonder if HELO_DYNAMIC_IPADDR should get a lower score in SA in
general - I have now lowered it's score in our set
22.253])
by webmail.fingerprint.fr (IMP) with HTTP
for <[EMAIL PROTECTED]>; Wed, 15 Jun 2005 11:05:03 +0200
X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on mx.fprt.com
X-Spam-Status: Yes, score=6.6 required=5.5 tests=HELO_DYNAMIC_IPADDR,
YES
X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on mx.fprt.com
X-Spam-Report:
* 2.8 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP
addr
1)
* 1.7 RCVD_IN_NJABL_DUL RBL: NJABL: dialup sender did non-local SMTP
* [80.13.222.253 liste
On Fri, 28 Jan 2005, Matt Kettler wrote:
> > The order and spacing of the items after the from keyword is wrong. The
> > specification for Received: lines is in RFC 2821. A correctly formatted
> > line would be something like
> >
> > Received: from hotmail.com (bay22-dav1.bay22.hotmail.com
> > [64
On Mon, 31 Jan 2005, Ole Nomann Thomsen wrote:
>
> So I don't feel able to bugzilla this one - any takers?
It isn't a bug in SpamAssassin.
Tony.
--
f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/
FAEROES: NORTHWEST 5 TO 7, OCCASIONALLY VARIABLE 3 OR 4 FOR A TIME. RAIN AT
TIMES. MODERATE OR GO
Justin Mason wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> Matt Kettler writes:
>> At 09:23 AM 1/28/2005, Tony Finch wrote:
>> > > Hi, it seems that HELO_DYNAMIC_IPADDR fires wrongly on this header:
>> > >
>> > > Recei
1 - 100 of 112 matches
Mail list logo
