Re: SPF skipped for whitelisted relay domain

Hi, > this is question for policyd-spf and its configuration. > > >The problem here is that something appears to be preventing my > >welcomelist_auth entries from working properly, but I don't really > >understand how. > > I guess it's the whitelist in policyd-spf. Is it possible that it's some

Re: SPF skipped for whitelisted relay domain

>https://pastebin.com/TvTx6KzY X-Comment: SPF skipped for whitelisted relay domain - client-ip=13.110.6.221; helo=smtp14-ph2-sp4.mta.salesforce.com; envelope-from=re...@support.meridianlink.com; receiver= X-Greylist: whitelisted by SQLgrey-1.8.0 isn't it possible that it's sqlgrey that whitelist

Re: SPF skipped for whitelisted relay domain

Hi, > >https://pastebin.com/TvTx6KzY > > X-Comment: SPF skipped for whitelisted relay domain - > client-ip=13.110.6.221; helo=smtp14-ph2-sp4.mta.salesforce.com; > envelope-from=re...@support.meridianlink.com; receiver= > X-Greylist: whitelisted by SQLgrey-1.8.0 > > isn't it possible that it's sql

Re: SPF skipped for whitelisted relay domain

>I'm trying to understand why some domains are not whitelisted even >though they pass SPF and are in my local welcomelist_auth entries. I'm >using policyd-spf with postfix, and it appears to be adding the >following header: > >X-Comment: SPF skipped for whitelisted relay domain - >client-ip=13.110

Re: SPF skipped for whitelisted relay domain

> >I'm trying to understand why some domains are not whitelisted even > >though they pass SPF and are in my local welcomelist_auth entries. I'm > >using policyd-spf with postfix, and it appears to be adding the > >following header: > > > >X-Comment: SPF skipped for whitelisted relay domain - > >cli

Re: SPF skipped for whitelisted relay domain

> we wait for spamassassin 4.0.0 :=) > > 4.0.0 is in pre-release now and in production for a few of us. Start stress testing it now so we can shake out the bugs and get it out the door! Regards, KAM

Re: SPF skipped for whitelisted relay domain

On 2022-05-06 05:35, Kevin A. McGrail wrote: Hi Alex, sometimes I see this when the envelope from doesn't match the header from. So what you think might pass SPF does not. That's my only guess from looking at the example you posted. That example looked like it would work perfectly. we wait for

Re: SPF skipped for whitelisted relay domain

On 05.05.22 18:01, Alex wrote: I'm trying to understand why some domains are not whitelisted even though they pass SPF and are in my local welcomelist_auth entries. I'm using policyd-spf with postfix, and it appears to be adding the following header: X-Comment: SPF skipped for whitelisted relay

Re: SPF skipped for whitelisted relay domain

Hi Alex, sometimes I see this when the envelope from doesn't match the header from. So what you think might pass SPF does not. That's my only guess from looking at the example you posted. That example looked like it would work perfectly. KAM On Thu, May 5, 2022, 18:02 Alex wrote: > Hi, > > I'm

Re: spf fails at apache.org forwards ipv6

Benny Pedersen: : host mx1-he-de.apache.org[2a01:4f8:c2c:2bf7::1] said: 550 5.7.23 : Recipient address rejected: ASF gnomes rejected your message: SPF fail - not authorized. See https://infra.apache.org/mail-rejection.html (in reply to RCPT TO command) is it solved ? On 2022-01

Re: spf fails at apache.org forwards ipv6

On 2022-01-19 11:41, David Bürgin wrote: Benny Pedersen: : host mx1-he-de.apache.org[2a01:4f8:c2c:2bf7::1] said: 550 5.7.23 : Recipient address rejected: ASF gnomes rejected your message: SPF fail - not authorized. See https://infra.apache.org/mail-rejection.html (in reply to R

Re: spf fails at apache.org forwards ipv6

Benny Pedersen: > : host > mx1-he-de.apache.org[2a01:4f8:c2c:2bf7::1] said: 550 5.7.23 > : Recipient address rejected: ASF gnomes > rejected your message: SPF fail - not authorized. See > https://infra.apache.org/mail-rejection.html (in reply to RCPT TO > command) > > > is it solv

Re: SPF plugin ignores existing Authentication-Results

Matus UHLAR - fantomas: Matus UHLAR - fantomas: this is more an issue of how milter itself operates. the milter is supposed to see e-mail as it was received from (smtp) client - even without Received: headers, just with other milters' modifications. If SpamAssassin (SA from now) has to see Aut

Re: SPF plugin ignores existing Authentication-Results

Matus UHLAR - fantomas: this is more an issue of how milter itself operates. the milter is supposed to see e-mail as it was received from (smtp) client - even without Received: headers, just with other milters' modifications. If SpamAssassin (SA from now) has to see Authentication-Results: head

Re: SPF plugin ignores existing Authentication-Results

David Bürgin: > David Bürgin: > > Bother. I think I will try to modify my SpamAssassin milter, so that it > > will add a synthetic ‘internal’ Received header right after the > > Authentication-Results headers … that should trick SpamAssassin into > > recognising them as internal. > > Here’s the pl

Re: SPF plugin ignores existing Authentication-Results

Matus UHLAR - fantomas: Possible workarounds require trusting the Authentication-Results: header either via SA milter (which would add synthetized Received: header after it), or via SpamAssassin itself (trust headers added by "host" immediately after last trusted/internal "Received" header.) I p

Re: SPF plugin ignores existing Authentication-Results

Matus UHLAR - fantomas: this is more an issue of how milter itself operates. the milter is supposed to see e-mail as it was received from (smtp) client - even without Received: headers, just with other milters' modifications. If SpamAssassin (SA from now) has to see Authentication-Results: head

Re: SPF plugin ignores existing Authentication-Results

Martin Gregorie: Have you set the 'internal_networks' configuration parameter (in local.cf)? If not, try that first. On 18.05.21 12:07, David Bürgin wrote: Thanks, but I don’t think this helps here. I don’t know what I could add to internal_networks that would somehow change the behaviour. The

Re: SPF plugin ignores existing Authentication-Results

Martin Gregorie: Have you set the 'internal_networks' configuration parameter (in local.cf)? If not, try that first. Thanks, but I don’t think this helps here. I don’t know what I could add to internal_networks that would somehow change the behaviour. The problem is with how milters for SpamAss

Re: SPF plugin ignores existing Authentication-Results

On Tue, 2021-05-18 at 10:00 +0200, David Bürgin wrote: > David Bürgin: > > Bother. I think I will try to modify my SpamAssassin milter, so that > > it > > will add a synthetic ‘internal’ Received header right after the > > Authentication-Results headers … that should trick SpamAssassin into > > rec

Re: SPF plugin ignores existing Authentication-Results

David Bürgin: Bother. I think I will try to modify my SpamAssassin milter, so that it will add a synthetic ‘internal’ Received header right after the Authentication-Results headers … that should trick SpamAssassin into recognising them as internal. Here’s the plan to address this in SpamAssassi

Re: SPF plugin ignores existing Authentication-Results

David Bürgin: I remember asking here if SpamAssassin is able to use these instead of doing its own SPF queries. Now with debug logging on, I see that SpamAssassin isn’t actually using these results: ... Is this a bug in the SPF plugin? Do I need to set something in my config? I’m using Spa

Re: spf fail !

Noel Butler skrev den 2020-07-19 04:12: you'll find other mail rejected as well, since someone changed from hermes to this mailroute machine... X-Spam-Rules_score: HEADER_FROM_DIFFERENT_DOMAINS=0.001,HTML_MESSAGE=0.1, MAILING_LIST_MULTI=-10.1,RCVD_IN_DNSWL_NONE=-0.1,SPF_FAIL=6.419,

Re: spf fail !

On 7/18/2020 10:12 PM, Noel Butler wrote: > > On 19/07/2020 10:45, Benny Pedersen wrote: > >> Received: from mailroute1-lw-us.apache.org >> (mailroute1-lw-us.apache.org [207.244.88.153]) >> by mx.junc.eu (Postfix) with ESMTPS >> for > >; Sun, 19 Jul 2020 00:41:16 + 

Re: spf fail !

On 19/07/2020 10:45, Benny Pedersen wrote: > Received: from mailroute1-lw-us.apache.org (mailroute1-lw-us.apache.org > [207.244.88.153]) > by mx.junc.eu (Postfix) with ESMTPS > for ; Sun, 19 Jul 2020 00:41:16 + (UTC) > > gives spf fails now, be carefull you'll find other mail rejected as we

Re: spf none and dkim not pass domains

Kevin A. McGrail skrev den 2019-08-27 01:40: I believe you will find lazy domain security rules in KAM.cf that can help with this.  ?all, for example, is lazy SPF. added whole kam.cf now, one problem solved another created :=) Aug 28 00:05:23.366 [7470] info: rules: meta test JMQ_CONGRAT has

Re: spf none and dkim not pass domains

Is it the spam coming as a empty subject, empty message and a pdf attachment ? I received about 3000 of them in the weekend and I'm starting to check the logs of yesterday. A lot of them got an high score, from 8 to 13 thanks to RBL... score=9.692 required=5.6 tests=[BAYES_60=1.5, MY_RULE_1=-0.001,

Re: spf none and dkim not pass domains

I believe you will find lazy domain security rules in KAM.cf that can help with this.  ?all, for example, is lazy SPF. On 8/26/2019 19:20, Benny Pedersen wrote: > i see that bitcoins phinshing is trying to make use of not dkim signed > and use domains without spf, sounds silly and maybe its just n

Re: SPF Fail for Amazon mails, although mail headers say its a pass

On 06.06.19 00:59, MarcelM wrote: Ahh... I see. So probably other headers are modified by the mail server as well, and that is why SA's SPF check fails! this is probably SPF check for ampel-24.de which fails when forwarded locally. as you can see, amazon SPF succeeds: Received: from a1-14.smt

Re: SPF Fail for Amazon mails, although mail headers say its a pass

On Thu, 6 Jun 2019 09:30:31 +0200 Matus UHLAR - fantomas wrote: > On 05.06.19 23:06, MarcelM wrote: > >These are the full headers. (Sorry, did not realise all emails get > >redacted) > > > >https://pastebin.com/Z6hkL9hD > > the mails didn't get redacted. The headers are quoted even on the > pas

Re: SPF Fail for Amazon mails, although mail headers say its a pass

On 06.06.19 00:59, MarcelM wrote: Ahh... I see. So probably other headers are modified by the mail server as well, and that is why SA's SPF check fails! Why would it do that ? I will read up on that. because, after forwarding is done, SPF would fail - that is why SRS applied. -- Matus UHLAR -

Re: SPF Fail for Amazon mails, although mail headers say its a pass

Ahh... I see. So probably other headers are modified by the mail server as well, and that is why SA's SPF check fails! Why would it do that ? I will read up on that. Thank you! -- Sent from: http://spamassassin.1065346.n5.nabble.com/SpamAssassin-Users-f3.html

Re: SPF Fail for Amazon mails, although mail headers say its a pass

On 05.06.19 23:06, MarcelM wrote: These are the full headers. (Sorry, did not realise all emails get redacted) https://pastebin.com/Z6hkL9hD the mails didn't get redacted. The headers are quoted even on the pastebin example. and the non-forwared mail header too: https://pastebin.com/WGM0aYr

Re: SPF Fail for Amazon mails, although mail headers say its a pass

These are the full headers. (Sorry, did not realise all emails get redacted) https://pastebin.com/Z6hkL9hD and the non-forwared mail header too: https://pastebin.com/WGM0aYrh Does not look like SRS (but a good readup, something learned again). I really don't get this. The spf record for 'amazon

Re: SPF Fail for Amazon mails, although mail headers say its a pass

Thanks Bill, I will check that! -- Sent from: http://spamassassin.1065346.n5.nabble.com/SpamAssassin-Users-f3.html

Re: SPF Fail for Amazon mails, although mail headers say its a pass

