On Wed, Nov 13, 2019 at 03:14:36AM +0100, Ján Lalinský wrote:
> Thanks for the insights. However, I am optimistic that for smtp sessions
> this can be made to (mostly) work, because the check for UID of the
> process holding the client port can be done some time after SMTP
> commands have been received by Postfix, at which point the connection is
> already established.
It may work for you, but my experience with Firefox showed that
visibility of the peer uid could be noticeably delayed beyond
connection setup. In any case, there are potentially both reliability
and portability roadblocks do adding built-in support for this in
Postfix.
> I haven't found any mention suggesting authd is not reliable (except for
> some bugs on Redhat bugzilla which got solved). Do you think it is not
> reliable, when the query is made after the TCP connection is established
> and Postfix has received the RCPT TO command?
I am not aware of any guarantee of timely visibility of the peer uid
data, it often works, and for some clients (e.g. the already mentioned
Firefox) often does not.
> If this works, the next question would be, is it possible to pass the
> UID to Postfix as well and use that UID in Postfix config to alter its
> behaviour when processing the email? For example, the UID should be
> logged next to email ID to /var/log/maillog.
You can add a header (PREPEND action), and perhaps some milter might
then be able to react to that header. Don't recall whether PREPEND
is available as an action in front of pre-queue proxy filters.
--
Viktor.
