Mailing List Archive

The message I have tested is spam and I want to add some score when the SPF failed
but my X-Spam-Status looks like

X-Spam-Status: No, score=4.4 required=5.0 tests=DYN_RDNS_SHORT_HELO_HTML,
FSL_HELO_NON_FQDN_1,HELO_NO_DOMAIN,HTML_MESSAGE,MIME_HTML_ONLY,
RCVD_IN_BRBL_LASTEXT,RCVD_IN_RP_RNBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC,
TO_EQ_FM_HTML_ONLY,UNPARSEABLE_RELAY autolearn=no version=3.3.2
X-Spam-Level: ****
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06)

after checking it with command spamassassin -D < /home/admin/test.eml
there is no SPF_FAIL

Thank You for any help

Piotr

----- Original Message -----
From: Piotr Kloc
To: users@spamassassin.apache.org
Sent: Wednesday, March 21, 2012 10:48 PM
Subject: SPF_FAIL


Hello !

I have question why Spamassasssin doesnt add the header SPF_FAIL in X-Spam-Status ?

s61:~# cat sa.log |grep -i spf
mar 21 22:42:40.285 [20073] dbg: config: read file /usr/share/spamassassin/25_spf.cf
mar 21 22:42:40.287 [20073] dbg: config: read file /usr/share/spamassassin/60_whitelist_spf.cf
mar 21 22:42:40.336 [20073] dbg: plugin: loading Mail::SpamAssassin::Plugin::SPF from @INC
mar 21 22:42:40.921 [20073] dbg: plugin: did not register Mail::SpamAssassin::Plugin::SPF, already registered
mar 21 22:42:42.365 [20073] dbg: spf: checking to see if the message has a Received-SPF header that we can use
mar 21 22:42:42.386 [20073] dbg: spf: using Mail::SPF for SPF checks
mar 21 22:42:42.386 [20073] dbg: spf: checking HELO (helo=discus, ip=82.154.150.174)
mar 21 22:42:42.386 [20073] dbg: spf: cannot check HELO of 'discus', skipping
mar 21 22:42:42.389 [20073] dbg: spf: already checked for Received-SPF headers, proceeding with DNS based checks
mar 21 22:42:42.389 [20073] dbg: spf: found Envelope-From in first external Received header
mar 21 22:42:42.389 [20073] dbg: spf: checking EnvelopeFrom (helo=discus, ip=82.154.150.174, envfrom=picturesquek5@ameriton.com)
mar 21 22:42:42.390 [20073] dbg: dns: providing a callback for id: 10955/ameriton.com/SPF/IN
mar 21 22:42:42.404 [20073] dbg: spf: query for picturesquek5@ameriton.com/82.154.150.174/discus: result: none, comment: , text: No applicable sender policy available
mar 21 22:42:42.411 [20073] dbg: spf: def_spf_whitelist_from: already checked spf and didn't get pass, skipping whitelist check
mar 21 22:42:42.413 [20073] dbg: spf: whitelist_from_spf: already checked spf and didn't get pass, skipping whitelist check
mar 21 22:42:42.895 [20073] dbg: timing: total 2614 ms - init: 1502 (57.4%), parse: 1.58 (0.1%), extract_message_metadata: 82 (3.1%), poll_dns_idle: 21 (0.8%), get_uri_detail_list: 1.03 (0.0%), tests_pri_-1000: 19 (0.7%), compile_gen: 163 (6.2%), compile_eval: 55 (2.1%), tests_pri_-950: 5 (0.2%), tests_pri_-900: 6 (0.2%), tests_pri_-400: 5 (0.2%), tests_pri_0: 857 (32.8%), dkim_load_modules: 56 (2.1%), check_dkim_signature: 0.83 (0.0%), check_dkim_adsp: 150 (5.7%), check_spf: 36 (1.4%), check_pyzor: 0.40 (0.0%), tests_pri_500: 77 (3.0%)
s61:~#

I have in my config

score SPF_FAIL 8
score SPF_SOFTFAIL 6
score SPF_NEUTRAL 4

Regards,
Piotr

