Thanks Gilles. I puzzled it out and it's working great now.

On Sat, Sep 1, 2018 at 1:50 PM Gilles Chehade wrote:
>
> On Sat, Sep 01, 2018 at 11:59:20AM -0400, Matt Schwartz wrote:
> > I am afraid that I am hopelessly confused on the userbase parameter.
> > If I were to have the following:
> >
> > # credentials
> > user1      <encrypted_password_goes_here>
> >
> > # userinfo
> > # vmail user is 2000
> > user1      2000:2000:/var/vmail/user1
> >
> > # virtuals
> > us...@domain1.com      vmail
> >
> > [...]
> >
> > In theory, shouldn't this deliver email addressed to us...@domain1.com
> > to /var/vmail/user1/Maildir/new?
> >
>
> you got the configuration file wrong again, despite having it right with
> the comment itself:
>
> > # vmail user is 2000
> > user1      2000:2000:/var/vmail/user1
>
>
> I'll describe how things work in this mail so it serves as reference for
> future questions regarding aliases, virtual and userbase:
>
> Aliases and virtuals are mutually exclusive features that operate at the
> same level, converting an e-mail address into a local user.
>
> Userbases operate at a lower level, allowing to lookup system details of
> a local user such as uid, gid and home directory.
>
> You don't have to have aliases or virtuals, but you MUST have a userbase
> which defaults to the system user database when you don't specify one.
>
> Aliases and virtuals can be seen as functions that take an e-mail as the
> input and produce usernames that _MUST_ exist in the underlying userbase
> as the output, otherwise the recipient will be rejected.
>
> The difference between aliases and virtuals is subtle but simple:
>
> - aliases assume that all users on the system are allowed to get e-mails
>   and that the user-part of recipient e-mail addresses are the usernames
>   on the system. the mechanism allows you to provide an OPTIONAL list of
>   transformations in case some recipients have user-parts that are not a
>   system user, and it assumes that if no alias is found, then user-parts
>   must be looked up as real usernames.
>
> - virtuals assume that users are NOT allowed to get e-mails, unless they
>   are EXPLICITELY allowed on a list. either a transform is found and the
>   recipient is converted into a username, or the recipient is rejected.
>
>
> You can receive e-mail if you're not in the aliases list, if you have an
> account on the system with a username matching the user-part.
>
> You can't receive e-mail if you're not in the virtuals list, EVEN if you
> have an account matching the user-part.
>
>
> Now with that being said, converting a recipient into a username doesn't
> help us much if that username doesn't exist for real. We need a uid, gid
> and a home directory, so no matter if you used aliases, virtuals or none
> of them, the username behind a recipient must be found in the user base.
>
> If I take your example:
>
>
> > # vmail user is 2000
> > user1      2000:2000:/var/vmail/user1
> >
> > # virtuals
> > us...@domain1.com      vmail
>
> you have resolved us...@domain1.com into the user 'vmail'.
> then we lookup the user 'vmail' in the userbase and ... nope, not found.
>
> Hope it clears it for everyone.
>
>
> --
> Gilles Chehade
>
> https://www.poolp.org                                          @poolpOrg

-- 
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org

Reply via email to