On 5 Jun 2019, at 10:09, MarcelM wrote: I am not sure how Spamassassin checks SPF, but this mail did pass and fail at the same time!Spamassassin scored a fail, although it passed... This is the complete header of an example: [hopelessly mangled header block snipped] Please, if you can't in

Re: SPF

On 6 May 2019, at 17:10, Grant Taylor wrote: > On 5/3/19 2:02 PM, Bill Cole wrote: >> If the signer domain and the From header domain match, a valid DKIM >> signature that includes the From header is authentication of the From header >> to the limits of DNS trustworthiness and trust in the integ

Re: SPF

On Mon, 6 May 2019 15:10:07 -0600 Grant Taylor wrote: > Many university IT departments claim responsibility for what the > university's staff and students do while decidedly NOT authenticating > anyone. DKIM author domain signing provides strong authentication where it matters, which is wher

Re: SPF

On 5/3/19 11:41 PM, Bill Cole wrote: This is all true of any authentication mechanism: if control of authenticating credentials is lost, the authentication is worthless. Agreed. For example, if someone can control the DNS for tnetconsulting.net, they can very likely get Comodo to reissue your

Re: SPF

On 5/3/19 2:02 PM, Bill Cole wrote: If the signer domain and the From header domain match, a valid DKIM signature that includes the From header is authentication of the From header to the limits of DNS trustworthiness and trust in the integrity of the domain's authority. Which section of RFC

Re: SPF

On 5/3/19 6:26 PM, Grant Taylor wrote: > On 5/3/19 5:10 PM, Kevin A. McGrail wrote: >> I guess if you lose control of your keys and/or your DNS is >> compromised, then yes, you have a DKIM issue. > > This brings up a non-repudiation issue introduced by DKIM. > This is similar to saying not to u

Re: SPF

On 5/4/2019 12:48 AM, Grant Taylor wrote: > The point being there are reasonable circumstances that someone else > can DKIM sign messages as a victim. Sure, your entire server can be compromised and there might be a mole in the ministry. Your premise started out with the From Header versus Envelo

Re: SPF

On 4 May 2019, at 0:48, Grant Taylor wrote: > On 5/3/19 5:51 PM, Kevin A. McGrail wrote: >> If your key is compromised, generate another and publish it on DNS. > > That requires knowing that the key is compromised. > > It really helps to know that an APT is going on to know that your key has > be

Re: SPF

On 5/3/19 5:51 PM, Kevin A. McGrail wrote: If your key is compromised, generate another and publish it on DNS. That requires knowing that the key is compromised. It really helps to know that an APT is going on to know that your key has been compromised. The point being there are reasonable

Re: SPF

If your key is compromised, generate another and publish it on DNS. On Fri, May 3, 2019, 19:43 Grant Taylor wrote: > On 5/3/19 5:10 PM, Kevin A. McGrail wrote: > > I guess if you lose control of your keys and/or your DNS is compromised, > > then yes, you have a DKIM issue. > > This brings up a n

Re: SPF

On 5/3/19 5:10 PM, Kevin A. McGrail wrote: I guess if you lose control of your keys and/or your DNS is compromised, then yes, you have a DKIM issue. This brings up a non-repudiation issue introduced by DKIM. How can you successfully refute a DKIM-Signature if someone has your signing keys.

Re: SPF

On 5/3/19 4:47 PM, Kevin A. McGrail wrote: Unless you have the private key matching the public key in DNS of a domain, that's the benefit of a DKIM signature. I was referring to exactly that. As in the real ena.com being compromised and attackers taking a copy of their private key. See rece

Re: SPF

On 5/3/2019 6:53 PM, Grant Taylor wrote: > On 5/3/19 4:47 PM, Kevin A. McGrail wrote: >> Unless you have the private key matching the public key in DNS of a >> domain, that's the benefit of a DKIM signature. > > I was referring to exactly that. > I guess if you lose control of your keys and/or your

Re: SPF

On 5/3/2019 6:40 PM, Grant Taylor wrote: > I think that I could sign as d=ena.com if I had access to their keys. > Which obviously I / my server should not. > > I need to reread if there is any protection in DKIM to detect such > malicious use of the spoofed domain's keys.  My current understanding

