Re: "Authentication-Results" header order

2021-06-27 Thread David Bürgin
Hi Kevin,

> I am using two milters to check incoming mail for DKIM signatures and SPF
> records. They are specified in main.cf using the "smtpd_milters" parameter.
> 
> Now,
> when I place the DKIM milter before the SPF milter, like so:
> 
> 
> smtpd_milters = inet:dkim-milter-host:port, inet:spf-milter-host:port
> 
> 
> the final delivered message headers will look like:
> 
> 
> Received: from  ...
> Authentication-Results:  ...
> Received: from  ...
> Authentication-Results:  ...
> Authentication-Results:  auth=pass (login)
> 
> 
> (note the  "Received" header between the two 
> "Authentication-Results" headers)
> 
> 
> 
> When I place the SPF milter before the DKIM milter, like so:
> 
> 
> smtpd_milters = inet:spf-milter-host:port, inet:dkim-milter-host:port
> 
> 
> the final delivered message headers will look like:
> 
> 
> Received: from  ...
> Authentication-Results:  ...
> Authentication-Results:  ...
> Received: from  ...
> Authentication-Results:  auth=pass (login)
> 
> 
> (no  "Received" header between the two 
> "Authentication-Results" headers)

Here is the very technical explanation for your observation.

Milters decide themselves where they want to insert headers, by index.
Depending on the order in which milters run, insertion done by one
milter can shift the insertion point of the next milter.

The sendmail milter API that milters use to insert headers has a bit of
an oddity when using index 0 and 1 to insert: Index 0 inserts *before*
the MTA’s ‘Received’ header, index 1 *after*. When all milters use
index 1, headers will be inserted in (reverse) order after the
‘Received’ header. However, when just one milter uses index 0, all
subsequent milters using index 1 also insert *before* the MTA’s
‘Received’ header. (For details see doc for ‘smfi_insheader’.) This is
what I would guess is happening in your case.

By the way, RFC 8601 says that ‘Authentication-Results’ headers should
be inserted *before* the MTA’s ‘Received’ header. If it is OpenDKIM
you’re talking about, you may be interested in this recent change
request to fix this and make it consistent:

https://github.com/trusteddomainproject/OpenDKIM/pull/126

> 1. Is there a situation in which the order of the "Authentication-Results"
> header matters?
> 
> I tend to think not, since the ones set by the remote MTA and the ones set
> by my milter should be distinguishable based on the "authserv-id" field.
> Is this correct?
> 
> 2. For incoming mail, I like to place the DKIM milter first, before any
> other milter has the chance to change relevant headers.

Personally I prefer to do SPF before DKIM. Because SPF looks at envelope
information, which comes before the data, it seems more logical to check
that first.

> But I think in this particular case it would not matter if SPF is performed
> before DKIM, since as far as I know the Authentication-Results header is
> generally not included in the DKIM signature. So basically the SPF
> authentication header added by my milter should not affect the DKIM
> signature check on the incoming message.
> Is this correct?
> 
> 3. From what I've read, the milters are called in the order they are
> specified.
> 
> But does that mean that for each SMTP event Postfix will call the milters in
> the specified order? Or does it mean that it will call and wait until the
> first milter finishes processing all SMTP events and then it moves on to the
> next milter from the list?
> 
> As far as I can tell it is the first case (otherwise, i guess that in my
> particular case, when the SPF milter is placed after the DKIM milter this
> should be reflected in the order of the auth results headers. But in my case
> the SPF auth results header is always places before the DKIM auth results
> header). I'm not sure the second case would even make sense with the SMTP
> protocol :) .
> 
> Do I understand this correctly?

Ciao,


-- 
David


Re: "Authentication-Results" header order

2021-06-27 Thread Kevin N.

Thank you for the clarification,

Cheers,

Kevin


On 27/06/2021 02:36, Wietse Venema wrote:

Kevin N.:

3. From what I've read, the milters are called in the order they are
specified.

But does that mean that for each SMTP event Postfix will call the
milters in the specified order?


Yes. Each event is given to the first milter, then the second milter,
and so on. Not: all events to the first milter, then all events to
the second milter, and so on.

Wietse



Re: "Authentication-Results" header order

2021-06-27 Thread Kevin N.

Hi David,

Thank you for the detailed explanation.



Milters decide themselves where they want to insert headers, by index.
Depending on the order in which milters run, insertion done by one
milter can shift the insertion point of the next milter.

The sendmail milter API that milters use to insert headers has a bit of
an oddity when using index 0 and 1 to insert: Index 0 inserts *before*
the MTA’s ‘Received’ header, index 1 *after*. When all milters use
index 1, headers will be inserted in (reverse) order after the
‘Received’ header. However, when just one milter uses index 0, all
subsequent milters using index 1 also insert *before* the MTA’s
‘Received’ header. (For details see doc for ‘smfi_insheader’.) This is
what I would guess is happening in your case.


I definitely need to take a closer look at the 'smfi_insheader' docs.



By the way, RFC 8601 says that ‘Authentication-Results’ headers should
be inserted *before* the MTA’s ‘Received’ header. 


I totally missed this part while I was skimming through the RFC.

So, just to make sure that I understand this correctly, the order of the 
"Authentication-Results" headers do matter. Correct?




If it is OpenDKIM you’re talking about, you may be interested in this recent 
change
request to fix this and make it consistent:

https://github.com/trusteddomainproject/OpenDKIM/pull/126


Yes, I was talking about OpenDKIM. I forgot to mention that in my 
initial mail.


I'll take a look at the pull request. Thanks for pointing this out :)



Personally I prefer to do SPF before DKIM. Because SPF looks at envelope
information, which comes before the data, it seems more logical to check
that first.


