Re: SPF plugin ignores existing Authentication-Results

o see Authentication-Results: headers from other milter, the other milter must run before milter using SA (spamass-milter, amavisd-milter, etc) SA milter has to synthetize the Received: header it passsed with mail to SpamAssassin.  If it prepends Received: header (as expected), the Authentication-Re

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

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 a

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 "Receiv

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

Re: SPF plugin ignores existing Authentication-Results

rom now) has to see Authentication-Results: headers from other milter, the other milter must run before milter using SA (spamass-milter, amavisd-milter, etc) SA milter has to synthetize the Received: header it passsed with mail to SpamAssassin. If it prepends Received: header (as expected), 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 sho

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

Re: SPF plugin ignores existing Authentication-Results

SpamAssassin 3.4.4-1ubuntu1.1 on Ubuntu Server 20.04. Oh, it actually cannot work. SpamAssassin only accepts Authentication-Results that come *before* an ‘internal’ Received header (https://cwiki.apache.org/confluence/display/SPAMASSASSIN/TrustedRelays). I use SpamAssassin as a milter, so the

SPF plugin ignores existing Authentication-Results

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

Re: Make SpamAssassin use SPF results in an Authentication-Results header?

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’m us

Make SpamAssassin use SPF results in an Authentication-Results header?

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

Re: Authentication-Results

Geoffrey Leach skrev den 2013-11-10 21:58: Are there any rules for analyzing Authentication-Results headers? you open a can of worms asking this :=) http://spamassassin.1065346.n5.nabble.com/Creating-new-rules-td105984.html well i still miss to see dmarc testing in sa subject is done if its

Authentication-Results

Are there any rules for analyzing Authentication-Results headers?

Re: Interpreting an Authentication-Results: header ?

trying to rerun the SPF and DKIM checks itself? in sa-3.3.2/Plugin/SPF.pm is still code like this: if ($hdr =~ /^received-spf:) { // parse & return } elsif ($hdr =~ /^Authentication-Results:) { // parse & return } check_spf Maybe it's simply not documented ... i think we just need

Re: Interpreting an Authentication-Results: header ?

this: if ($hdr =~ /^received-spf:) { // parse & return } elsif ($hdr =~ /^Authentication-Results:) { // parse & return } check_spf Maybe it's simply not documented ... Andreas

Re: Interpreting an Authentication-Results: header ?

* Shankar : > Unsubscribe. list-help: list-unsubscribe: List-Post: List-Id: -- Ralf Hildebrandt Charite Universitätsmedizin Berlin ralf.hildebr

Re: Interpreting an Authentication-Results: header ?

> > > >Agreed. I think it would also - at the trust boundary - need a filter > before > >the DKIM/SPF verifier that adds the Authentication-Results: header. Its > job > >would be to remove any Authentication-Results: that claim to belong to > ones > >own ADMD. &g

Re: Interpreting an Authentication-Results: header ?

e >the DKIM/SPF verifier that adds the Authentication-Results: header. Its job >would be to remove any Authentication-Results: that claim to belong to ones >own ADMD. You might want to reread section 5 of RFC 5451. That's already in the A-R spec. R's, John

Re: Interpreting an Authentication-Results: header ?

default for the authid. Agreed. I think it would also - at the trust boundary - need a filter before the DKIM/SPF verifier that adds the Authentication-Results: header. Its job would be to remove any Authentication-Results: that

Re: Interpreting an Authentication-Results: header ?

>IIRC there isn't at the moment. One thought that comes to mind immediately: > >If there were it should not be enabled by default or others will try to forge >the results. It should only be enabled if a "trust boundary" > has been established. The >do

Re: Interpreting an Authentication-Results: header ?

John, * John Levine : > The Authentication-Results: header defined in RFC 5451 can describe > the SPF and DKIM status of a message. It's typically added by the > SMTP daemon as the message is received. > > Is there any way to tell spamassassin to look at the A-R header rat

Re: Interpreting an Authentication-Results: header ?

On Fri, 2013-03-29 at 00:56 +, John Levine wrote: > The Authentication-Results: header defined in RFC 5451 can describe > the SPF and DKIM status of a message. It's typically added by the > SMTP daemon as the message is received. > > Is there any way to tell spamassassi

Interpreting an Authentication-Results: header ?

The Authentication-Results: header defined in RFC 5451 can describe the SPF and DKIM status of a message. It's typically added by the SMTP daemon as the message is received. Is there any way to tell spamassassin to look at the A-R header rather than trying to rerun the SPF and DKIM c