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

Virtual aliases pointing to non-existent virtual mailboxes

Expand Messages
  • Axel Luttgens
    Hello, Let s consider following config (presentation based on VIRTUAL_README): /etc/postfix/main.cf : virtual_transport = lmtp:unix:/path/name
    Message 1 of 3 , Jul 3, 2013
      Hello,

      Let's consider following config (presentation based on VIRTUAL_README):

      /etc/postfix/main.cf :
      virtual_transport = lmtp:unix:/path/name
      virtual_mailbox_domains = example.com
      virtual_mailbox_maps = hash:/etc/postfix/vmailbox
      virtual_alias_maps = hash:/etc/postfix/virtual
      /etc/postfix/vmailbox:
      joe@... whatever
      /etc/postfix/virtual:
      postmaster@... joe@...
      abuse@... jooe@...

      When, in a smtp session, I inadvertently type:

      rcpt to:<jooe@...>

      there's an immediate rejection:

      550 5.1.1 <jooe@...>: Recipient address rejected: User unknown in virtual mailbox table

      On the other hand, typing:

      rcpt to:<abuse@...>

      allows to go ahead and the message will be queued, then bounced because the LMTP service ultimately rejects the target address <jooe@...>.

      So, a typo in both cases, but with two very different outcomes.

      Does this reflect what is meant by:

      An address is always considered "known" when it matches a virtual(5)
      alias or a canonical(5) mapping.

      under the entry for smtpd_reject_unlisted_recipient in POSTCONF(5)?

      Is there any way (beside taking care not to mistype) to avoid the message enqueuing in the second case?

      TIA,
      Axel
    • Wietse Venema
      ... Yes. Note that the resulting address may be remote, or it may resolve to a local alias that expands into a non-existent address. If you want immediate
      Message 2 of 3 , Jul 3, 2013
        Axel Luttgens:
        > 550 5.1.1 <jooe@...>: Recipient address rejected: User unknown in virtual mailbox table
        >
        > On the other hand, typing:
        >
        > rcpt to:<abuse@...>
        >
        > allows to go ahead and the message will be queued, then bounced
        > because the LMTP service ultimately rejects the target address
        > <jooe@...>.
        >
        > So, a typo in both cases, but with two very different outcomes.
        >
        > Does this reflect what is meant by:
        >
        > An address is always considered "known" when it matches a
        > virtual(5) alias or a canonical(5) mapping.

        Yes. Note that the resulting address may be remote, or it may resolve
        to a local alias that expands into a non-existent address.

        If you want immediate verification, use reject_unverified_recipient.
        This does a lot of work behind the scenes and then caches the result.
        http://www.postfix.org/ADDRESS_VERIFICATION_README.html#recipient

        Having Postfix do full address resolution for every RCPT TO command
        would make Postfix more vulnerable to denial-of-service attacks,
        because sending RCPT TO is much cheaper than recursively resolving
        multiple levels of address rewriting or aliasing that happens in a
        bunch of different processes from cleanup(8), trivial-rewrite(8),
        to local(8), virtual(8), lmtp(8) and so on.

        Wietse
      • Axel Luttgens
        ... Hello Wietse, You must have been reading my mind... I was indeed trying (agreed, a bit confusingly) to check whether I could have overlooked some
        Message 3 of 3 , Jul 3, 2013
          Le 3 juil. 2013 à 16:23, Wietse Venema a écrit :

          > [...]
          >
          > If you want immediate verification, use reject_unverified_recipient.
          > This does a lot of work behind the scenes and then caches the result.
          > http://www.postfix.org/ADDRESS_VERIFICATION_README.html#recipient
          >
          > Having Postfix do full address resolution for every RCPT TO command
          > would make Postfix more vulnerable to denial-of-service attacks,
          > because sending RCPT TO is much cheaper than recursively resolving
          > multiple levels of address rewriting or aliasing that happens in a
          > bunch of different processes from cleanup(8), trivial-rewrite(8),
          > to local(8), virtual(8), lmtp(8) and so on.

          Hello Wietse,

          You must have been reading my mind...

          I was indeed trying (agreed, a bit confusingly) to check whether I could have overlooked some intermediate between the quick smtpd_reject_unlisted_recipient and the heavyweight reject_unverified_recipient.

          Many thanks for your thorough reply,
          Axel
        Your message has been successfully submitted and would be delivered to recipients shortly.