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

clarification about missing LMTP_README file

Expand Messages
  • mailing list subscriber
    Ok, this¹ has been raised over a few times in the past, but I m not satisfied with the answer (referral to man page of lmtp/smtp instead of idiot-proof
    Message 1 of 4 , Jul 22, 2012
    • 0 Attachment
      Ok, this¹ has been raised over a few times in the past, but I'm not
      satisfied with the answer (referral to man page of lmtp/smtp instead
      of idiot-proof narrative version like other *_README howtos).
      1. Do the cached file contents still apply to current release version
      of postfix?
      2. If yes, why is it retired/not present as
      http://www.postfix.org/LMTP_README.html?
      3. If not, why isn't there the updated version?

      Cheers
      ___
      ¹ http://nixforums.org/about29845-lmtp_readme.html
      http://marc.info/?l=postfix-users&m=110442875921891

      ² https://www.google.com/search?q=lmtp_readme
    • /dev/rob0
      On Sun, Jul 22, 2012 at 11:01:20AM +0300, mailing list subscriber ... As Victor pointed out in the referenced thread, the most similar document presently
      Message 2 of 4 , Jul 22, 2012
      • 0 Attachment
        On Sun, Jul 22, 2012 at 11:01:20AM +0300, mailing list subscriber
        wrote:
        > Ok, this¹ has been raised over a few times in the past, but I'm
        > not satisfied with the answer (referral to man page of lmtp/smtp
        > instead of idiot-proof narrative version like other *_README
        > howtos).
        > 1. Do the cached file contents still apply to current release
        > version of postfix?
        > 2. If yes, why is it retired/not present as
        > http://www.postfix.org/LMTP_README.html?
        > 3. If not, why isn't there the updated version?
        >
        > Cheers
        > ___
        > ¹ http://nixforums.org/about29845-lmtp_readme.html
        > http://marc.info/?l=postfix-users&m=110442875921891
        >
        > ² https://www.google.com/search?q=lmtp_readme

        As Victor pointed out in the referenced thread, the most similar
        document presently supported would be MAILDROP_README. Frankly I'm
        not sure that MAILDROP_README is appropriate in Postfix
        documentation.[1] Dovecot's "deliver" LDA is probably more widely
        used now.

        I didn't carefully pick over the retired LMTP_README, but I did see
        mention of virtual_maps therein, which gives a clue as to its
        vintage, pre-Postfix 2.0.

        The big difference between LMTP and Courier Maildrop (or Dovecot LDA)
        delivery is that LMTP is a network process, more like
        ADDRESS_CLASS_README.html#relay_domain_class , whereas maildrop &
        deliver are commands invoked for receipt of mail.

        The way I would implement LMTP (which I have not yet done, but I am
        sure I'll do eventually, for a customer if not for my own site) is as
        a relay domain, with that domain listed in transport_maps:

        sqlite = sqlite:$config_directory/query
        relay_domains = $sqlite/relay_dom.query
        transport_maps = $sqlite/transport.query

        $ postmap -q example.net sqlite:/etc/postfix/query/relay_dom.query
        example.net
        $ postmap -q example.net sqlite:/etc/postfix/query/transport.query
        lmtp:example.net.rob0
        $ dig +short mx example.net.rob0
        0 localhost.

        And my LMTP listener on localhost would be configured to accept and
        deliver mail for example.net addresses. That part would be out of
        scope for Postfix, depending on the LMTP/imapd implementation.

        Bottom line: I think LMTP is covered well enough in README documents
        as is. If I was to suggest a new README it would be called
        TRANSPORT_README, and it would cover the concept of transport(5) in
        Postfix. The transport(5) manual is good, but it could be augmented
        with some high-level examples and illustrations of the various knobs
        available, e.g. transport_* postconf(5) settings. My idea of a
        TRANSPORT_README would show transports being used for delivery of
        your own mail as well as their use for external sending.

        If I had time I would start on a rough draft thereof. :) Lucky for
        me, I've had some work lately. (Maybe in the fall I can get to it.)

        For the OP, whom I guess is considering LMTP delivery, I would
        suggest concentrating on understanding address classes and the
        transport(5) manual.



        [1] That said, I would hate to see MAILDROP_README go, because it
        credits our late friend and list participant, Tonni Earnshaw. :)
        --
        http://rob0.nodns4.us/ -- system administration and consulting
        Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
      • Wietse Venema
        ... As documented the LMTP and SMTP client are part of the same program. The clients have identical behavior unless documented otherwise or required by
        Message 3 of 4 , Jul 22, 2012
        • 0 Attachment
          mailing list subscriber:
          > Ok, this? has been raised over a few times in the past, but I'm not
          > satisfied with the answer (referral to man page of lmtp/smtp instead
          > of idiot-proof narrative version like other *_README howtos).

          As documented the LMTP and SMTP client are part of the same program.
          The clients have identical behavior unless documented otherwise or
          required by Internet RFCs.

          This change was made 20051208, more than seven years ago.

          Wietse

          SMTP(8) SMTP(8)

          NAME
          smtp - Postfix SMTP+LMTP client
          ...
          DESCRIPTION
          The Postfix SMTP+LMTP client implements the SMTP and LMTP mail delivery
          protocols. It processes message delivery requests from the queue man-
          ager.
          ...
          CONFIGURATION PARAMETERS
          Before Postfix version 2.3, the LMTP client is a separate program that
          implements only a subset of the functionality available with SMTP:
          there is no support for TLS, and connections are cached in-process,
          making it ineffective when the client is used for multiple domains.

          Most smtp_xxx configuration parameters have an lmtp_xxx "mirror" param-
          eter for the equivalent LMTP feature. This document describes only
          those LMTP-related parameters that aren't simply "mirror" parameters.
        • Wietse Venema
          ... This is not relaying, instead this is final delivery. I would therefore suggest a final delivery address class. The virtual_mailbox class would be most
          Message 4 of 4 , Jul 22, 2012
          • 0 Attachment
            /dev/rob0:
            > The way I would implement LMTP (which I have not yet done, but I am
            > sure I'll do eventually, for a customer if not for my own site) is as
            > a relay domain, with that domain listed in transport_maps:

            This is not relaying, instead this is final delivery. I would
            therefore suggest a final delivery address class. The virtual_mailbox
            class would be most natural for this.

            /etc/postfix/main.cf:
            virtual_mailbox_domains = the list domains
            virtual_transport = the lmtp transport
            virtual_mailbox_maps = the list of users

            You aren't using the Postfix virtual(8) delivery agent. Therefore
            Postfix uses virtual_mailbox_maps only to look up the recipient,
            and it doesn't matter what the lookup result looks like. That makes
            virtual_mailbox_maps remarkably similar to relay_recipient_maps.

            transport_maps are not needed for this (they would be needed for
            destinations that require local(8) or pipe(8) features).

            I think that virtual_mailbox_maps needs to be documented better,
            for use cases like the one shown above.

            Wietse
          Your message has been successfully submitted and would be delivered to recipients shortly.