Hello,
I'll throw out a comment, on a similar need we have,
and maybe they can both get solved together. We intend
to use [EMAIL PROTECTED] type usernames, but for some historic
accounts we still need to support a plain username (no
@domain) login, till we can get completely transitioned.
This would be a nice feature for anyone wanting to transition
from a realm-less setup to a realmed setup. I was going to
start adding this in for us soon - the easiest/bandaided
method that came to mind was a new table of accepted login
names and user_idnrs, and have the pop3/imap daemons look up
the user_idnr from there.
-- From "Mark Mackay" --
> I has similar problems when investigating this earlier on, and even more so
> when I had hoped to have multiple pop3/imap deaemons on the same machines
> listing for different ISPs.
>
> My ultimate plan is to different pop3/imap daemons consult either a
> different user database, or a single userdatabase but with 2 keys (eg.
> Username and ISP/Company code => thereby allowing duplicate usernames. As
> dbmail for the most part refers to mail messages and mailboxes by a numeric
> ID, you could have a mark/ISPA and mark/ISPB which didn't need to log in by
> realm ("[EMAIL PROTECTED]" / "[EMAIL PROTECTED]"). The differention for me
> would be IP
> address:
>
> Therefore I need to be able to have POP3/IMAP listening on say
>
> 10.0.0.1 - doing a lookup from dbmail users with a userid of "mark" and say
> "virtualcode" of "ISPA" ('virtualcode' being a new column in the dbmail
> users table).
>
> 10.0.0.2 - could do a lookup from dbmail users with userid of "mark" and
> virtualcode="ISPB"
>
>
> No-one commented back on whether people liked this idea or not, so I'd
> welcome comments now that dbmail is starting to be used in more production
> environments and the list is getting bigger.
--
Jesse Norell
[EMAIL PROTECTED]