On 3/21/2012 5:48 PM, Piotr Kloc wrote:
> Hello !
> I have question why Spamassasssin doesnt add the header SPF_FAIL in
> X-Spam-Status ?
> s61:~# cat sa.log |grep -i spf
> mar 21 22:42:40.285 [20073] dbg: config: read file
> /usr/share/spamassassin/25_spf.cf
> mar 21 22:42:40.287 [20073] dbg: config: read file
> /usr/share/spamassassin/60_whitelist_spf.cf
> mar 21 22:42:40.336 [20073] dbg: plugin: loading
> Mail::SpamAssassin::Plugin::SPF from @INC
> mar 21 22:42:40.921 [20073] dbg: plugin: did not register
> Mail::SpamAssassin::Plugin::SPF, already registered
> mar 21 22:42:42.365 [20073] dbg: spf: checking to see if the message
> has a Received-SPF header that we can use
> mar 21 22:42:42.386 [20073] dbg: spf: using Mail::SPF for SPF checks
> mar 21 22:42:42.386 [20073] dbg: spf: checking HELO (helo=discus,
> ip=82.154.150.174)
> mar 21 22:42:42.386 [20073] dbg: spf: cannot check HELO of 'discus',
> skipping
> mar 21 22:42:42.389 [20073] dbg: spf: already checked for Received-SPF
> headers, proceeding with DNS based checks
> mar 21 22:42:42.389 [20073] dbg: spf: found Envelope-From in first
> external Received header
> mar 21 22:42:42.389 [20073] dbg: spf: checking EnvelopeFrom
> (helo=discus, ip=82.154.150.174, envfrom=picturesquek5@ameriton.com
> <mailto:envfrom=picturesquek5@ameriton.com>)
> mar 21 22:42:42.390 [20073] dbg: dns: providing a callback for id:
> 10955/ameriton.com/SPF/IN
> mar 21 22:42:42.404 [20073] dbg: spf: query for
> picturesquek5@ameriton.com/82.154.150.174/discus
> <mailto:picturesquek5@ameriton.com/82.154.150.174/discus>: result:
> none, comment: , text: No applicable sender policy available
> mar 21 22:42:42.411 [20073] dbg: spf: def_spf_whitelist_from: already
> checked spf and didn't get pass, skipping whitelist check
> mar 21 22:42:42.413 [20073] dbg: spf: whitelist_from_spf: already
> checked spf and didn't get pass, skipping whitelist check
> mar 21 22:42:42.895 [20073] dbg: timing: total 2614 ms - init: 1502
> (57.4%), parse: 1.58 (0.1%), extract_message_metadata: 82 (3.1%),
> poll_dns_idle: 21 (0.8%), get_uri_detail_list: 1.03 (0.0%),
> tests_pri_-1000: 19 (0.7%), compile_gen: 163 (6.2%), compile_eval: 55
> (2.1%), tests_pri_-950: 5 (0.2%), tests_pri_-900: 6 (0.2%),
> tests_pri_-400: 5 (0.2%), tests_pri_0: 857 (32.8%), dkim_load_modules:
> 56 (2.1%), check_dkim_signature: 0.83 (0.0%), check_dkim_adsp: 150
> (5.7%), check_spf: 36 (1.4%), check_pyzor: 0.40 (0.0%), tests_pri_500:
> 77 (3.0%)
> s61:~#
> I have in my config
> score SPF_FAIL 8
> score SPF_SOFTFAIL 6
> score SPF_NEUTRAL 4
> Regards,
> Piotr

The Domain in the From in the envelope, ameriton.com, doesn't publish an
SPF Record:

dig -t txt ameriton.com

;; QUESTION SECTION:
;ameriton.com. IN TXT

;; AUTHORITY SECTION:
ameriton.com. 7200 IN SOA NS53.WORLDNIC.com.
namehost.WORLDNIC.com. 111110914 10800 3600 604800 3600

Regards,
KAM

> The Domain in the From in the envelope, ameriton.com, doesn't publish an SPF Record:
>

I know that and I wanted to add some more score when there is no SPF record
its possible to do this with Spamassassin ?

Piotr

Den 2012-03-21 23:00, Piotr Kloc skrev:
>> The Domain in the From in the envelope, ameriton.com, doesn't
> publish an SPF Record:

> I know that and I wanted to add some more score when there is no SPF
> record
> its possible to do this with Spamassassin ?

meta NO_SPF_ON_SENDER_DOMAIN (!SPF_PASS || !SPF_HELO_PASS)

or make one for other spam conditions as you see fit

> I know that and I wanted to add some more score when there is no SPF
> record
> its possible to do this with Spamassassin ?
>
I'm not aware of a "no spf record rule" but the underlying plugin looks
to support what you want. I think you might find that to be a poorly
performing rule except in meta rules, though.

