On Wed, 2015-12-09 at 08:11 +0100, Reindl Harald wrote:
>
> T_SPF_PERMERROR says pretty clear that you made something wrong
> why do people not *verify* DNS changes? seen the same from a
> lot of large companies
>
> http://www.kitterman.com/spf/validate.html
>
+1 for the Kitterman checking tool
On 2015-12-08 9:46 PM, Marc Perkel wrote:
I'm confused. Are you saying it's catching the same spam messages you
about the same amount?
If they are new messages then it's doing well.
On 12/08/15 12:43, Rick Macdougall wrote:
Hi,
Quick and dirty look.
grep CTYME_IXHASH /var/log/spamd/current
Hi,
>> T_SPF_PERMERROR says pretty clear that you made something wrong
>> why do people not *verify* DNS changes? seen the same from a
>> lot of large companies
>>
>> http://www.kitterman.com/spf/validate.html
>>
> +1 for the Kitterman checking tool - still my first stop for SPF
> checking.
>
> I
Am 09.12.2015 um 15:44 schrieb Alex:
T_SPF_PERMERROR says pretty clear that you made something wrong
why do people not *verify* DNS changes? seen the same from a
lot of large companies
http://www.kitterman.com/spf/validate.html
+1 for the Kitterman checking tool - still my first stop for
On Wed, 2015-12-09 at 09:44 -0500, Alex wrote:
> My main problem is understanding how to build a rule to block
> spoofing attempts against my own domain? Do I need to build a meta
> that combines envelope FROM with SPF_FAIL?
>
Don't forget that SPF fails and errors will always be related to the
Hi,
>> My main problem is understanding how to build a rule to block spoofing
>> attempts against my own domain? Do I need to build a meta that
>> combines envelope FROM with SPF_FAIL?
>
> first: spoofing protection is *only* about envelope and not about the
> visible From-header (spoofing
Am 09.12.2015 um 17:30 schrieb Alex:
Hi,
My main problem is understanding how to build a rule to block spoofing
attempts against my own domain? Do I need to build a meta that
combines envelope FROM with SPF_FAIL?
first: spoofing protection is *only* about envelope and not about the
visible
On Wed, 9 Dec 2015, Alex wrote:
Please help me understand why SPF_FAIL would not be triggered when an
incoming email using my domain is received by a server that is not in
my SPF record.
I think you mean, *FROM* a server that is not in your SPF record.
SPF says nothing about the *recipient*
On 12/09/15 05:50, Rick Macdougall wrote:
Hi,
The messages it flags are messages that would have been caught without
it. About 2% of messages it flags are not seen by any other markers.
Regards,
Rick
Any false positives?
I suppose catching the same messages again just creates more
>> Please help me understand why SPF_FAIL would not be triggered when an
>> incoming email using my domain is received by a server that is not in
>> my SPF record.
>
> I think you mean, *FROM* a server that is not in your SPF record.
>
> SPF says nothing about the *recipient* MTA.
Unless that
On Wed, 9 Dec 2015, Alex wrote:
Please help me understand why SPF_FAIL would not be triggered when an
incoming email using my domain is received by a server that is not in
my SPF record.
I think you mean, *FROM* a server that is not in your SPF record.
SPF says nothing about the *recipient*
In testing in my lab, I've found significant issues using SpamAssassin
3.4.1 with Net::DNS 1.02 or later. Previously, I was using 0.81.
With Net::DNS 1.02 or 1.04, there is an 15 second+ delay in delivering
email. With debugging enabled for SA, we see the first delay here:
Dec 9 15:19:56
Hi,
>>> I think you mean, *FROM* a server that is not in your SPF record.
>>>
>>> SPF says nothing about the *recipient* MTA.
>>
>>
>> Unless that recipient MTA is my own, correct?
>
> No. The recipient *does not matter*. SPF is vetting the *sending* MTA.
>
>> The SPF record contains a list of
Am 09.12.2015 um 18:25 schrieb Alex:
Please help me understand why SPF_FAIL would not be triggered when an
incoming email using my domain is received by a server that is not in
my SPF record.
I think you mean, *FROM* a server that is not in your SPF record.
SPF says nothing about the
On Wed, 9 Dec 2015, Alex wrote:
I think you mean, *FROM* a server that is not in your SPF record.
SPF says nothing about the *recipient* MTA.
Unless that recipient MTA is my own, correct?
No. The recipient *does not matter*. SPF is vetting the *sending* MTA.
The SPF record contains a
Hi,
>> Yes, understood. This was always about my own MTA receiving a message
>> appearing to be "FROM" my own domain, and my own SPF record would be
>> used to check the IP of the remote system to determine if it was
>> permitted. I may have made that especially clear at one point.
>>
>> Does
Alex skrev den 2015-12-10 03:42:
If I wanted to use SPF in spamassassin to block spoofing attempts
against my domain, how would I do that?
Can I create a meta that combines SPF_FAIL with the From header for my
domain to do this?
setup pypolicyd-spf is not that hard is it ?
when done, you
>Spamassassin is just going to record a generic SPF_FAIL, regardless of
>whether it's my SPF record or an email from some other domain.
>If I wanted to use SPF in spamassassin to block spoofing attempts
>against my domain, how would I do that?
Simply put all approved mail servers that you allow
On 10-12-15 03:42, Alex wrote:
> Hi,
>
>>> Yes, understood. This was always about my own MTA receiving a message
>>> appearing to be "FROM" my own domain, and my own SPF record would be
>>> used to check the IP of the remote system to determine if it was
>>> permitted. I may have made that
19 matches
Mail list logo