This actually makes a lot of sense now that you mentioned it :) .
But in this case, can there be a situation in which the 
"Authentication-Results" header added by the SPF check could mess up the 
DKIM signature check?


From what I read, in certain situations, milters running before the 
milter that does the DKIM check, could add headers that would mess up 
the DKIM signature check.


Is it safe to assume that the "Authentication-Results" header added by 
the SPF check is *not* such a case? Or am I misunderstanding this 
completely :) ?




Cheers,

Kevin


Re: "Authentication-Results" header order

2021-06-27 Thread David Bürgin
Kevin N.:
> > Milters decide themselves where they want to insert headers, by index.
> > Depending on the order in which milters run, insertion done by one
> > milter can shift the insertion point of the next milter.
> > 
> > The sendmail milter API that milters use to insert headers has a bit of
> > an oddity when using index 0 and 1 to insert: Index 0 inserts *before*
> > the MTA’s ‘Received’ header, index 1 *after*. When all milters use
> > index 1, headers will be inserted in (reverse) order after the
> > ‘Received’ header. However, when just one milter uses index 0, all
> > subsequent milters using index 1 also insert *before* the MTA’s
> > ‘Received’ header. (For details see doc for ‘smfi_insheader’.) This is
> > what I would guess is happening in your case.
> 
> I definitely need to take a closer look at the 'smfi_insheader' docs.

I forgot the main bit of my explanation. So: If your spf-milter inserts
at index 0 and your dkim-milter inserts at index 1, then the header
order behaviour that you showed is exactly as expected.

> > By the way, RFC 8601 says that ‘Authentication-Results’ headers should
> > be inserted *before* the MTA’s ‘Received’ header.
> 
> I totally missed this part while I was skimming through the RFC.
> 
> So, just to make sure that I understand this correctly, the order of the
> "Authentication-Results" headers do matter. Correct?

RFC 8601 seems to give significance to the relative ordering of
‘Authentication-Results’ and ‘Received’ headers.

> > If it is OpenDKIM you’re talking about, you may be interested in this 
> > recent change
> > request to fix this and make it consistent:
> > 
> > https://github.com/trusteddomainproject/OpenDKIM/pull/126
> 
> Yes, I was talking about OpenDKIM. I forgot to mention that in my initial
> mail.
> 
> I'll take a look at the pull request. Thanks for pointing this out :)
> 
> 
> > Personally I prefer to do SPF before DKIM. Because SPF looks at envelope
> > information, which comes before the data, it seems more logical to check
> > that first.
> 
> This actually makes a lot of sense now that you mentioned it :) .
> But in this case, can there be a situation in which the
> "Authentication-Results" header added by the SPF check could mess up the
> DKIM signature check?
> 
> From what I read, in certain situations, milters running before the milter
> that does the DKIM check, could add headers that would mess up the DKIM
> signature check.
> 
> Is it safe to assume that the "Authentication-Results" header added by the
> SPF check is *not* such a case? Or am I misunderstanding this completely :)
> ?

I hadn’t thought about this in detail but checked quickly. RFC 6376,
sections 5.4.1 and 5.4.2 makes it clear that this is not a problem.

Cheers,


-- 
David


Re: "Authentication-Results" header order

2021-06-27 Thread Kevin N.

Super. Thank you for all the info :)


Cheers,

Kevin


On 28/06/2021 00:04, David Bürgin wrote:

Kevin N.:

Milters decide themselves where they want to insert headers, by index.
Depending on the order in which milters run, insertion done by one
milter can shift the insertion point of the next milter.

The sendmail milter API that milters use to insert headers has a bit of
an oddity when using index 0 and 1 to insert: Index 0 inserts *before*
the MTA’s ‘Received’ header, index 1 *after*. When all milters use
index 1, headers will be inserted in (reverse) order after the
‘Received’ header. However, when just one milter uses index 0, all
subsequent milters using index 1 also insert *before* the MTA’s
‘Received’ header. (For details see doc for ‘smfi_insheader’.) This is
what I would guess is happening in your case.


I definitely need to take a closer look at the 'smfi_insheader' docs.


I forgot the main bit of my explanation. So: If your spf-milter inserts
at index 0 and your dkim-milter inserts at index 1, then the header
order behaviour that you showed is exactly as expected.


By the way, RFC 8601 says that ‘Authentication-Results’ headers should
be inserted *before* the MTA’s ‘Received’ header.


I totally missed this part while I was skimming through the RFC.

So, just to make sure that I understand this correctly, the order of the
"Authentication-Results" headers do matter. Correct?


RFC 8601 seems to give significance to the relative ordering of
‘Authentication-Results’ and ‘Received’ headers.


If it is OpenDKIM you’re talking about, you may be interested in this recent 
change
request to fix this and make it consistent:

https://github.com/trusteddomainproject/OpenDKIM/pull/126


Yes, I was talking about OpenDKIM. I forgot to mention that in my initial
mail.

I'll take a look at the pull request. Thanks for pointing this out :)



Personally I prefer to do SPF before DKIM. Because SPF looks at envelope
information, which comes before the data, it seems more logical to check
that first.


This actually makes a lot of sense now that you mentioned it :) .
But in this case, can there be a situation in which the
"Authentication-Results" header added by the SPF check could mess up the
DKIM signature check?

 From what I read, in certain situations, milters running before the milter
that does the DKIM check, could add headers that would mess up the DKIM
signature check.

Is it safe to assume that the "Authentication-Results" header added by the
SPF check is *not* such a case? Or am I misunderstanding this completely :)
?


I hadn’t thought about this in detail but checked quickly. RFC 6376,
sections 5.4.1 and 5.4.2 makes it clear that this is not a problem.

Cheers,