I'm going to add this to the default rules with a score 0 so you can
then just give it a score you want.
header SPF_NONE eval:check_for_spf_none()
describe SPF_NONE SPF sender does not publish an SPF Record
score SPF_NONE 1

regards,
kAM

> I'm going to add this to the default rules with a score 0 so you can
> then just give it a score you want.

I also added spf_helo_none

svn commit -m 'Added a default rule for SPF_NONE that is disabled with
Score 0 for administrators to activate'
Sending rules/25_spf.cf
Sending rules/50_scores.cf
Transmitting file data ..
Committed revision 1303613.

Regards,
KAM

On 3/21/12 6:19 PM, Kevin A. McGrail wrote:
>
>> I know that and I wanted to add some more score when there is no SPF
>> record
>> its possible to do this with Spamassassin ?
>>
> I'm not aware of a "no spf record rule" but the underlying plugin
> looks to support what you want. I think you might find that to be a
> poorly performing rule except in meta rules, though.
>
> I'm going to add this to the default rules with a score 0 so you can
> then just give it a score you want.
> header SPF_NONE eval:check_for_spf_none()
> describe SPF_NONE SPF sender does not publish an SPF Record
> score SPF_NONE 1
>
score of zero? or 1?


> regards,
> kAM


--
Michael Scheidell, CTO
o: 561-999-5000
d: 561-948-2259
>*| *SECNAP Network Security Corporation

* Best Mobile Solutions Product of 2011
* Best Intrusion Prevention Product
* Hot Company Finalist 2011
* Best Email Security Product
* Certified SNORT Integrator

______________________________________________________________________
This email has been scanned and certified safe by SpammerTrap(r).
For Information please see http://www.spammertrap.com/
______________________________________________________________________

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I would be careful about giving points to a non spf enabled site.
My experience is that phishingattempts usually comes from stolen
legitimate accounts on sites with spf enabled.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPas3kAAoJEOVOmoKjmKMkBdUIAJXxv/5F/mpPfCiLnxmPhRV5
91xybuyzCApA/XIx7Fw/QgcbEPBwCLKK5g+XjJ5YKp3cvzXDiG2f9Z2e1/jFmylO
cnx1Kyk0pEwvX90MUEPlKki6qnGCLb4EhP7CYfyIjH0PRdlXBnzlVd/1SxKRU3GQ
6mLGbMUEBfIJZd+I5x84xyas58buFyl2iYt48KCGW6Zzbe+A+gDeJRAfVwkM0xXZ
q69cm17LJOu3KA/SJFSbG0RSpcFZ7BrcPoegFSDMwKAOol0K/qWORSAbtrmiYc9b
uJIaGswKYUa3i6pjY6fXhqR3PrstNyE2k6ZaBLSlZhT3eK8LmL7tuoEOzyPusPc=
=929S
-----END PGP SIGNATURE-----

>> The Domain in the From in the envelope, ameriton.com, doesn't publish an SPF Record:

On 21.03.12 23:00, Piotr Kloc wrote:
>I know that and I wanted to add some more score when there is no SPF record
>its possible to do this with Spamassassin ?

the SPF can only give results (as FAIL, PASS, SOFT*) if SPF records are
set. If they are not set, no SPF test will apply.

I have no idea how to apply rule for "no SPF records on domain, and I
advise you not to make any direct rule related to that. Maybe some
metas, byt I doubt they will help you much.

--
Matus UHLAR - fantomas, uhlar@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 reklamnu postu.
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759

On Thu, 2012-03-22 at 10:26 +0100, Matus UHLAR - fantomas wrote:
> >> The Domain in the From in the envelope, ameriton.com, doesn't publish an SPF Record:
>
> On 21.03.12 23:00, Piotr Kloc wrote:
> >I know that and I wanted to add some more score when there is no SPF record
> >its possible to do this with Spamassassin ?
>
The only sensible use of SPF is to prevent backscatter. This seems to
work well now that most domains are running SPF-aware MTAs.

I don't use SPF for spam detection and can't see any benefit from doing
so.


Martin

I committed score 0. I posted score 1 for the example requested.
Regards,
KAM

Michael Scheidell <michael.scheidell@secnap.com> wrote:
>> I'm going to add this to the default rules with a score 0 so you can
>> then just give it a score you want.
>> header SPF_NONE eval:check_for_spf_none()
>> describe SPF_NONE SPF sender does not publish an SPF
>Record
>> score SPF_NONE 1
>>
>score of zero? or 1?