Re: SPF

On 5/3/19 4:35 PM, RW wrote: But if you sign it with d=ena.com it wont pass as valid, unless you have also gained control of the DNS for ena.com. I was referring to signing it with d=tnetconsulting.net. I need to reread RFC 6376 to comment further. But at this point, I think that I could sig

Re: SPF

On Fri, 3 May 2019 13:28:00 -0600 Grant Taylor wrote: > On 5/3/19 11:53 AM, David Jones wrote: > > Not completely true as long as domain/DNS control is not > > compromised. > > How is it not completely true? > > My server can apply a DKIM signature to an outgoing email with a > From: header of

Re: SPF

On 3 May 2019, at 12:30, Grant Taylor wrote: > On 5/3/19 9:48 AM, Bill Cole wrote: >> An entirely different mechanism (DKIM) exists to verify From headers. > > DKIM is only positive confirmation that the (signed) headers (and body > content) has not changed since the signature was applied. RFC63

Re: SPF

On 5/3/19 11:53 AM, David Jones wrote: Not completely true as long as domain/DNS control is not compromised. How is it not completely true? My server can apply a DKIM signature to an outgoing email with a From: header of djo...@ena.com. Nothing about my server's DKIM signature verifies the

Re: SPF

On 5/3/19 11:30 AM, Grant Taylor wrote: > On 5/3/19 9:48 AM, Bill Cole wrote: >> An entirely different mechanism (DKIM) exists to verify From headers. > > DKIM is only positive confirmation that the (signed) headers (and body > content) has not changed since the signature was applied. > Not com

Re: SPF

On 5/3/19 9:48 AM, Bill Cole wrote: An entirely different mechanism (DKIM) exists to verify From headers. DKIM is only positive confirmation that the (signed) headers (and body content) has not changed since the signature was applied. DKIM does nothing to verify the authenticity of what was

Re: SPF

Take your email in example: envelope from: users-return-120376-duca=staff.spin...@spamassassin.apache.org body from:  maj...@gmail.com SPF for gmail.com: v=spf1 redirect=_spf.google.com You see that in case of mailing lists (and ESPs and possibly every other VERP case) a check on the body fr

Re: SPF

On 5/3/19 9:47 AM, RW wrote: > On Fri, 3 May 2019 06:55:40 -0700 (MST) > user321 wrote: > >> Any reason why SA is checking for SPF against envelope from not the >> header from? > See the SPF link on this page: https://blog.returnpath.com/how-to-explain-dmarc-in-plain-english/ > Because that's

Re: SPF

On 3 May 2019, at 11:24, user321 wrote: But I have a feeling this would be extremely effective in dealing with spoofed emails. Your "feeling" is not consistent with known facts. For example: messages sent to this mailing list and most other mailing lists would fail a SPF test using the From

Re: SPF

But I have a feeling this would be extremely effective in dealing with spoofed emails. They are often having borderline score around the blocking point, so that kind of rule with relatively low score could be the last straw on the camel's back, don't you agree? cheers user321 -- Sent from: http

Re: SPF

On Fri, 3 May 2019 06:55:40 -0700 (MST) user321 wrote: > Any reason why SA is checking for SPF against envelope from not the > header from? Because that's how SPF works. > I am rejecting the SPF_FAIL e-mails on Postfix (-all only), but still > spammers can forge the header from field. > Can I ch

Re: SPF

El vie., 3 may. 2019 a las 11:13, user321 () escribió: > Any reason why SA is checking for SPF against envelope from not the header > from? > > This is what SPF is made for > > cheers > user > > > > -- > Sent from: > http://spamassassin.1065346.n5.nabble.com/SpamAssassin-Users-f3.html >

Re: SPF weirdness...

On 1/15/19 8:02 PM, David B Funk wrote: It's a bit tricky to implement a milter correctly because people often don't understand that the message which sendmail hands to a milter is as-received from the incoming network connection. Any locally added stuff (EG the "Received:" header) isn't in th

Re: SPF weirdness...

