zonie via Postfix-users: > > > > Wietse Venema via Postfix-users <postfix-users@postfix.org>: > > > > ?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 -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org