On Thu, 22 Mar 2012 11:19:04 +0000
Martin Gregorie <martin@gregorie.org> wrote:

> The only sensible use of SPF is to prevent backscatter.

Agreed.

> This seems to work well now that most domains are running SPF-aware
> MTAs.

Disagreed. I don't believe SPF has cut backscatter down by
more than a few percentage points. The vast majority of Exchange
installations don't even reject invalid RCPT commands
(http://david.skoll.ca/blog/2010-12-29-microsoft-dumbness.html)
In fact, I believe this is true even of Microsoft's Hosted Exchange
offering.

There is such an incredibly deep well of ignorance and stupidity among
Microsoft administrators and software designers that it will take
many years of hard work to improve things, if it can even be done at all.

Regards,

David.

Martin Gregorie wrote:
> On Thu, 2012-03-22 at 10:26 +0100, Matus UHLAR - fantomas wrote:
>>>> The Domain in the From in the envelope, ameriton.com, doesn't publish an SPF Record:
>>
>> On 21.03.12 23:00, Piotr Kloc wrote:
>>> I know that and I wanted to add some more score when there is no SPF record
>>> its possible to do this with Spamassassin ?
>>
> The only sensible use of SPF is to prevent backscatter. This seems to
> work well now that most domains are running SPF-aware MTAs.
>

what do you mean with backscatter here?

SPF usually is not part of the MTA but from any kind of milter/filter add-on



> I don't use SPF for spam detection and can't see any benefit from doing
> so.

ok but you can check if the sender is legitimate (obviously this no
criteria about spam yes|no)

may be you should look at SID , then together with it SPF makes much
more sense

of course I agree that the ~ statement in the SPF record is as good as
none, so no point at all

but it is up to you to configure your server as you wish, to accept a
not useful statement or interpret it as fail

IMO, who configures SPF with ~all is showing the bird to all ...

so I take "the bird action" also on my servers

if all would do so, SPF would be taken much more serious by the ~admins
and life could be a little better :)

Hans




--
XTrade Assessory
International Facilitator
BR - US - CA - DE - GB - RU - UK
+55 (11) 4249.2222
http://xtrade.matik.com.br

"David F. Skoll" <dfs@roaringpenguin.com> wrote:

>On Thu, 22 Mar 2012 11:19:04 +0000
>Martin Gregorie <martin@gregorie.org> wrote:
>
>> The only sensible use of SPF is to prevent backscatter.
>
>Agreed.

For the record, I am not promoting spf_none. I am simply answering questions and letting the admin make the choice.

>There is such an incredibly deep well of ignorance and stupidity among
>Microsoft administrators and software designers that it will take
>many years of hard work to improve things, if it can even be done at
>all.

I will comment that this is also a pervasive security model issue. Microsoft and others argue that knowing the emails that work/don't is a security concern. I agree but believe backscatter is the bigger evil. I think Microsoft is in a damned if they do / don't. They have been beaten up for a lack of security and now people don't want it.

On Thu, 2012-03-22 at 07:45 -0400, David F. Skoll wrote:

> Disagreed. I don't believe SPF has cut backscatter down by
> more than a few percentage points.
>
YMMV of course, but it worked for me: when I put up an SPF record
backscatter, which had been a problem at the time, was dramatically
reduced.

Now I don't see any backscatter except for the occasional 'mailbox full'
or 'out of office' message that arrives on a mailing list. I deduce that
greylisting, which my ISP uses, is quite effective at dealing with
backscatter too.


Martin

On Thu, 22 Mar 2012 13:55:50 +0000
Martin Gregorie <martin@gregorie.org> wrote:

> > Disagreed. I don't believe SPF has cut backscatter down by
> > more than a few percentage points.

> YMMV of course, but it worked for me: when I put up an SPF record
> backscatter, which had been a problem at the time, was dramatically
> reduced.

Hmm... OK. I may have been hasty. Assuming that the large providers
like Google, Hotmail, and Yahoo reject SPF-failing mail during the SMTP
transaction, I can see it making a measurable difference.

I still stand by my opinions about the lack of competence of most
Microsoft Exchange admins, though. :)

Regards,

David.

On 3/22/12 10:05 AM, David F. Skoll wrote:
> On Thu, 22 Mar 2012 13:55:50 +0000
> Martin Gregorie<martin@gregorie.org> wrote:
>
>>> Disagreed. I don't believe SPF has cut backscatter down by
>>> more than a few percentage points.
>> YMMV of course, but it worked for me: when I put up an SPF record
>> backscatter, which had been a problem at the time, was dramatically
>> reduced.
> Hmm... OK. I may have been hasty. Assuming that the large providers
> like Google, Hotmail, and Yahoo reject SPF-failing mail during the SMTP
> transaction, I can see it making a measurable difference.
>
> I still stand by my opinions about the lack of competence of most
> Microsoft Exchange admins, though. :)
>
like ip/dns that is not 'round trip' consistent :-)

host colo3.roaringpenguin.com
colo3.roaringpenguin.com has address 70.38.112.54
host 70.38.112.54
54.112.38.70.in-addr.arpa domain name pointer roaringpenguin.com


--
Michael Scheidell, CTO
o: 561-999-5000
d: 561-948-2259
>*| *SECNAP Network Security Corporation

* Best Mobile Solutions Product of 2011
* Best Intrusion Prevention Product
* Hot Company Finalist 2011
* Best Email Security Product
* Certified SNORT Integrator

______________________________________________________________________
This email has been scanned and certified safe by SpammerTrap(r).
For Information please see http://www.spammertrap.com/
______________________________________________________________________

On Thu, 22 Mar 2012 10:09:22 -0400
Michael Scheidell <michael.scheidell@secnap.com> wrote:

> like ip/dns that is not 'round trip' consistent :-)

> host colo3.roaringpenguin.com
> colo3.roaringpenguin.com has address 70.38.112.54
> host 70.38.112.54
> 54.112.38.70.in-addr.arpa domain name pointer roaringpenguin.com

There's absolutely nothing wrong with that.

Round-trip consistency means this:

A_lookup(PTR_lookup(70.38.112.54)) == 70.38.112.54 which is indeed the case.

There's *nothing* to say that PTR_lookup(A_lookup(some_hostname)) is
necessarily some_hostname.

Regards,

David.

On 3/22/2012 4:19 AM, Martin Gregorie wrote:
> The only sensible use of SPF is to prevent backscatter. This seems to
> work well now that most domains are running SPF-aware MTAs. I don't
> use SPF for spam detection and can't see any benefit from doing so.
> Martin

What site competent enough to use SPF is still going to be bouncing
enough mail for it to matter?

SPF (and other authentication methods) are very useful for whitelisting
though since it brings back the ability to whitelist based on sending
domain or address without fear spoofing.

Similarly, it negates the need to manually track sender's IPs for
whitelisting purposes.

--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren

Den 2012-03-22 15:05, David F. Skoll skrev:

> Hmm... OK. I may have been hasty. Assuming that the large providers
> like Google, Hotmail, and Yahoo reject SPF-failing mail during the
> SMTP
> transaction, I can see it making a measurable difference.

are you saying yahoo using spf test, but not provide spf records self
on there domain ?

> I still stand by my opinions about the lack of competence of most
> Microsoft Exchange admins, though. :)

+1

lets have ipv6 now instaed of hearing daily is running out of ipv4 to
there custommers and cliams thay now have to take money pr ipv4, there
is so no intervention to go on ipv6 will only cost more money in loosed
income isp wise

On Thu, 2012-03-22 at 13:55 +0000, Martin Gregorie wrote:


> YMMV of course, but it worked for me: when I put up an SPF record
> backscatter, which had been a problem at the time, was dramatically
> reduced.
>
> Now I don't see any backscatter except for the occasional 'mailbox full'
> or 'out of office' message that arrives on a mailing list.

+1 (big time)

Bill Cole skrev den 2020-11-05 00:21:

> 1. Incorrect SPF records are not rare. Even '-all' records with some
> permitted IPs.

envelope sender changes on nexthop

> 2. Traditional (/etc/aliases, ~/.forward, etc.) transparent forwarding
> breaks SPF.

envelope sender changes on nexthop

nothing is really breaked

On 4 Nov 2020, at 20:42, Benny Pedersen wrote:

> Bill Cole skrev den 2020-11-05 00:21:
>
>> 1. Incorrect SPF records are not rare. Even '-all' records with some
>> permitted IPs.
>
> envelope sender changes on nexthop

Irrelevant to the problem cited, which is simply incorrect records that
fail to list IPs that they should

>
>> 2. Traditional (/etc/aliases, ~/.forward, etc.) transparent
>> forwarding
>> breaks SPF.
>
> envelope sender changes on nexthop

That is simply not true, unless one deploys extraordinary measures such
as SRS. SMTP is not UUCP.