On Tue, 15 Jan 2019, Bill Cole wrote: On 15 Jan 2019, at 15:05, Grant Taylor wrote: I will investigate to see if spamass-milter can fabricate a satisfactory Received: header. A quick look at the issue tracker for it implies that it does so. A milter that actually works with SA really needs

Re: SPF weirdness...

On 15 Jan 2019, at 15:05, Grant Taylor wrote: > I will investigate to see if spamass-milter can fabricate a satisfactory > Received: header. A quick look at the issue tracker for it implies that it does so. A milter that actually works with SA really needs to. Unfortunately, it is a nuisance t

Re: SPF weirdness...

On 01/15/2019 12:59 PM, Bill Cole wrote: There are at many different milters that can use SpamAssassin listed at https://wiki.apache.org/spamassassin/IntegratedInMta#Integrated_into_Sendmail. Some links there may be dead. I am using spamass-milter, and spfmilter, both connected to Sendmail.

Re: SPF weirdness...

On 15 Jan 2019, at 14:24, Grant Taylor wrote: > On 01/15/2019 11:39 AM, Bill Cole wrote: >> This strikes me as a flaw in whatever milter you're using. Some (e.g. >> MIMEDefang) milters deal with the fact that they don't get a local Received >> header by constructing one from what they know befor

Re: SPF weirdness...

On 01/15/2019 11:39 AM, Bill Cole wrote: This strikes me as a flaw in whatever milter you're using. Some (e.g. MIMEDefang) milters deal with the fact that they don't get a local Received header by constructing one from what they know before passing the message to SA. The SPF milter is constru

Re: SPF weirdness...

On 15 Jan 2019, at 12:15, Grant Taylor wrote: > On 01/15/2019 09:24 AM, Kevin A. McGrail wrote: >> What is your glue for SA? Is it getting the received header you are >> expecting in time for the parsing? > > Both SA and my spfmilter are are milters on the same inbound Internet edge > MTA. > >

Re: SPF weirdness...

On 01/15/2019 09:24 AM, Kevin A. McGrail wrote: What is your glue for SA? Is it getting the received header you are expecting in time for the parsing? Both SA and my spfmilter are are milters on the same inbound Internet edge MTA. I will have to research to see if the header is added by the

Re: SPF weirdness...

On 01/15/2019 09:36 AM, Bill Cole wrote: Check both the contents and documentation of trusted_networks, msa_networks, and internal_networks. Will do. If SA thinks a prior hop is through a machine that writes trustworthy Received headers and is a normal part of your relay path, it will check

Re: SPF weirdness...

On 15 Jan 2019, at 11:08, Grant Taylor wrote: Does anybody know off the top of their head—don't dig, I'll do that later—what might cause SpamAssassin to apply SPF processing to earlier Received: headers (lower in the message source)? Check both the contents and documentation of trusted_networ

Re: SPF check though external relay

>On 11.11.17 20:06, Sean Greenslade wrote: >>SPF checks the final server that transmits the mail. If you are using >a relay server, that server will need to be in the SPF records. > >no. Only outgoing mail servers really need to be in SPF records. Sorry, I misread the original message and thought

Re: SPF check though external relay

On November 11, 2017 5:31:08 PM PST, Stephan Herker wrote: I'm running spam assassin default configuration which checks spf records.  In my case I received an email and it checked if the last relay was a valid sender for SPF.  The last relay was a server I have in the cloud, so it failed SPF eve

Re: SPF check though external relay

On Sat, 11 Nov 2017 17:31:08 -0800 Stephan Herker wrote: > I'm running spam assassin default configuration which checks spf > records.  In my case I received an email and it checked if the last > relay was a valid sender for SPF.  The last relay was a server I have > in the cloud, You probably

Re: SPF check though external relay

On 11/11/2017 07:31 PM, Stephan Herker wrote: I'm running spam assassin default configuration which checks spf records.  In my case I received an email and it checked if the last relay was a valid sender for SPF.  The last relay was a server I have in the cloud, so it failed SPF even though ori

Re: SPF check though external relay

On November 11, 2017 5:31:08 PM PST, Stephan Herker wrote: >I'm running spam assassin default configuration which checks spf >records.  In my case I received an email and it checked if the last >relay was a valid sender for SPF.  The last relay was a server I have >in >the cloud, so it failed S

