Yes, I saw it - there seems to be a call stack level and error handling
problem with Error.pm.
I'm just working on that.
Thomas
Von:"Daniel L. Miller"
An: assp-test@lists.sourceforge.net,
Datum: 18.08.2012 02:27
Betreff:Re: [Assp-test] Antwort: Re: Antwort: Re: Block spoofe
ASSP development mailing list schrei
bt:
>How would I do that in ASSP 1.9.x or am I SOL? I know SPFoverride use
>d
>to be in there, but was removed a little while back.
It was removed, because it was unreliable.
Furthermore I recommended some years back a simple method for handling
this type of
On 8/17/2012 3:10 PM, Daniel L. Miller wrote:
> On 8/17/2012 9:32 AM, Thomas Eckardt wrote:
>> So it seems there is a change in 2.008 that prevents assp from accessing
>> the record - will have a look.
>>
>> Thomas
>>
> Looks like SPF is starting to process again - I'll see when the next
> efax.com
On 8/17/2012 9:32 AM, Thomas Eckardt wrote:
> So it seems there is a change in 2.008 that prevents assp from accessing
> the record - will have a look.
>
> Thomas
>
Looks like SPF is starting to process again - I'll see when the next
efax.com mail hits how it processes. In the meantime...here's
Hi all,
fixed in assp 2.2.2 build 12230:
- calculating IPv6 addresses was partly done in upper case - the RFC
recommendation is lower case - this is changed
- The configuration of 'SPFlocalRecord' , 'SPFoverride' and
'LocalPolicySPF' was not working after an upgrade
of the module Mail::SPF t
So it seems there is a change in 2.008 that prevents assp from accessing
the record - will have a look.
Thomas
Von:"Daniel L. Miller"
An: assp-test@lists.sourceforge.net,
Datum: 17.08.2012 18:30
Betreff:Re: [Assp-test] Antwort: Re: Block spoofed addresses
On 8/17/2012 9
Please have a look, what Mail::SPF version is installed !
Thomas
Von:"Daniel L. Miller"
An: assp-test@lists.sourceforge.net,
Datum: 17.08.2012 18:28
Betreff:Re: [Assp-test] Antwort: Re: Block spoofed addresses
On 8/17/2012 8:26 AM, Thomas Eckardt wrote:
> so the followin
>Why use SPFoverride instead of SPFfallback
like you want it.
>that way if efax actually
publishes a SPF record it can take effect
it has no SPF record - so first SPF has to look -> find there is no SPF
record defined -> now use the SPFfallback
the override takes place without doing an failing
On 8/17/2012 9:27 AM, Daniel L. Miller wrote:
> On 8/17/2012 8:26 AM, Thomas Eckardt wrote:
>> so the following SPF record in 'SPFoverride' will solve the problem.
>>
>> efax.com=>v=spf1 ip4:66.52.2.3 to be extended.. -all
>>
>>
> I'm getting the same "nothing to parse" error for this.
>
I
On 8/17/2012 8:26 AM, Thomas Eckardt wrote:
> so the following SPF record in 'SPFoverride' will solve the problem.
>
> efax.com=>v=spf1 ip4:66.52.2.3 to be extended.. -all
>
>
I'm getting the same "nothing to parse" error for this.
--
Daniel
--
On 8/17/2012 8:26 AM, Thomas Eckardt wrote:
> so the following SPF record in 'SPFoverride' will solve the problem.
>
Why use SPFoverride instead of SPFfallback - that way if efax actually
publishes a SPF record it can take effect.
--
Daniel
-
so the following SPF record in 'SPFoverride' will solve the problem.
efax.com=>v=spf1 ip4:66.52.2.3 to be extended.. -all
192.162.216.96
195.167.194.84
200.51.203.41
202.58.137.202
202.79.205.113
202.177.203.65
204.11.168.2
204.11.168.20
204.11.172.69
204.11.173.246
207.213.246
On 8/17/2012 5:16 AM, Thomas Eckardt wrote:
> efax.com=>v=spf1 mx/24 -all
>
> This record in 'SPFoverride' may help.
>
> It is possible that you have to expand or to change the entry, if efax.com
> sends email not from the same class C network were there MX is located.
> If the record contains the
what about taking it out of your white listed domains and find the ip
range of the efax mailservers from
http://www.senderbase.org/senderbase_queries/detaildomain?search_string=efax.com
and put those ranges in your ipnp.txt then try other things to block
the spoofing mails like regex etc, but t
On 8/17/2012 1:44 AM, Colin wrote:
> You're not the only one.
>
> As of the last day or two we've seen a number of fake efax.com messages
> getting through.
>
> Does anyone have a legitimate subscription to efax.com so that we can
> compare headers and see if there is an obvious regex for this?
>
>
How would I do that in ASSP 1.9.x or am I SOL? I know SPFoverride used
to be in there, but was removed a little while back.
Thanks,
Brett
> -Original Message-
> From: Thomas Eckardt [mailto:thomas.ecka...@thockar.com]
> Sent: Friday, August 17, 2012 8:17 AM
> To: ASSP development mailing
efax.com=>v=spf1 mx/24 -all
This record in 'SPFoverride' may help.
It is possible that you have to expand or to change the entry, if efax.com
sends email not from the same class C network were there MX is located.
If the record contains the right information, put '@efax..com' in to
'blockstrict
You're not the only one.
As of the last day or two we've seen a number of fake efax.com messages
getting through.
Does anyone have a legitimate subscription to efax.com so that we can
compare headers and see if there is an obvious regex for this?
I first spotted this because a client was runni
18 matches
Mail list logo
