Sending the local TCP port with Dovecot SASL

[Phil Vandry]

Hello Postfix developpers,

When Postfix sends a SASL authentication request to Dovecot,
it includes the local IP address and remote IP address of the TCP
connection. Dovecot also supports receiving the local and remote TCP
ports (and other things besides) but Postfix doesn't send them.

I have a use case where Postfix is listining on hundreds of different
TCP ports, and Dovecot needs to know on which SMTP server the connection
was received in order to authenticate the user.

It isn't difficult to add the local TCP port number to the Dovecot
SASL request. May I suggest that this be added?

-Phil

[Wietse Venema]

Post by Phil Vandry
Hello Postfix developpers,
When Postfix sends a SASL authentication request to Dovecot,
it includes the local IP address and remote IP address of the TCP
connection. Dovecot also supports receiving the local and remote TCP
ports (and other things besides) but Postfix doesn't send them.
I have a use case where Postfix is listining on hundreds of different
TCP ports, and Dovecot needs to know on which SMTP server the connection
was received in order to authenticate the user.
It isn't difficult to add the local TCP port number to the Dovecot
SASL request. May I suggest that this be added?

You may suggest, but you may not know what you're asking for. Adding
server (local) port support to Postfix was discussed a few weeks
ago here.

For consistency server port support needs to work in the exact same
way as the existing code for client (remote) port support. According
to "grep -i client_port" there are 139 lines of code with "client_port"
or "CLIENT_PORT", over 39 different C source or include files
(including the embedded manpages in those files). Similar code would
be needed for server port support without WTF surprises.

The large code footprint is the result of many different contexts
where the information is used; it won't siply shrink with "better"
code decomposition. The contexts range from server-side XCLIENT and
XFORWARD support in smtpd(8), code that writes or reads queue files
in cleanup(8) and qmgr(8), code that sends or receives delivery
requests between qmgr(8) and delivery agents, to client-side XFORWARD
support in smtp(8) and smtpd(8) (the latter to support before-queue
content filters).

Wietse

[Phil Vandry]

Post by Wietse Venema

Post by Phil Vandry
It isn't difficult to add the local TCP port number to the Dovecot
SASL request. May I suggest that this be added?

You may suggest, but you may not know what you're asking for. Adding
server (local) port support to Postfix was discussed a few weeks
ago here.

I'm sorry, I hope I'm not duplicating anything... but I didn't see
this topic in the list archive.

Post by Wietse Venema
For consistency server port support needs to work in the exact same
way as the existing code for client (remote) port support. According

It sounds like you're saying that support for testing the server port
shouldn't be added at all unless it is added consistently throughout
Postfix.

I disagree that just applying my patch to the Dovecot SASL code
without adding support for the server port in many other places in
Postfix would cause user surprises. The fact that you would be able
to meaningfully use "%a" (a Dovecot variable that expands to the
server port number) somewhere Dovecot auth configuration doesn't
imply anything to users about what you can and can't do in Postfix.
Rather, it is more likely that the current behaviour causes a surprise:
Dovecot knows the port number is 143 when it authenticates an IMAP
request but it thinks it's 0 (because it doesn't know it) when it
authenticates an SMTP request.

-Phil

[Wietse Venema]

Post by Phil Vandry

Post by Wietse Venema

Post by Phil Vandry
It isn't difficult to add the local TCP port number to the Dovecot
SASL request. May I suggest that this be added?

You may suggest, but you may not know what you're asking for. Adding
server (local) port support to Postfix was discussed a few weeks
ago here.

I'm sorry, I hope I'm not duplicating anything... but I didn't see
this topic in the list archive.

Post by Wietse Venema
For consistency server port support needs to work in the exact same
way as the existing code for client (remote) port support. According

It sounds like you're saying that support for testing the server port
shouldn't be added at all unless it is added consistently throughout
Postfix.

Indeed. There are few things as frustrating as a feature that
works only in some setttings and that lets users down in
other settings.

Post by Phil Vandry
I disagree that just applying my patch to the Dovecot SASL code
without adding support for the server port in many other places in
Postfix would cause user surprises. The fact that you would be able

Postfix allows a client to connect to the server through a proxy.
Naively doing a getsockname() call on the SMTP server's file
descriptor would produce an incorrect result (the port of the
proxy-to-Postfix connection). The correct result uses the port
(and IP address) of the client-to-proxy connection. And that is
just one scenario that uses ports and that you weren't aware of.

This is what I mean that a feature works only in some settings
and lets users down in others, causing surprises and frustration.

Wietse

[Phil Vandry]

Post by Wietse Venema
Postfix allows a client to connect to the server through a proxy.
Naively doing a getsockname() call on the SMTP server's file
descriptor would produce an incorrect result (the port of the
proxy-to-Postfix connection). The correct result uses the port
(and IP address) of the client-to-proxy connection. And that is
just one scenario that uses ports and that you weren't aware of.

Understood. Yet I didn't add the getsockname(). It was already there.
Presumably that means that the server IP address that is
handed to Dovecot was already wrong (under some circumstances).

-Phil

[Wietse Venema]

Post by Phil Vandry

Post by Wietse Venema
Postfix allows a client to connect to the server through a proxy.
Naively doing a getsockname() call on the SMTP server's file
descriptor would produce an incorrect result (the port of the
proxy-to-Postfix connection). The correct result uses the port
(and IP address) of the client-to-proxy connection. And that is
just one scenario that uses ports and that you weren't aware of.

Understood. Yet I didn't add the getsockname(). It was already there.
Presumably that means that the server IP address that is
handed to Dovecot was already wrong (under some circumstances).

The getsockname() call was already clearly flagged in the code with
XXX as a temporary workaround that doesn't belong there.

I worked on proxied client support several years later. And since
this getsockname() call was hidden in a place where it does not
belong, this call was overlooked, resulting in broken code.

So now you have seen with your own eyes how bad temporay hacks are.
They just make a big stinking mess of the system. I've spent the
last one-third of the Postfix 2.9 development cycle cleaning up.

Wietse