Re: spf

On 26.02.17 20:04, Gokan Atmaca wrote: % locate -i spf.pm /usr/lib/perl5/Net/DNS/RR/SPF.pm /usr/share/perl5/Mail/SPF.pm # this is the module. /usr/share/perl5/Mail/SpamAssassin/Plugin/SPF.pm Hello This module path: [root@mail ~]# locate -i spf.pm /opt/zimbra/common/lib/perl5/Mail/SPF.pm

Re: spf

> % locate -i spf.pm > /usr/lib/perl5/Net/DNS/RR/SPF.pm > /usr/share/perl5/Mail/SPF.pm # this is the module. > /usr/share/perl5/Mail/SpamAssassin/Plugin/SPF.pm Hello This module path: [root@mail ~]# locate -i spf.pm /opt/zimbra/common/lib/perl5/Mail/SPF.pm /opt/zimbra/common/lib/perl5/Mail

Re: spf

Oops; I misread -- Gokan is the one reporting is issue. Zimbra is bit unique -- they distribute most of the large OS components as they have them pinned to various versions. So this is really going to be an issue best addressed by them. For example, my install (on an Ubuntu 14.04 LTS base) in

Re: spf

On 26.02.17 10:12, Jered Floyd wrote: It may be more effective to pursue this in a Zimbra support forum. perl modules more belong to the perl and OS installation, not to zimbra. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advert

Re: spf

Matus, It may be more effective to pursue this in a Zimbra support forum. If you are running the OSS version (as am I!), you may have good luck here: https://forums.zimbra.org/ Unfortunately I run SpamAssassin on my mailhub prior to Zimbra so can't help on this one. --Jered - On Feb 26,

Re: spf

Do you have Mail-SPF perl module installed? On 26.02.17 15:20, Gokan Atmaca wrote: i am using zimbra. The module is being installed. /opt/zimbra/data/spamassassin/rules/25_spf.cf -| SPF module that is not SPF module, nor a perl module. try searching it: % locate -i spf.pm /usr/l

Re: spf

> Do you have Mail-SPF perl module installed? Hello i am using zimbra. The module is being installed. /opt/zimbra/data/spamassassin/rules/25_antivirus.cf /opt/zimbra/data/spamassassin/rules/25_asn.cf /opt/zimbra/data/spamassassin/rules/25_dcc.cf /opt/zimbra/data/spamassassin/rules/25_dkim.cf /op

Re: spf

On 26.02.17 13:46, Gokan Atmaca wrote: I want to check SPF. But it does not work. Can you help me with this? config: header SPF_GECER eval:check_for_spf_pass() describe SPF_GECER SPF: sender matches SPF record score SPF_GECER -0.5 what is wrong with existing and provided

Re: SPF PermError or TempError cannot hit

> I realized that the rules T_SPF_PERMERROR and T_SPF_TEMPERROR were never > hitting on my emails even though my Postfix log had multiple instances > of such errors, e.g. this timeout Hmm, thats weird, they hit just fine over here... > > 2017-01-16 14:03:35-0500 [postfix] 10111.5ms ip=173.37.142.

Re: SPF should always hit? SOLVED

Am 11.07.2016 um 21:02 schrieb David B Funk: On Mon, 11 Jul 2016, Reindl Harald wrote: SA has also a weakness or design mistake here "envelope_sender_header X-Local-Envelope-From" while that header comes from postfix with customized configuration because we use it in own rules has no fallback

Re: SPF should always hit? SOLVED

On Mon, 11 Jul 2016, Reindl Harald wrote: Am 11.07.2016 um 19:30 schrieb RW: [snip..] It sounds like SA is not able to parse the envelope sender out of the headers. See the description for envelope_sender_header in man Mail::SpamAssassin::Conf SA has also a weakness or design mistake here

Re: SPF should always hit? SOLVED

Am 11.07.2016 um 19:30 schrieb RW: On Mon, 11 Jul 2016 12:49:04 -0400 Robert Fitzpatrick wrote: I finally was able to get SPF checks to be more reliable by making sure Postfix SPF policies were in place. Here is a good read https://github.com/mail-in-a-box/mailinabox/issues/698 Excerpt:

