Mailing List Archive

>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.