> nothing is really breaked

But in fact, it is. If you use traditional MTA-based forwarding
mechanisms such as /etc/aliases and ~/.forward files, the envelope
sender on an outbound message is the same as it is on the inbound
message. This is why SRS was invented alongside SPF.

Are you maybe thinking of how mailing list managers like Mailman or
majordomo operate?


--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

Bill Cole skrev den 2020-11-05 04:22:
> On 4 Nov 2020, at 20:42, Benny Pedersen wrote:
>
>> Bill Cole skrev den 2020-11-05 00:21:
>>
>>> 1. Incorrect SPF records are not rare. Even '-all' records with some
>>> permitted IPs.
>>
>> envelope sender changes on nexthop
>
> Irrelevant to the problem cited, which is simply incorrect records
> that fail to list IPs that they should

no its not, its not same domain atleast, more or less people say
maillists breaks spf and we need srs to resolve it, maybe why more
maillists does not have spf at all

>>> 2. Traditional (/etc/aliases, ~/.forward, etc.) transparent
>>> forwarding
>>> breaks SPF.
>>
>> envelope sender changes on nexthop
>
> That is simply not true, unless one deploys extraordinary measures
> such as SRS. SMTP is not UUCP.

oh uucp breaks spf :=)

spf is breaked on original envelope sender, the nexthop sender domain
can still have no spf, or spf pass or fail

>> nothing is really breaked
>
> But in fact, it is. If you use traditional MTA-based forwarding
> mechanisms such as /etc/aliases and ~/.forward files, the envelope
> sender on an outbound message is the same as it is on the inbound
> message. This is why SRS was invented alongside SPF.

then you forwards forward with orginal domain as sender, this is the
fail then, forwarding mta should still self make valid spf for there own
domain, and not include missing ips into original sender domain in
envelope from

> Are you maybe thinking of how mailing list managers like Mailman or
> majordomo operate?

postfix maillist have no spf at all, i still get dmarc pass :=)

can read only accounts be solved in spamassassin maillis ?, i just say i
have now added rhsoft to rpz localy

>Bill Cole skrev den 2020-11-05 04:22:
>>On 4 Nov 2020, at 20:42, Benny Pedersen wrote:
>>
>>>Bill Cole skrev den 2020-11-05 00:21:
>>>
>>>>1. Incorrect SPF records are not rare. Even '-all' records with some
>>>>permitted IPs.
>>>
>>>envelope sender changes on nexthop
>>
>>Irrelevant to the problem cited, which is simply incorrect records
>>that fail to list IPs that they should

On 05.11.20 11:52, Benny Pedersen wrote:
>no its not, its not same domain atleast, more or less people say
>maillists breaks spf and we need srs to resolve it, maybe why more
>maillists does not have spf at all

I don't remember anyone saying that. Maybe you confused forwarding and
mailing lists?

>>Are you maybe thinking of how mailing list managers like Mailman or
>>majordomo operate?
>
>postfix maillist have no spf at all, i still get dmarc pass :=)
>
>can read only accounts be solved in spamassassin maillis ?, i just say
>i have now added rhsoft to rpz localy

dmarc can pass even if SPF does not.
dmarc requires either DKIM or SPF pass, with the domain same as From:.


--
Matus UHLAR - fantomas, uhlar@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 reklamnu postu.
- Holmes, what kind of school did you study to be a detective?
- Elementary, Watkins. -- Daffy Duck & Porky Pig

On 5 Nov 2020, at 5:52, Benny Pedersen wrote:

> Bill Cole skrev den 2020-11-05 04:22:
>> On 4 Nov 2020, at 20:42, Benny Pedersen wrote:
>>
>>> Bill Cole skrev den 2020-11-05 00:21:
>>>
>>>> 1. Incorrect SPF records are not rare. Even '-all' records with
>>>> some
>>>> permitted IPs.
>>>
>>> envelope sender changes on nexthop
>>
>> Irrelevant to the problem cited, which is simply incorrect records
>> that fail to list IPs that they should
>
> no its not, its not same domain atleast, more or less people say
> maillists breaks spf and we need srs to resolve it, maybe why more
> maillists does not have spf at all

I believe that we have a language barrier, as I cannot make sense of
that "sentence" and it veers off into the irrelevant issue of mailing
list. I am not up to the task of trying to navigate around that barrier.
I am sorry that we cannot understand each other's words.

--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

