List of clients: Eudora. I don't know of any others, but I'm sure they're out there. But Eudora still has a large installed base of desktop users, especially in industry and academia where they are site licensed and nobody is eager to upgrade.
The issue isn't so ugly that it can't be hacked around in four lines of code, and isn't so idiosyncratic that it needs to be strewn all over the place to make things work right. I believe that it is limited to the LOGIN command. How about ALT_DOMAIN_CHAR = %, although I think that your suggested pair of config options might be more generally better. I recall once reading that some European keyboards don't have an atsign, so they use $ for their separator. (Although somehow I can't imagine that this hasn't changed since email became the killer application of the Internet...). Aaron Brian Blood <[EMAIL PROTECTED]> said: > > Here's the rub: > > Everybody else does it. > > I know that CGatePro can take both and from what I've gathered most other > MDA's can take both. (We currently use EIMS www.eudora.co.nz, and it > supports either % or @) > > And it's probably 50/50 % vs @ in what our client base has programmed in > (about 500 domains/800 clients) > > Our online docs suggest using % so as to avoid any possible problems with > the older clients. (Is there a definitive list of clients that won't take > @?) > > If it were my code base, this type of substitution would be hard coded in. > I only suggested the conf directives as an intro to the idea. > I guess I could make a patch that we use for our own compiles. > > While I like your usermap patches as a solution to the multiple domains on a > single acct scenario, I think utilizing it to account for a single character > substitution is overkill. > > > Remember the mail server precept, liberal in what you accept, conservative > in what you present. > > > Brian > > On 11/26/03 12:40 PM, "Jesse Norell" <[EMAIL PROTECTED]> wrote: > > > > > Hello Brian, > > > > One way you could handle this is use the usermap patch I posted > > a couple weeks ago. It would require you add a usermap entry for > > each of the user%realm users pointing to the user_idnr of a real > > users entry, but I'd guess the number of your users with broken > > pop3/imap clients affected by this is probably small, so that may > > be a workable solution. Your idea is probably worth consideration, > > but it always "just seems wrong" to me to have to patch one software > > package to work around the brokenness of another (not that it doesn't > > happen all the time, but still...). > > > > Jesse > > > > > > > > ---- Original Message ---- > > From: Brian Blood <dbmail-dev@dbmail.org> > >> an idea on how to handle the realm separator issue (if it still exists): > >> > >> add some directives to the dbmail.conf like: > >> > >> # this is the separator used in usernames in the database > >> DB_REALM_DELIM=@ > >> > >> # This is a list of characters allowed as realm separators > >> # as presented by POP3 or IMAP clients. > >> CLIENT_REALM_DELIM=% > >> > >> > >> a search/replace is done on the username to replace any instances of the > >> characters in CLIENT_REALM_DELIM with DB_REALM_DELIM > >> > >> This code would go in right after the username is presented by the > > client so > >> that it would propagate through the system. > >> > > > > _______________________________________________ > Dbmail-dev mailing list > Dbmail-dev@dbmail.org > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > --
