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
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
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
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
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
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
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
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
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
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
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: mail
11 matches
Mail list logo