John Hardin wrote:
>
> > Moreover, after reading other replies in the thread, I am even begining to
> > doubt the wizdom of rejecting hard SPF fails in the MTA (which I do in
> > some installations).
>
> "it depends".
>
> Doing that for certain domains - like, large banks - would probably be a
> good idea. By default, for all domains, not so much.

If I only had a ready-made list of those important domains.


--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/

> If I only had a ready-made list of those important domains.

If you filter for customer domains then maybe (depending the customer
domain) adding the customer domain to spf checks is worth a look too.


On 11/11/20 6:29 AM, Victor Sudakov wrote:
> John Hardin wrote:
>>
>>> Moreover, after reading other replies in the thread, I am even begining to
>>> doubt the wizdom of rejecting hard SPF fails in the MTA (which I do in
>>> some installations).
>>
>> "it depends".
>>
>> Doing that for certain domains - like, large banks - would probably be a
>> good idea. By default, for all domains, not so much.
>
> If I only had a ready-made list of those important domains.
>
>

On Wed, 2020-11-11 at 09:52 +0100, Tobi wrote:
> > If I only had a ready-made list of those important domains.
>
> If you filter for customer domains then maybe (depending the customer
> domain) adding the customer domain to spf checks is worth a look too.
>
That's easy: keep a database of addresses you've sent mail to and treat
that as a whitelist. Should work at almost any scale and about the only
essential maintenance it needs is the ability to remove addresses you no
longer want to whitelist.

I suppose some may find it useful to datestamp entries with the last
time mail was sent to them and remove any addresses that haven't been
sent mail for 'x' days/weeks/months/years but I've never needed that
ability.

Martin

Martin Gregorie skrev den 2020-11-11 11:02:
> On Wed, 2020-11-11 at 09:52 +0100, Tobi wrote:

> I suppose some may find it useful to datestamp entries with the last
> time mail was sent to them and remove any addresses that haven't been
> sent mail for 'x' days/weeks/months/years but I've never needed that
> ability.

amavisd have penpal
spamassassin have txrep

it require no maintaince at all when configured

but i admit txrep could need more support to this

On Wed, 11 Nov 2020 11:14:05 +0100
Benny Pedersen wrote:

> Martin Gregorie skrev den 2020-11-11 11:02:
> > On Wed, 2020-11-11 at 09:52 +0100, Tobi wrote:
>
> > I suppose some may find it useful to datestamp entries with the last
> > time mail was sent to them and remove any addresses that haven't
> > been sent mail for 'x' days/weeks/months/years but I've never
> > needed that ability.
>
> amavisd have penpal
> spamassassin have txrep

Note that without a DKIM pass, SPF is easily spoofed in TxRep.

DKIM reputations are identified by a combination of header from address
and signing domain. SPF pass reputations are just identified by header
address, without incorporating the envelope domain or requiring
alignment.

>> Martin Gregorie skrev den 2020-11-11 11:02:
>> > On Wed, 2020-11-11 at 09:52 +0100, Tobi wrote:
>>
>> > I suppose some may find it useful to datestamp entries with the last
>> > time mail was sent to them and remove any addresses that haven't
>> > been sent mail for 'x' days/weeks/months/years but I've never
>> > needed that ability.

>On Wed, 11 Nov 2020 11:14:05 +0100
>Benny Pedersen wrote:
>> amavisd have penpal
>> spamassassin have txrep

On 11.11.20 15:41, RW wrote:
>Note that without a DKIM pass, SPF is easily spoofed in TxRep.

is it? how does that work then?

>DKIM reputations are identified by a combination of header from address
>and signing domain. SPF pass reputations are just identified by header
>address, without incorporating the envelope domain or requiring
>alignment.

--
Matus UHLAR - fantomas, uhlar@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 reklamnu postu.
"To Boot or not to Boot, that's the question." [WD1270 Caviar]

Matus UHLAR - fantomas skrev den 2020-11-11 17:01:
>>> Martin Gregorie skrev den 2020-11-11 11:02:
>>> > On Wed, 2020-11-11 at 09:52 +0100, Tobi wrote:

> On 11.11.20 15:41, RW wrote:
>> Note that without a DKIM pass, SPF is easily spoofed in TxRep.
>
> is it? how does that work then?

signedby tracking in awl and txrep

but not signed, does just group them as not signed, it still is
reputition

