Loading ...
Sorry, an error occurred while loading the content.
 

Re: Local UNIX accounts, aliasing & rejecting mail to non-public UNIX accounts

Expand Messages
  • Craig R. Skinner
    ... Correct - refer back to earlier messages in the last few days. ... Yes, that s my thinking of how aliases functions. (See below.) ... That could explain
    Message 1 of 37 , Jun 24, 2013
      On 2013-06-24 Mon 12:34 PM |, /dev/rob0 wrote:
      > On Mon, Jun 24, 2013 at 03:12:24PM +0100, Craig R. Skinner wrote:
      > > main.cf:
      > > myorigin = $mydomain # example.com
      > > mydestination = localhost, localhost.$mydomain
      >
      > Here we see that $myorigin (nor $mydomain) is listed in
      > $mydestination.
      >

      Correct - refer back to earlier messages in the last few days.

      > > However, aliases seems to be totally ignored.
      > >
      > > When I move these from virtual_alias_maps back to aliases,
      > > mail to those convential aliases bounces:
      > >
      > > aliases:
      > > root: admin-acct
      >
      > I don't know if this was mentioned upthread or not, but you seem to
      > be making a common, wrong assumption about the meaning of an
      > unqualified address localpart, e.g., "admin-acct" in this example.
      > You're probably thinking that means "deliver to the Unix user
      > 'admin-acct'",

      Yes, that's my thinking of how aliases functions. (See below.)

      > when in fact it means "deliver to the address 'admin-acct@$myorigin'".
      > If $myorigin (which you set to $mydomain) is not listed in
      > $mydestination, local(8) delivery is not used.
      >

      That could explain it.

      > Likewise, aliases(5) ($alias_maps) are only consulted for addresses
      > where the domain is listed in $mydestination. For you, that's only
      > localpart@localhost.$mydomain (or "localpart@localhost" also if you
      > followed Jeroen's suggestion of "append_dot_mydomain=no".)
      >
      > OTOH virtual(5) ($virtual_alias_maps) mapping is applied to all
      > addresses, regardless of class.
      >
      > Generally I'd say it's a best practice to always specify
      > fully-qualified addresses on the RHS of $alias_maps

      The default aliases file does not indicate that;-

      "The aliases(5) table provides a system-wide mechanism to redirect mail for LOCAL recipients."

      "Users can control delivery of their own mail by setting up .forward files in their home directory."

      Which seems to mean that addresses on the RHS are often Unix accounts.

      # The format of the alias database input file is as follows:
      #
      # o An alias definition has the form
      #
      # name: value1, value2, ...
      #
      # The name is a local address (no domain part).
      #
      # The value contains one or more of the following:
      #
      # address
      # Mail is forwarded to address, which is compatible
      # with the RFC 822 standard.

      Which to my reading means the RHS does not require the domain when it is
      a local Unix account. i.e. mail from Unix user56 to root is aliased.

      > > $ uptime | mail -s uptime root
      >
      > Here you have deliberately used an unqualified localpart as if it was
      > an email address.
      >

      Naturally. Cron, mutt, sendmail, etc must work too. Hence the local Unix
      accounts as opposed to a vmail setup.

      > > Jun 24 14:37:25 server1 postfix/pickup[29745]: C15E367DC: uid=7432 from=<admin-acct>
      > > Jun 24 14:37:25 server1 postfix/cleanup[20891]: C15E367DC: message-id=<20130624133725.C15E367DC@...>
      > > Jun 24 14:37:25 server1 postfix/qmgr[32379]: C15E367DC: from=<server.admin@...>, size=389, nrcpt=1 (queue active)
      >
      > (Inconsistent munging, or the sender was rewritten from
      > admin-acct@$myorigin to server.admin@....)
      >

      No. This is entirely consistent when using sender_canonical_maps,
      that behaviour is expected.

      > > Jun 24 14:37:25 server1 postfix/error[22953]: C15E367DC: to=<root@...>, orig_to=<root>, relay=none, delay=0.26, delays=0.14/0.06/0/0.06, dsn=5.0.0, status=bounced (User unknown in virtual alias table)
      >
      > Postfix has appended @$myorigin as documented. example.com is in
      > $virtual_alias_domains (as you showed), but root@... either:
      > 1. is not listed in $virtual_alias_maps

      Correct, I moved root (& others) out of $virtual_alias_maps back to
      aliases to test if aliases was being evaluated at all.

      > 2. does not resolve to an address which is NOT in
      > $virtual_alias_domains
      >

      $virtual_alias_domains is essentially $mydomain

      > As mentioned above, since example.com is NOT in $mydestination (and
      > you must not list the same domain in more than one address class
      > definition), $alias_maps are not consulted.
      >
      > > From what I'm still seeing, aliases is not referenced when the
      > > machine's domain name is virtual. Is this significant?
      >
      > Um, yes, that's more or less what I have been saying. :)
      >

      Thanks Rob, & various people proudly promoting postfix.

      Previously, the pair of primary postfix developers posted remarkably
      similar proposed configs, with a virtual $mydomain not listed plainly in
      $mydestination, and both including references to aliases evaluation. But
      that is not my experience - as logs show in my last mail.

      I'll continue reading, experimenting & testing.

      Thanks,
      --
      Craig Skinner | http://twitter.com/Craig_Skinner | http://linkd.in/yGqkv7
    • Craig R. Skinner
      ... Viktor, you deleted/ignored the part where I stated that I d changed it: ... It s clear enough if you read what I wrote. ... That might be what you d like
      Message 37 of 37 , Jun 25, 2013
        On 2013-06-25 Tue 14:38 PM |, Viktor Dukhovni wrote:
        >
        > > Jun 25 14:04:08 server1 postfix/pickup[29023]: 51B8367E0: uid=7432 from=<admin-acct>
        > > Jun 25 14:04:08 server1 postfix/cleanup[154]: 51B8367E0: message-id=<20130625130408.51B8367E0@...>
        > > Jun 25 14:04:08 server1 postfix/qmgr[6613]: 51B8367E0: from=<server.admin@...>, size=389, nrcpt=1 (queue active)
        > > Jun 25 14:04:08 server1 postfix/trivial-rewrite[2958]: warning: do not list domain example.com in BOTH mydestination and virtual_alias_domains
        >
        > This configuration is not what you claim above, stop wasting the list's
        > time with misleading reports.

        Viktor, you deleted/ignored the part where I stated that I'd changed it:

        On 2013-06-25 Tue 14:53 PM |, Craig R. Skinner wrote:
        >
        > However, alias expansion does occur when I do the NAUGHTY thing of
        > including $mydomain in $mydestination.

        It's clear enough if you read what I wrote.

        >
        > > Jun 25 14:04:08 server1 postfix/lmtp[30743]: 51B8367E0: to=<admin-acct@...>, orig_to=<daemon>, relay=server1.example.com[private/dovecot-lmtp], delay=0.07, delays=0.02/0/0.01/0.03, dsn=2.0.0, status=sent (250 2.0.0 <admin-acct@...> wCqpOjmVyVF/agAANm01jw Saved)
        >
        > Were example.com in virtual_alias_domains, this message would have bounced.
        >

        That might be what you'd like to happen. I don't see Postfix acting that way.

        Here in more detail (deliberately including mydomain in mydestination):

        $ postconf \
        config_directory \
        alias_database \
        alias_maps \
        mydomain \
        myorigin \
        mydestination \
        virtual_alias_domains \
        virtual_alias_maps \
        mailbox_transport \
        sender_canonical_maps \
        masquerade_domains \
        remote_header_rewrite_domain \
        local_recipient_maps \
        mail_spool_directory \
        append_dot_mydomain \
        local_transport

        config_directory = /etc/postfix
        alias_database = btree:$config_directory/aliases
        alias_maps = $alias_database
        mydomain = example.com
        myorigin = $mydomain
        mydestination = localhost, localhost.$mydomain, $mydomain
        virtual_alias_domains = example.com
        virtual_alias_maps = btree:$config_directory/virtual_alias_maps.map
        mailbox_transport = lmtp:unix:private/dovecot-lmtp
        sender_canonical_maps = btree:$config_directory/canonical.map
        masquerade_domains = $virtual_alias_domains
        remote_header_rewrite_domain = address.invalid
        local_recipient_maps = proxy:unix:passwd.byname $alias_maps
        mail_spool_directory = /var/mail/
        append_dot_mydomain = yes
        local_transport = local:$myhostname

        $ postmap -q daemon btree:/etc/postfix/aliases
        root

        $ postmap -q root btree:/etc/postfix/aliases
        admin-acct

        $ postmap -q daemon btree:/etc/postfix/virtual_alias_maps.map
        [nothing]

        $ postmap -q root btree:/etc/postfix/virtual_alias_maps.map
        [nothing]

        $ postmap -q server.admin btree:/etc/postfix/virtual_alias_maps.map
        admin-acct@localhost


        $ uname | mail -s uname daemon
        Jun 25 19:39:03 server1 postfix/pickup[23791]: 46C026764: uid=7432 from=<admin-acct>
        Jun 25 19:39:03 server1 postfix/cleanup[4734]: 46C026764: message-id=<20130625183903.46C026764@...>
        Jun 25 19:39:03 server1 postfix/qmgr[7589]: 46C026764: from=<server.admin@...>, size=328, nrcpt=1 (queue active)
        Jun 25 19:39:03 server1 postfix/trivial-rewrite[30793]: warning: do not list domain example.com in BOTH mydestination and virtual_alias_domains
        Jun 25 19:39:03 server1 postfix/trivial-rewrite[30793]: warning: do not list domain example.com in BOTH mydestination and virtual_alias_domains
        Jun 25 19:39:03 server1 postfix/trivial-rewrite[30793]: warning: do not list domain example.com in BOTH mydestination and virtual_alias_domains
        Jun 25 19:39:03 server1 dovecot: lmtp(23729): Connect from local
        Jun 25 19:39:03 server1 dovecot: lmtp(23729, admin-acct): 6epMMMfjyVGxXAAANm01jw: sieve: msgid=<20130625183903.46C026764@...>: stored mail into mailbox 'INBOX'
        Jun 25 19:39:04 server1 postfix/lmtp[19198]: 46C026764: to=<admin-acct@...>, orig_to=<daemon>, relay=server1.example.com[private/dovecot-lmtp], delay=0.78, delays=0.14/0.07/0.39/0.19, dsn=2.0.0, status=sent (250 2.0.0 <admin-acct@...> 6epMMMfjyVGxXAAANm01jw Saved)
        Jun 25 19:39:04 server1 dovecot: lmtp(23729): Disconnect from local: Client quit (in reset)
        Jun 25 19:39:04 server1 postfix/qmgr[7589]: 46C026764: removed


        Log evidence of no bounce when the mydomain is both in mydestination &
        virtual_alias_domains. Also log evidence of aliases being parsed.


        > > Comments?
        >
        > 0. All address -> address mappings in virtual(5).
        >
        > 1. No address-> address mappings in aliases(5).
        >
        > 2. localhost and localhost.$mydomain only in mydestionation.
        >
        > 3. Your domain in virtual_alias_domains and myorigin.
        >
        > 4. In virtual(5) the LHS and RHS of all lookup keys include @domain:
        >
        > alias@... user@..., otheruser@...
        > user@... useracct@localhost
        > otheruser@... otheracct@localhost
        >
        > 5. Nothing in aliases(5) except aliases whose RHS is a ":include:" file
        > if you need that feature (mailing list manager integration).

        This is what I stated worked for me an earlier mail:

        On 2013-06-21 Fri 20:57 PM |, Craig R. Skinner wrote:
        >
        > Thanks Viktor, this set up works with making the machines domain name
        > virtual for Postfix, accepting mail for pretty addresses & rejecting
        > remote mail for MOST Unix accounts, while accepting local mail to Unix
        > accounts, IF listed as virtual aliases (mutt, sendmail, cron,....):
        >
        ..
        ..
        ..
        >
        > It seems the aliases file is not used. I've got root, postmaster,
        > abuse, hostmaster, etc. in virtual_alias_maps.map. Should the other
        > traditional aliases of MAILER-DAEMON, bin, dumper, etc. be in there
        > too?
        >

        On 2013-06-21 Fri 22:08 PM |, Jeroen Geilman wrote:
        > >It seems the aliases file is not used.
        >
        > Of course it is used, for any destinations in $mydestination.
        >

        On 2013-06-24 Mon 15:12 PM |, Craig R. Skinner wrote:
        >
        > Thanks winning team (& Dr. Seuss too) for the quality education.
        >
        > I'm about getting it now.
        >
        > This set up works:-
        >
        ...
        ...
        >
        > aliases:
        > [empty]
        >
        > virtual_alias_maps.map:
        > # example.com: ($myorigin)
        > # Re-mapped from aliases(5): # Are they all needed these days???
        > postmaster postmaster@localhost
        > abuse postmaster@...
        > root admin-acct@localhost
        > MAILER-DAEMON postmaster@...
        > bin root@...
        > daemon root@...
        > named hostmaster@...
        ...
        ...



        However, Wietse replied to a later email with:

        On 2013-06-22 Sat 17:10 PM |, Wietse Venema wrote:
        > I agree with Viktor's description:
        >
        ...
        ...
        >
        > # Legacy sendmail-style aliases:
        > /etc/aliases:
        > # Here, no @domain in LHS or RHS.
        > postmaster: unixaccount
        > abuse: unixaccount
        >

        Therefore I tried moving some 'traditional' aliases back from
        virtual_alias_maps into aliases to test -
        and that's where it all fell apart:-

        The summary I hear from Viktor: is 'put it all in virtual'
        And from Wietse effectively: 'plain aliases will still work'

        I'm confused because both situations do not work, unless
        mydomain is in mydestination, which Postfix complains about.

        I've accurately followed the mixed instructions & tested each.

        >
        > 6. Handle "| command" aliases via .forward files of a designated
        > account, rather than in the system aliases file.
        >
        > 7. Did I mention no address to address (or if you like account to
        > account, address to account, account to address, ...) mappings in
        > aliases(5)? Plase all of these in virtual(5).
        >

        Yes, see above.

        > 8. When testing, stop Postfix, check the configuration is what you want
        > to test and save "postconf -n" output. Start Postfix and run your
        > tests. Then report log entries that postdate the most recent Postfix
        > stop/start.
        >
        > 9. Don't tinker with the configuration mid-test and report logs that
        > don't match the reported configuration.
        >
        > 11. Yes local aliases(5) will still work when useracct@localhost is
        > processed by local(8), but best practice is to avoid user accounts as
        > lookup keys in /etc/aliases.

        OK. I'll forget that as useracct@localhost is rather unlikely.
        Either of these is more common day to day:
        *) useracct (from local processes)
        *) user.acct@... (via smtpd)

        >
        > 12. Local aliases(5) are not consulted when an address is missing
        > from virtual(5). If you send email to "missing@..." with
        > missing@... not listed in virtual(5), then having an entry of
        > the form "missing: user" in aliases(5) will not help. You must
        > include:
        >
        > missing@... missing@localhost
        >
        > for missing to then be looked up in aliases(5), but if
        > missing needs to be sent to a different user, you should
        > use virtual(5) for that! See 1 and 7 above. Basically,
        > in most cases aliases(5) can and should be empty.

        As I had before:

        On 2013-06-24 Mon 15:12 PM |, Craig R. Skinner wrote:
        >
        > aliases:
        > [empty]
        >



        >
        > 13. You can even set:
        >
        > alias_database =
        > alias_maps =
        >
        > and the question of whether aliases(5) lookups works becomes moot.
        > You'll only need aliases(5) for mailing list manager support, with
        > aliases(5) files that belong to the list manager account, so that
        > pipe commands there run under the correct account.
        >

        OK, that's all clear now.

        $ postmap -q daemon btree:/etc/postfix/aliases
        [nothing]
        $ postmap -q root btree:/etc/postfix/aliases
        [nothing]


        $ postmap -q daemon btree:/etc/postfix/virtual_alias_maps.map
        root@...

        $ postmap -q root btree:/etc/postfix/virtual_alias_maps.map
        admin-acct@localhost

        $ postconf \
        config_directory \
        alias_database \
        alias_maps \
        mydomain \
        myorigin \
        mydestination \
        virtual_alias_domains \
        virtual_alias_maps \
        mailbox_transport \
        sender_canonical_maps \
        masquerade_domains \
        remote_header_rewrite_domain \
        local_recipient_maps \
        mail_spool_directory \
        append_dot_mydomain \
        local_transport

        config_directory = /etc/postfix
        alias_database =
        alias_maps =
        mydomain = example.com
        myorigin = $mydomain
        mydestination = localhost, localhost.$mydomain
        virtual_alias_domains = example.com
        virtual_alias_maps = btree:$config_directory/virtual_alias_maps.map
        mailbox_transport = lmtp:unix:private/dovecot-lmtp
        sender_canonical_maps = btree:$config_directory/canonical.map
        masquerade_domains = $virtual_alias_domains
        remote_header_rewrite_domain = address.invalid
        local_recipient_maps = proxy:unix:passwd.byname $alias_maps
        mail_spool_directory = /var/mail/
        append_dot_mydomain = yes
        local_transport = local:$myhostname


        $ uname | mail -s uname daemon
        Jun 25 20:30:49 server1 postfix/pickup[9331]: B347067D2: uid=7432 from=<admin-acct>
        Jun 25 20:30:49 server1 postfix/cleanup[12470]: B347067D2: message-id=<20130625193049.B347067D2@...>
        Jun 25 20:30:49 server1 postfix/qmgr[27612]: B347067D2: from=<server.admin@...>, size=328, nrcpt=1 (queue active)
        Jun 25 20:30:50 server1 dovecot: lmtp(32687): Connect from local
        Jun 25 20:30:50 server1 dovecot: lmtp(32687, admin-acct): hheEDurvyVGvfwAANm01jw: sieve: msgid=<20130625193049.B347067D2@...>: stored mail into mailbox 'INBOX'
        Jun 25 20:30:50 server1 postfix/lmtp[8423]: B347067D2: to=<admin-acct@...>, orig_to=<daemon>, relay=server1.example.com[private/dovecot-lmtp], delay=0.78, delays=0.15/0.06/0.38/0.19, dsn=2.0.0, status=sent (250 2.0.0 <admin-acct@...> hheEDurvyVGvfwAANm01jw Saved)
        Jun 25 20:30:50 server1 dovecot: lmtp(32687): Disconnect from local: Client quit (in reset)
        Jun 25 20:30:50 server1 postfix/qmgr[27612]: B347067D2: removed

        $ uname | mail -s uname server.admin
        Jun 25 20:31:57 server1 postfix/pickup[9331]: 4FDA567D2: uid=7432 from=<admin-acct>
        Jun 25 20:31:57 server1 postfix/cleanup[12470]: 4FDA567D2: message-id=<20130625193157.4FDA567D2@...>
        Jun 25 20:31:57 server1 postfix/qmgr[27612]: 4FDA567D2: from=<server.admin@...>, size=329, nrcpt=1 (queue active)
        Jun 25 20:31:57 server1 dovecot: lmtp(15765): Connect from local
        Jun 25 20:31:57 server1 dovecot: lmtp(15765, admin-acct): qYkuGC3wyVGVPQAANm01jw: sieve: msgid=<20130625193157.4FDA567D2@...>: stored mail into mailbox 'INBOX'
        Jun 25 20:31:57 server1 postfix/lmtp[8423]: 4FDA567D2: to=<admin-acct@...>, orig_to=<server.admin>, relay=server1.example.com[private/dovecot-lmtp], delay=0.22, delays=0.02/0/0.06/0.13, dsn=2.0.0, status=sent (250 2.0.0 <admin-acct@...> qYkuGC3wyVGVPQAANm01jw Saved)
        Jun 25 20:31:57 server1 dovecot: lmtp(15765): Disconnect from local: Client quit (in reset)
        Jun 25 20:31:57 server1 postfix/qmgr[27612]: 4FDA567D2: removed


        $ uname | mail -s uname server.admin@...
        Jun 25 20:33:23 server1 postfix/pickup[9331]: 10DBA67D2: uid=7432 from=<admin-acct>
        Jun 25 20:33:23 server1 postfix/cleanup[12470]: 10DBA67D2: message-id=<20130625193323.10DBA67D2@...>
        Jun 25 20:33:23 server1 postfix/qmgr[27612]: 10DBA67D2: from=<server.admin@...>, size=329, nrcpt=1 (queue active)
        Jun 25 20:33:23 server1 dovecot: lmtp(9968): Connect from local
        Jun 25 20:33:23 server1 dovecot: lmtp(9968, admin-acct): 86tLCYPwyVHwJgAANm01jw: sieve: msgid=<20130625193323.10DBA67D2@...>: stored mail into mailbox 'INBOX'
        Jun 25 20:33:23 server1 postfix/lmtp[8423]: 10DBA67D2: to=<admin-acct@...>, orig_to=<server.admin@...>, relay=server1.example.com[private/dovecot-lmtp], delay=0.23, delays=0.03/0.01/0.07/0.13, dsn=2.0.0, status=sent (250 2.0.0 <admin-acct@...> 86tLCYPwyVHwJgAANm01jw Saved)
        Jun 25 20:33:23 server1 dovecot: lmtp(9968): Disconnect from local: Client quit (in reset)
        Jun 25 20:33:23 server1 postfix/qmgr[27612]: 10DBA67D2: removed

        It doesn't work with local mail to unix accounts, which I want.

        $ uname | mail -s uname admin-acct
        Jun 25 20:34:37 server1 postfix/pickup[9331]: DC92C67D2: uid=7432 from=<admin-acct>
        Jun 25 20:34:37 server1 postfix/cleanup[12470]: DC92C67D2: message-id=<20130625193437.DC92C67D2@...>
        Jun 25 20:34:37 server1 postfix/qmgr[27612]: DC92C67D2: from=<server.admin@...>, size=337, nrcpt=1 (queue active)
        Jun 25 20:34:38 server1 postfix/error[14142]: DC92C67D2: to=<admin-acct@...>, orig_to=<admin-acct>, relay=none, delay=0.17, delays=0.03/0.07/0/0.07, dsn=5.0.0, status=bounced (User unknown in virtual alias table)

        To solve that problem, I can replace
        sender_canonical_maps = btree:$config_directory/canonical.map
        with:
        canonical_maps = btree:$config_directory/canonical.map

        But then (naturally) smtpd also accepts remote mail for
        admin-acct@..., rather than just for server.admin@...

        Which can be controlled with Stan's idea of rejecting specific Unix
        accounts via smtpd_recipient_restrictions check_recipient_access
        reject_system_accounts.map.


        Thanks everyone for all your combined help,
        --
        Craig Skinner | http://twitter.com/Craig_Skinner | http://linkd.in/yGqkv7
      Your message has been successfully submitted and would be delivered to recipients shortly.