[exim] Re: Dovecot pidgeonhole transport untaint $sender

Top Page
Delete this message
Reply to this message
Author: Martin Waschbüsch
Date:  
To: exim-users
Subject: [exim] Re: Dovecot pidgeonhole transport untaint $sender


Am 11.05.23 um 20:36 schrieb Bill Cole via Exim-users:
> On 2023-05-11 at 11:39:50 UTC-0400 (Thu, 11 May 2023 17:39:50 +0200)
> Martin Waschbüsch via Exim-users <martin@???>
> is rumored to have said:
>
>> Am 11.05.23 um 17:25 schrieb Jeremy Harris via Exim-users:
>>> On 11/05/2023 16:12, Evgeniy Berdnikov via Exim-users wrote:
>>>>   What about proposal in 1st comment to strip out "-f $sender_address"?
>>>>
>>>>   IMHO, dovecot-lda doesn't need sender address. Unless sieve is used,
>>>>   with explicit reference to sender address.
>>>
>>> I assumed the most likely use of something called "pidginhole"
>>> was delivery to distinct folders, often by inspecting the sender.
>>> But perhaps it can use the From: header?
>>
>> If I read the dovecot docs correctly, lda will use the From: header if
>> present and no -f <sender address> is given:
>>
>> "-f <address>: Envelope sender address. If not specified and message
>> data begins with a valid mbox-style “From ” line, the address is taken
>> from it."
>> (https://doc.dovecot.org/configuration_manual/protocols/lda/)
>
> That's not the "From:" RFC5322 message header, it is the prepended "From
> " (no colon) line that acts as a delimiter for mbox files. That's good,
> because that line contains the envelope sender, which the "From:"
> message header may not.


Important difference. Thank you!

>> However, pidginhole provides extensive sieve language support and you
>> can use almost any piece of an email to move, copy, filter, forward,
>> autoreply, etc.
>> (https://datatracker.ietf.org/doc/html/rfc5228)
>> (https://pigeonhole.dovecot.org/)
>>
>> My guess is: Just removing the -f $sender_address just might change
>> mail processing for some people.
>
> Provided Exim is properly adding the no-colon From line to messages that
> it pipes into dovecot-lda, there should be no change.


Under what circumstances would exim add that line? Those lines are not
currently added on my setup.

(And I would assume for the purpose of the pipe transport, exim is not
adding anything that is storage-format format-specific?)

I could manually force such a line to be written using e.g.
message_prefix, I suppoe. Hm... Would that take us full circle and be
considered using tainted data? :-)

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@???
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/