>Matus UHLAR - fantomas skrev den 2020-11-11 17:01:
>>>>Martin Gregorie skrev den 2020-11-11 11:02:
>>>>> On Wed, 2020-11-11 at 09:52 +0100, Tobi wrote:
>
>>On 11.11.20 15:41, RW wrote:
>>>Note that without a DKIM pass, SPF is easily spoofed in TxRep.
>>
>>is it? how does that work then?

On 11.11.20 17:20, Benny Pedersen wrote:
>signedby tracking in awl and txrep
>
>but not signed, does just group them as not signed, it still is
>reputition

can you please describe deeper?

how is it spoofed? does it ignore SPF sometimes, and takes for correct
otherwise?
--
Matus UHLAR - fantomas, uhlar@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 reklamnu postu.
Fucking windows! Bring Bill Gates! (Southpark the movie)

On Wed, 11 Nov 2020 17:01:21 +0100

> On 11.11.20 15:41, RW wrote:
> >Note that without a DKIM pass, SPF is easily spoofed in TxRep.
>
> is it? how does that work then?

It's implicit in the next bit.

> >DKIM reputations are identified by a combination of header from
> >address and signing domain. SPF pass reputations are just identified
> >by header address, without incorporating the envelope domain or
> >requiring alignment.

These two cases share the same "authenticated" primary reputation:

Return-path: ceo@example.com
From: ceo@example.com

Return-path: someone@somewhereelse.com
From: ceo@example.com

The benefit of this could be substantial, particularly with
txrep_learn_bonus set. All you have to do is make sure the envelope
sender passes SPF.

To be honest I haven't verified this, but the code looks
straightforward. $signedby gets set to the tag DKIMDOMAIN or falls
back to the fixed string 'spf' for an SPF pass.

>On Wed, 11 Nov 2020 17:01:21 +0100
>
>> On 11.11.20 15:41, RW wrote:
>> >Note that without a DKIM pass, SPF is easily spoofed in TxRep.
>>
>> is it? how does that work then?
>
>It's implicit in the next bit.
>
>> >DKIM reputations are identified by a combination of header from
>> >address and signing domain. SPF pass reputations are just identified
>> >by header address, without incorporating the envelope domain or
>> >requiring alignment.

On 11.11.20 19:06, RW wrote:
>These two cases share the same "authenticated" primary reputation:
>
> Return-path: ceo@example.com
> From: ceo@example.com
>
> Return-path: someone@somewhereelse.com
> From: ceo@example.com
>
>The benefit of this could be substantial, particularly with
>txrep_learn_bonus set. All you have to do is make sure the envelope
>sender passes SPF.
>
>To be honest I haven't verified this, but the code looks
>straightforward. $signedby gets set to the tag DKIMDOMAIN or falls
>back to the fixed string 'spf' for an SPF pass.

sorry, I'm not into txrep much for now.

Does it mean, that txrep correctly compares Return-Path (or any header that
is filled by envelope from), but incorrectly adds bonus to address in From:
header?

--
Matus UHLAR - fantomas, uhlar@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 reklamnu postu.
WinError #98652: Operation completed successfully.

On Thu, 12 Nov 2020 12:34:25 +0100
Matus UHLAR - fantomas wrote:

> >On Wed, 11 Nov 2020 17:01:21 +0100
> >
> >> On 11.11.20 15:41, RW wrote:

> On 11.11.20 19:06, RW wrote:
> >These two cases share the same "authenticated" primary reputation:
> >
> > Return-path: ceo@example.com
> > From: ceo@example.com
> >
> > Return-path: someone@somewhereelse.com
> > From: ceo@example.com
> >
> >The benefit of this could be substantial, particularly with
> >txrep_learn_bonus set. All you have to do is make sure the envelope
> >sender passes SPF.
> >
> >To be honest I haven't verified this, but the code looks
> >straightforward. $signedby gets set to the tag DKIMDOMAIN or falls
> >back to the fixed string 'spf' for an SPF pass.
>
> sorry, I'm not into txrep much for now.
>
> Does it mean, that txrep correctly compares Return-Path (or any
> header that is filled by envelope from), but incorrectly adds bonus
> to address in From: header?

When there's a valid DKIM signature TxRep identifies the main reputation
with a combination of "header from" and the signing domain. It doesn't
require DMARC style alignment, but that's not easily exploitable because
signing with a different domain creates a new reputation.

With SPF a pass is simply treated as having authenticated the "header
from" regardless of the "envelope from" that was used in SPF. This
allows an existing good reputation to be exploited easily - even
accidentally.

An improvement would be to handle SPF like DKIM, using the envelope
domain like a signing domain.