s of "-all" being used with incomplete or
obsolete lists of "permitted" hosts to accept that they know all of the
places their mail gets generated.
The idea of using -all is not just configuring it and forgetting it,
it's part of the accepted risk that if you change something, y
ing to adopt SRS or any other mechanisms to avoid SPF
breakage to ever change. There is no ROI in trying to fix such cases
individually but users still want their college email addresses to work decades
after graduating and some colleges have pandered to them. So have some
professional orgs.
--
On 09/05/2024 22:47, Bill Cole wrote:
On 2024-05-09 at 08:37:06 UTC-0400 (Thu, 09 May 2024 14:37:06 +0200)
Benny Pedersen
is rumored to have said:
Bill Cole skrev den 2024-05-09 14:22:
In fact, I can't think of any whitelist test that should pass if SPF
fails.
If you operate on the theory
On 2024-05-09 at 08:37:06 UTC-0400 (Thu, 09 May 2024 14:37:06 +0200)
Benny Pedersen
is rumored to have said:
Bill Cole skrev den 2024-05-09 14:22:
In fact, I can't think of any whitelist test that should pass if SPF
fails.
If you operate on the theory that a SPF failure is always a sign
Bill Cole skrev den 2024-05-09 14:22:
In fact, I can't think of any whitelist test that should pass if SPF
fails.
If you operate on the theory that a SPF failure is always a sign of
spam, you can make your SpamAssassin always trust SPF failures
absolutely. I would not recommend that. Some
checks should never ever pass if the SPF checks
fail.
The only "white-hole" item there is RCVD_IN_DNSWL_HI, which is a
DNS-based list where IPs which are supposedly "good" can be listed, i.e.
it is external to SA, not something we manage. You are suggesting that
the knowl
=0.001,HTML_MESSAGE=0.001,
NORDNS_LOW_CONTRAST=0.001,RCVD_IN_DNSWL_HI=-5,RDNS_NONE=1.274,
SPF_FAIL=0.919,SPF_HELO_NONE=0.001,URIBL_BLOCKED=0.001,WIKI_IMG=2.397
autolearn=disabled version=3.4.6
DNS white-hole list checks should never ever pass if the SPF checks
fail. In fact, I can't think
On 09/05/2024 05:57, Jarland Donnell wrote:
That's easy though at least. Set the DNSWL rule to 0. I appreciate
their effort but it's simply not an accurate way to determine the value
of an email in 2024. It's never been the deciding factor between
whether or not an email was spam, in any
DNSWL_HIIn DNS whitelist, good SPF
- Original Message -
I received a (relatively) well crafted Phishing email today. It was clearly
a well planned campaign. The Spamassassin score was as follows:
X-Spam-Status: No, score=-0.4 required=5.0 tests=GOOG_REDIR_NORD
gt;
> DNS white-hole list checks should never ever pass if the SPF checks fail. In
> fact, I can't think of any whitelist test that should pass if SPF fails. I
> could attach a higher score to SPF_FAIL, but that would unduly affect cases
> where the sender wasn't white listed.
>
=0.001,RCVD_IN_DNSWL_HI=-5,RDNS_NONE=1.274,
SPF_FAIL=0.919,SPF_HELO_NONE=0.001,URIBL_BLOCKED=0.001,WIKI_IMG=2.397
autolearn=disabled version=3.4.6
DNS white-hole list checks should never ever pass if the SPF checks
fail. In fact, I can't think of any whitelist test that should pass
be used to check results.
ifplugin Mail::SpamAssassin::Plugin::AuthRes
ifplugin !(Mail::SpamAssassin::Plugin::SPF)
header SPF_PASS eval:check_authres_result('spf',
'pass')
header SPF_FAIL eval:check_authres_result('spf',
'fail')
header
On 24.04.24 18:50, Benny Pedersen wrote:
unsure so i ask :)
try to explain your question a bit more
--
Matus UHLAR - fantomas, uh...@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
unsure so i ask :)
On 7/27/23 6:25 AM, Matus UHLAR - fantomas wrote:
I use spamass-milter on my system and amavisd-milter on other systems
especially to be able to reject spam at SMTP time. Definitely a good thing.
:-)
You just should not use it for "outgoing" mail from your clients, so
they don't complain
>
> >> I assume that you mean so that your outbound SMTP server is actually
> >> authorized in some capacity and fall under "all". Is that correct?
>
> ... and does NOT dall under "all".
>
> On 27.07.23 08:11, Marc wrote:
> >indeed afaik -all is all authorized
>
> pardon me? -all means
I assume that you mean so that your outbound SMTP server is actually
authorized in some capacity and fall under "all". Is that correct?
... and does NOT dall under "all".
On 27.07.23 08:11, Marc wrote:
indeed afaik -all is all authorized
pardon me? -all means everyone except previously
On 7/26/23 2:34 AM, Benny Pedersen wrote:
milters should not be spam scanners, spamassassin is better
On 26.07.23 13:32, Grant Taylor via users wrote:
{spamass-milter,milter-spamc} combined with SpamAssassin cause me to
question the veracity of that statement.
+1
Milter implies doing the
Marc skrev den 2023-07-27 09:48:
The oldest mail server log I can find is from mx-in-08 sadly even that
one is only from 2005 but confirms we were using it then, quite a bit
longer than 2014 :P
Why retire? To go fishing or so? I think GDPR even prohibits keeping
very old log files, if there is
On 27/07/2023 18:11, Marc wrote:
I am always using -all. I honestly can't think of a good argument to
use anything else.
I agree.
It's my belief that ~all is only useful for a "production entry test
phase", once your happy, move to -all
Like DMARC's p=none it's a "getting it going" method
On 27/07/2023 17:48, Marc wrote:
The oldest mail server log I can find is from mx-in-08 sadly even that
one is only from 2005 but confirms we were using it then, quite a bit
longer than 2014 :P
Why retire? To go fishing or so? I think GDPR even prohibits keeping
very old log files, if there
>
> I assume that you mean so that your outbound SMTP server is actually
> authorized in some capacity and fall under "all". Is that correct?
indeed afaik -all is all authorized
> > When you configure your spf your result is either pass, softfail or
> f
>
> The oldest mail server log I can find is from mx-in-08 sadly even that
> one is only from 2005 but confirms we were using it then, quite a bit
> longer than 2014 :P
>
Why retire? To go fishing or so? I think GDPR even prohibits keeping very old
log files, if there is no specific reason for
On 27/07/2023 13:43, Bill Cole wrote:
No, SPF pre dates that, 1998 or there abouts if my ageing memory serves
me
It's failing... :)
SPF originated with an idea of Gordon Fecyk, first written up AFTER he
left MAPS in 2001. First ID calling it SPF would have been 2003 or so.
A brief
On 2023-07-26 at 23:01:11 UTC-0400 (Thu, 27 Jul 2023 13:01:11 +1000)
Noel Butler
is rumored to have said:
On 27/07/2023 10:20, Matija Nalis wrote:
[...]
Also, 1990s? Weren't first SPF-alike ideas drafted first time in
early-mid 2000s, and SPF itself not published as *proposed* IETF
standard
but reality is far different, that said, most would not be
using anything from 1990's, if they are, they are have far bigger issues
than SPF.
That at least I can attest is not always the case (I still see
systems with custom sendmail.cf which nobody dares to touch,
and with a good reason!)
As above
So, still in 2023, I have to
deal with SPF (and DKIM) failing due to such forwarders/ML (as well
as misconfigurations, of course)
+1
Also, 1990s? Weren't first SPF-alike ideas drafted first time in
early-mid 2000s, and SPF itself not published as *proposed* IETF
standard until 2014?
I
On Thu, Jul 27, 2023 at 07:11:59AM +1000, Noel Butler wrote:
> On 27/07/2023 05:09, Matija Nalis wrote:
>
> > Any SPF, no matter how correctly configured, will lead to false
> > positives in some cases (e.g. encoutering mailing list
>
> B.S.
I'd appreciat
On 7/26/23 2:09 PM, Matija Nalis wrote:
Only way to make SPF never incorrectly fail/softwail is to use "+all",
but that kind of kills its point :-)
I question the veracity of that.
Is SPF failing to perform it's intended function if an unauthorized
server is blocked from sen
On 7/26/23 1:44 PM, Marc wrote:
so your ip does not generate a softfail or fail
I assume that you mean so that your outbound SMTP server is actually
authorized in some capacity and fall under "all". Is that correct?
When you configure your spf your result is either pass, softfa
On 27/07/2023 05:09, Matija Nalis wrote:
Any SPF, no matter how correctly configured, will lead to false
positives in some cases (e.g. encoutering mailing list
B.S.
mailing lists have been smart enough for over 20 years to rewrite sender
and not appear as a basic forwarder - which are you
> > >
> > > What does "correctly setup SPF" mean to you?
> >
> > so your ip does not generate a softfail or fail
>
> Only way to make SPF never incorrectly fail/softwail is to use "+all",
> but that kind of kills its point :-)
+all is i
On Wed, Jul 26, 2023 at 06:44:32PM +, Marc wrote:
> > At the risk of starting a flame war...
> >
> > What does "correctly setup SPF" mean to you?
>
> so your ip does not generate a softfail or fail
Only way to make SPF never incorrectly fail/softwa
> At the risk of starting a flame war...
>
> What does "correctly setup SPF" mean to you?
so your ip does not generate a softfail or fail
> What makes your opinion better than someone else's opinion that differs?
> (I take it for granted that someone will have a diff
the ability to reject messages that SpamAssassin declares as
(bad enough) spam at SMTP time to be a good thing.
maybe use bind9 rpz to change spf data for stupid domains, mostly
freemail domains in this category ? :)
Will you provide a description of what you would have an RPZ do?
I know
On 7/26/23 1:44 AM, Marc wrote:
asking them to correctly setup spf is mostly enough.
At the risk of starting a flame war...
What does "correctly setup SPF" mean to you?
What makes your opinion better than someone else's opinion that differs?
(I take it for granted that someone
On 26/07/2023 17:34, Benny Pedersen wrote:
milters should not be spam scanners, spamassassin is better
SA is perl, perl is faster and better resource nice than python garbage,
but perl is still slow compared to C, that is why milters will win out
everytime.
milter-regex is also light and
Marc skrev den 2023-07-26 08:44:
blocklist_from *@gmail.com
welcomelist_auth *@gmail.com
makes it perfect :)
if both dkim and spf is pass, it will get neutral scores
I found this to be not sufficient (assuming the above pass is ~all).
gmail has spf ~all.
set softfail score to 100, solved
>
> blocklist_from *@gmail.com
> welcomelist_auth *@gmail.com
>
> makes it perfect :)
>
> if both dkim and spf is pass, it will get neutral scores
>
I found this to be not sufficient (assuming the above pass is ~all). gmail has
spf ~all.
So I have made an exceptio
J Doe writes:
> I am currently using SpamAssassin 4.0.0 and I had a question on how I
> can ensure that any e-mail from @gmail.com has a valid SPF and DKIM
> signature.
You should phrase what you want more carefully. What I think you said
is:
I want that if mail comes in wi
J Doe skrev den 2023-07-26 01:52:
Thanks for your reply - perfect: welcomelist_auth is exactly what I
was looking for!
blocklist_from *@gmail.com
welcomelist_auth *@gmail.com
makes it perfect :)
if both dkim and spf is pass, it will get neutral scores
but if fail it will get spamscored
You should "welcomelist" stuff that you want to guarantee passage of, regarless
of all other considerations.
Given that Google:
a) SPF & DKIMs all the stuff that comes out of their system
b) has lots of spammers who have Gmail accounts and spew spam from them.
c) does not seem to
On 2023-07-25 19:39, Benny Pedersen wrote:
J Doe skrev den 2023-07-26 01:20:
its a one liner with welcomelist_auth
Hi Benny,
Thanks for your reply - perfect: welcomelist_auth is exactly what I was
looking for!
- J
J Doe skrev den 2023-07-26 01:20:
I am currently using SpamAssassin 4.0.0 and I had a question on how I
can ensure that any e-mail from @gmail.com has a valid SPF and DKIM
signature.
incorrect questions gives incorrect answers
I am aware that the following can be easily fooled, because
Hi,
I am currently using SpamAssassin 4.0.0 and I had a question on how I
can ensure that any e-mail from @gmail.com has a valid SPF and DKIM
signature.
I am aware that the following can be easily fooled, because it is not
checking SPF and DKIM:
welcomelist_from *@gmail.com
... so
Hi,
I received an email from ncua.gov sent through Zix that apparently was an
SPF softfail. It also hit FROM_GOV_SPOOF. I wanted to see if the two were
related, or what the reason was for this email hitting so many spam rules.
meta FROM_GOV_SPOOF !__NOT_SPOOFED && __FROM_ADDR
On 2022-12-28 at 12:32:39 UTC-0500 (Wed, 28 Dec 2022 12:32:39 -0500)
Greg Troxel
is rumored to have said:
It would be great if someone(tm) went through the blackhat pdf and
wrote
rules for all the evasions, and fixed the MTAs etc.
From the cited page:
For more technical details, please
Brent Clark:
> Something to see and keep an eye on (Read: Why build this tool)
>
> https://www.kitploit.com/2022/01/espoofer-email-spoofing-testing-tool.html
This is old news. The espoofer tool and research were presented I think
in 2020 and were widely discussed then. And bug fixes for, say,
On 12/28/22 10:32 AM, Greg Troxel wrote:
It would be great if someone(tm) went through the blackhat pdf and
wrote rules for all the evasions, and fixed the MTAs etc.
I have seen and heard discussion about the raft number of bugs fixed 30
- 90 days after the annual Blackhat / Pwn2Own
It would be great if someone(tm) went through the blackhat pdf and wrote
rules for all the evasions, and fixed the MTAs etc.
On 12/28/22 6:17 AM, Kevin A. McGrail wrote:
Sigh. Yet another borderline ethical posting / tool like far too many
pentesters who think transparency is the ultimate way to move the needle
of security
Many tools can be used for both good and evil.
I have yet to find a kitchen knife that can
On 12/28/2022 8:11 AM, Brent Clark wrote:
Something to see and keep an eye on (Read: Why build this tool)
Sigh. Yet another borderline ethical posting / tool like far too many
pentesters who think transparency is the ultimate way to move the needle
of security while thinly veiling their
Good day Guys
Something to see and keep an eye on (Read: Why build this tool)
https://www.kitploit.com/2022/01/espoofer-email-spoofing-testing-tool.html
HTH
Regards
Brent Clark
On 16.12.22 15:18, Alex wrote:
This GoDaddy/M365 quarantined email passes SPF, but despite now adding it
to my welcomelist, it is still marked as spam.
https://pastebin.com/VpPmgGN4
On 19.12.22 09:54, Matus UHLAR - fantomas wrote:
* 6.0 KAM_ZWNJ Use of null characters indicates a goal
On 16.12.22 15:18, Alex wrote:
This GoDaddy/M365 quarantined email passes SPF, but despite now adding it
to my welcomelist, it is still marked as spam.
https://pastebin.com/VpPmgGN4
* 6.0 KAM_ZWNJ Use of null characters indicates a goal to elude scanners
try finding out why this matches
ted\b/
score TREE_WHITELIST-50
> I'm now more curious why it says SPF_PASSed, yet my welcomelist entry
> didn't work to keep it from being marked as spam.
SPF pass is just a result that gets processed in the general result. The
general result decides if a message is marked as spam.
>
On 17/12/2022 08:35, Marc wrote:
The sender's SPF record includes the sending IP (40.107.96.128) in the
secureserver.net <http://secureserver.net> entry, and SPF_PASS is
hit.
Without even checking anything I can already remember that this
secureserver.net is shit. I have blocked
Hi,
On Fri, Dec 16, 2022 at 5:35 PM Marc wrote:
> > The sender's SPF record includes the sending IP (40.107.96.128) in the
> > secureserver.net <http://secureserver.net> entry, and SPF_PASS is hit.
> >
>
> Without even checking anything I can already remembe
> The sender's SPF record includes the sending IP (40.107.96.128) in the
> secureserver.net <http://secureserver.net> entry, and SPF_PASS is hit.
>
Without even checking anything I can already remember that this
secureserver.net is shit. I have blocked whole ranges of them,
Alex skrev den 2022-12-16 21:18:
https://pastebin.com/VpPmgGN4
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 SPF_PASS SPF: sender matches SPF record
netblocks are authorized
505,425 individual IPv4 addresses
i think so many spamming ips is very spammy
Hi,
This GoDaddy/M365 quarantined email passes SPF, but despite now adding it
to my welcomelist, it is still marked as spam.
https://pastebin.com/VpPmgGN4
Only when I create a welcomelist_from_rcvd does it get delivered.
The sender's SPF record includes the sending IP (40.107.96.128
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-s
>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 sqlg
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
>
>
>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 d
> >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
> 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
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
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
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,
>
Hi,
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
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
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
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 RC
: 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 ?
LOCAL_HASHBL_ALL Message contains email address found on
HASHBL
[verificaciones[at]cobranzadental.com]
1.1 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.2 USER_IN_DEF_SPF_WL From: address is in the default SPF
white-list
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
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:
relay header after such header lines.
Now, using the following setting I should get SpamAssassin to reuse
Authentication-Results provided by SPF Milter:
--synth-relay '^(?i)authentication-results: *mail\.gluet\.ch;'
And here we go:
May 21 19:08:21 mail spf-milter[42418]: mxout1-he-
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
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:
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.
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
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
> >
-Results: mail.gluet.ch; dkim=pass ... [← untrusted!]
Authentication-Results: mail.gluet.ch; spf=pass ...[← untrusted!]
Message-ID: <1...@execute-api.eu-central-1.amazonaws.com>
...
Would now be sent to SpamAssassin in this form:
Authentication-Results: mail.gluet.ch; dmarc=pass ... [← now t
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
I use a separate SPF component (https://crates.io/crates/spf-milter). It
conveys SPF results for both HELO and MAIL FROM identity, each in its
own Authentication-Results header:
Authentication-Results: mail.gluet.ch; spf=fail
smtp.mailfrom=bounces.amazon.co.jp
Authentication-Results
On Sat, 2021-04-24 at 03:22 -0700, Yuri wrote:
> All messages from the FreeBSD mailing list are labeled as 'SPF check
> fail'.
>
> Here is the message:
> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=224393
>
> People said that SA does this by mistake:
> https://b
On 24.04.21 03:22, Yuri wrote:
All messages from the FreeBSD mailing list are labeled as 'SPF check fail'.
Here is the message:
https://bugs.freebsd.org/bugzilla/attachment.cgi?id=224393
it's the encapsulated message, but the first header from included message:
Received: from mail0
2021 at 11:48, Paul Stead wrote:
> Replied to Yuri directly,
>
> This could result of not having internal_networks set.
>
> mail2.{redacted} considers mail1.{redacted} to be an external server -
> thus checking the SPF record for freebsd.org against the IP address of
> mail
Replied to Yuri directly,
This could result of not having internal_networks set.
mail2.{redacted} considers mail1.{redacted} to be an external server - thus
checking the SPF record for freebsd.org against the IP address of
mail1.{redacted}
Paul
On Sat, 24 Apr 2021 at 11:45, Antony Stone
On Saturday 24 April 2021 at 12:22:15, Yuri wrote:
> All messages from the FreeBSD mailing list are labeled as 'SPF check fail'.
I would firstly observe that you (or whomever runs mail0.{redacted}.com) are
running SpamAssassin version 3.3.1 (eleven years old now), so therefore i
wonder how
All messages from the FreeBSD mailing list are labeled as 'SPF check fail'.
Here is the message:
https://bugs.freebsd.org/bugzilla/attachment.cgi?id=224393
People said that SA does this by mistake:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255356
Is it a mistake? A bug in SA
On Wed, 4 Nov 2020 16:18:56 +0100
David Bürgin wrote:
> Hello,
>
> as far as I understand, SpamAssassin can recognise and consume
> incoming SPF results in an Authentication-Results or Received-SPF
> header, so that it doesn’t have to do its own SPF evaluation.
>
> I
Hello,
as far as I understand, SpamAssassin can recognise and consume incoming
SPF results in an Authentication-Results or Received-SPF header, so that
it doesn’t have to do its own SPF evaluation.
I’m using SpamAssassin in a milter setup with Postfix, and have an SPF
milter that runs before
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,
c.eu>>; Sun, 19 Jul 2020 00:41:16 + (UTC)
>>
>> gives spf fails now, be carefull
>>
>>
> you'll find other mail rejected as well, since someone changed from
> hermes to this mailroute machine...
>
> infra didnt mention anything about the change
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 o
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
and there is an SPF test and it fails, send
to spam directory.
SpamAssassin can't send anything anywhere. SpamAssassin only scores e-mails
and decides if they are spam or ham.
I think SpamAssassin doesn't have DMARC plugin but simple google search
answered:
https://notes.sagredo.eu/en/qmail-notes-185
1 - 100 of 2086 matches
Mail list logo