Re: SPF should always hit? SOLVED

On Mon, 11 Jul 2016 12:49:04 -0400 Robert Fitzpatrick wrote: > I finally was able to get SPF checks to be more reliable by making > sure Postfix SPF policies were in place. Here is a good read > > https://github.com/mail-in-a-box/mailinabox/issues/698 > Excerpt: It's worth noting that lack o

Re: SPF should always hit? SOLVED

Robert Fitzpatrick wrote: Joe Quinn wrote: On 6/9/2016 11:23 AM, Robert Fitzpatrick wrote: Excuse me if this is too lame a question, but I have the SPF plugin enabled and it hits a lot. Should SPF_ something hit on every message if the domain has an SPF record in DNS? Furthermore, a message fo

Re: SPF should always hit?

Joe Quinn wrote: On 6/9/2016 11:23 AM, Robert Fitzpatrick wrote: Excuse me if this is too lame a question, but I have the SPF plugin enabled and it hits a lot. Should SPF_ something hit on every message if the domain has an SPF record in DNS? Furthermore, a message found as Google phishing did

Re: SPF should always hit?

On 6/9/2016 11:23 AM, Robert Fitzpatrick wrote: Excuse me if this is too lame a question, but I have the SPF plugin enabled and it hits a lot. Should SPF_ something hit on every message if the domain has an SPF record in DNS? Furthermore, a message found as Google phishing did not get a hit on

Re: SPF should always hit?

Am 09.06.2016 um 17:23 schrieb Robert Fitzpatrick: Excuse me if this is too lame a question, but I have the SPF plugin enabled and it hits a lot. Should SPF_ something hit on every message if the domain has an SPF record in DNS? and if it's SPF_NONE Furthermore, a message found as Google ph

Re: SPF rules and my domain

Am 11.12.2015 um 17:11 schrieb Alex: On Fri, Dec 11, 2015 at 10:33 AM, Matus UHLAR - fantomas wrote: On 10.12.15 22:54, Alex wrote: I don't understand why a message from tripadvisor.com would have SPF_FAIL, and as part of trying to understand how SPF works, I'd like to figure out what's happ

Re: SPF rules and my domain

Hi, On Fri, Dec 11, 2015 at 10:33 AM, Matus UHLAR - fantomas wrote: >> On 10.12.15 22:54, Alex wrote: >>> >>> I don't understand why a message from tripadvisor.com would have >>> SPF_FAIL, and as part of trying to understand how SPF works, I'd like >>> to figure out what's happening. >>> >>> Woul

Re: SPF rules and my domain

On 10.12.15 22:54, Alex wrote: I don't understand why a message from tripadvisor.com would have SPF_FAIL, and as part of trying to understand how SPF works, I'd like to figure out what's happening. Would someone be able to take a look at this message and figure out why mail from tripadvisor.com

Re: SPF rules and my domain

Am 11.12.2015 um 08:56 schrieb Matus UHLAR - fantomas: I don't understand why a message from tripadvisor.com would have SPF_FAIL, and as part of trying to understand how SPF works, I'd like to figure out what's happening. Would someone be able to take a look at this message and figure out why

Re: SPF rules and my domain

> My response was based on how you worded your question, which has been > removed from the thread now: > > > > > 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

Re: SPF rules and my domain

Hi, On Thu, Dec 10, 2015 at 10:28 AM, John Hardin wrote: > On Thu, 10 Dec 2015, Matus UHLAR - fantomas wrote: > >>> > My response was based on how you worded your question, which has been >>> > removed from the thread now: >>> > > > > > Please help me understand why SPF_FAIL would not be trigg

Re: SPF rules and my domain

On December 10, 2015 3:49:56 PM Alex wrote: whitelist_from_spf: *@example.tld (your domain) header Return-Path =~ example.tld That's great. I'll investigate. or blacklist_from *@* with whitelist_auth *@* to hate all equal :)

  1   2   3   4   5   6   7   8   9   >