zonie via Postfix-users:
>
>
> > Wietse Venema via Postfix-users <[email protected]>:
> >
> > ?zonie via Postfix-users:
> >> Hello,
> >>
> >> currently it's not possible to specify a username containing a colon ?:?
> >> inside a ?smtp_sasl_password_map?, as the colon is used to split username
> >> and password from each other.
> >>
> >> Is this limitation intentionally or was it just overlooked?
> >
> > Just like the UNIX login name, the SASL login name can't contain
> > ':'. With Cyrus SASL configurations, they can be the same thing.
>
> What do you mean by "they can be the same thing"?
They = the UNIX login name, the SASL login name
> I understand when you say this limitation counts for postfix server
> SASL configuration, as you mention the UNIX login name. In my case
> it's the mail provider who awaits the colon placed in the username
> and on postfix side it's just in the smtp client config. Postfix
> should be no more frightened by a colon than by all other special
> characters that can be specified now. And I think the colon is not
> one of the bad ones, if there are any.
There has to be a way to separate fields. If we support a different
syntax, then that will have to implemented as an option, it cannot
be the default because that would break existing configutations.
> Would it be possible to introduce an escape char for
> use inside a SASL username to circumvent this limitation.
If we change the syntax of smtp_sasl_password_maps entries, then
that will require a new configuration parameter to indicate how the
lookup result should be parsed.
My preference would be:
smtp_sasl_password_map_result_delimiter
printable character or C escape (like \t for TAB)
default = : (for backwards compatibility)
must not be empty
must not be multiple characters
I think that TAB would be sagfe for your case, unlikely to conflict
with anything in a username or password.
Less preferred, because most of Postfix configuration
does not support \
smtp_sasl_password_map_result_escape
printable character, like \
default = empty (for backwards compatibility)
disabled when empty
There are other approaches, like protecting text with quotes, like
"foo:bar":password, or prepending a length to each field value, like
7:foo:bar8:password.
Wietse
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
