Mailing List Archive

On 17/09/2020 23:30, Jim Fenton via Exim-users wrote:
> So instead I have tried putting into my mail_spool transport:
>
> headers_add = ${authresults {$primary_hostname}}
>
> but I'm not seeing the header field in locally-delivered messages (yes,
> I am using mail_spool local delivery). Is this the wrong approach?

It's not one I'd considered. My assumption was that since
one does authentication in the various ways as Exim accepts
the message, that was when the results would be recorded.
Obviously I wasn't thinking hard enough.

I think it will mostly, but not quite all, work.
Bits of the ARC info, for example, I think will not.
Basically, all the items that are made
available as exim variables will be ok (because they get
passed along with the message even in spool files).
Other info will not.

[. you're going to really confuse me, using a transport called
"mail_spool". What are you really trying to do? ]


You could, in acl, plonk the header string into a variable
which this one transport then used to add it as a header.
--
Cheers,
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 9/18/20 5:09 PM, Jeremy Harris via Exim-users wrote:
> On 17/09/2020 23:30, Jim Fenton via Exim-users wrote:
>> So instead I have tried putting into my mail_spool transport:
>>
>> headers_add = ${authresults {$primary_hostname}}
>>
>> but I'm not seeing the header field in locally-delivered messages (yes,
>> I am using mail_spool local delivery). Is this the wrong approach?
> It's not one I'd considered. My assumption was that since
> one does authentication in the various ways as Exim accepts
> the message, that was when the results would be recorded.
> Obviously I wasn't thinking hard enough.
>
> I think it will mostly, but not quite all, work.
> Bits of the ARC info, for example, I think will not.
> Basically, all the items that are made
> available as exim variables will be ok (because they get
> passed along with the message even in spool files).
> Other info will not.
>
> [. you're going to really confuse me, using a transport called
> "mail_spool". What are you really trying to do? ]

I hadn't realized, but apparently the mail_spool transport is part of
the config that's distributed with Debian, and not a generic Exim4
thing. Basically what I'm trying to do is get all locally delivered mail
to have the Authentication-results header field added, but not messages
sent externally (external domains should do their own email
authentication anyway, and I don't want to pollute outgoing messages
with non-useful stuff).

I discovered that the message wasn't actually going to the mail_spool
transport anyway, because I have a .procmailrc file. The procmail router
in my config sends it to a different transport, procmail_pipe, in that
case. So I had the headers_add in the wrong place.

>
> You could, in acl, plonk the header string into a variable
> which this one transport then used to add it as a header.

With it in the right transport (or the right router), it does add the
authentication-results header field, but without the DKIM info. This
suggestion will help with that. But I still have the problem that I want
to put the new header field at the beginning, not the end, of the
header. The ":at_start:" thing works for add_header in ACLs, but not for
headers_add in routers or transports. I'm not sure how to fix that.

Related question: when a router does a headers_add, does it only do that
if that router accepts? Or does the header field get added when a
subsequent router accepts? If the former, I need to add the header field
in several local-ish routers.

-Jim



--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 19/09/2020 05:08, Jim Fenton via Exim-users wrote:
> On 9/18/20 5:09 PM, Jeremy Harris via Exim-users wrote:
> Related question: when a router does a headers_add, does it only do that
> if that router accepts?

The documentation does say, in the obvious place:

"a list of text headers [...] that is associated with any addresses that
are accepted by the router"
--
Cheers,
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 18 Sep 2020, at 17:09, Jeremy Harris via Exim-users wrote:

> On 17/09/2020 23:30, Jim Fenton via Exim-users wrote:
>> So instead I have tried putting into my mail_spool transport:
>>
>> headers_add = ${authresults {$primary_hostname}}
>>
>> but I'm not seeing the header field in locally-delivered messages
>> (yes,
>> I am using mail_spool local delivery). Is this the wrong approach?
>
> It's not one I'd considered. My assumption was that since
> one does authentication in the various ways as Exim accepts
> the message, that was when the results would be recorded.
> Obviously I wasn't thinking hard enough.
>
> I think it will mostly, but not quite all, work.
> Bits of the ARC info, for example, I think will not.
> Basically, all the items that are made
> available as exim variables will be ok (because they get
> passed along with the message even in spool files).
> Other info will not.

That’s what happened; the DKIM authentication results were not
included when the header field was added in this manner.

> You could, in acl, plonk the header string into a variable
> which this one transport then used to add it as a header.

This must be the way to go (haven’t done this yet). But when I put the
above line into the appropriate router config, an Exam process crashed
with a segmentation violation when I locally sent a message to myself
(the message was queued, and this happened on each queue run).
Apparently those variables aren’t always populated. I’m not sure
whether this would be considered a bug or just a misconfiguration, but
I’m happy to create a bug report if appropriate.

-Jim

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 22/09/2020 01:41, Jim Fenton via Exim-users wrote:
> I’m not sure whether
> this would be considered a bug or just a misconfiguration, but I’m happy
> to create a bug report if appropriate.

Yes please; any crash that can be induced by a particular config is
a bug, even if the config is not supported.
--
Cheers,
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/