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

SASL auth and (local) relaying through telnet

Expand Messages
  • Titanus Eramius
    I m not entirely sure how to formulate this question best in English, so please bear over with me. In the past 6 months I ve set up several Postfix 2.7.1
    Message 1 of 7 , Dec 6, 2012
    • 0 Attachment
      I'm not entirely sure how to formulate this question best in English,
      so please bear over with me.

      In the past 6 months I've set up several Postfix 2.7.1 servers, which
      uses Dovecot as LDA and as SASL auth. One of them runs this domain, but
      they are still in testing.

      My highest concern is to setup an open relay by accident, so in the
      process I've used an online anti-spam tester several times:
      http://www.antispam-ufrj.pads.ufrj.br/test-relay.html

      It has always (and still does) reported the servers to reject
      relaying.

      I therefore thought it was only possible to relay mail through the
      servers if a valid username (an active email-address) and a password
      were given to the server (unless it's a systemuser logged in through
      ssh). That is how I would like the servers to behave.

      However, trying to learn a little I played around with telnet from my
      computer today, and was able to relay mail through the servers from the
      internet, without having to log in.

      It appears though, that it's only possible to relay mail if the server
      holds the address in the database, which suggest that the servers only
      are open to some limited backscatter, since the recipient address has
      to be known and given to Postfix. Some testing seems to support this.

      Even so, I would like Postfix to deny relaying in this case also, if at
      all possible.

      A telnet session goes like this, on either the server containing
      my_address or the backup MX:

      $ telnet X.X.X.X 25
      Trying X.X.X.X...
      Connected to X.X.X.X.
      Escape character is '^]'.
      220 machinename.domain.tld ESMTP Postfix
      EHLO fake-name.domain.tld
      250-machinename.domain.tld
      250-PIPELINING
      250-SIZE 10240000
      250-ETRN
      250-STARTTLS
      250-AUTH PLAIN LOGIN
      250-AUTH=PLAIN LOGIN
      250-ENHANCEDSTATUSCODES
      250-8BITMIME
      250 DSN
      $ MAIL FROM:spam@...
      250 2.1.0 Ok
      $ RCPT TO:my_address@my_domain.tld
      250 2.1.5 Ok
      DATA
      354 End data with <CR><LF>.<CR><LF>
      Test something
      .
      250 2.0.0 Ok: queued as 3653E371BAA1
      quit
      221 2.0.0 Bye
      Connection closed by foreign host.

      Then grep'ing the query ID from the log gives 5 lines:

      Dec 6 23:30:40 machinename postfix/smtpd[3184]: 3653E371BAA1:
      client=unknown[my wan-IP]

      Dec 6 23:30:51 machinename postfix/cleanup[3557]: 3653E371BAA1:
      message-id=<>

      Dec 6 23:30:51 machinename postfix/qmgr[4628]: 3653E371BAA1:
      from=<SRS0=nFZn=KA=dont-exists.tld=spam@my_domin.tld>, size=379,
      nrcpt=1 (queue active)

      Dec 6 23:30:51 machinename postfix/pipe[3577]: 3653E371BAA1:
      to=<my_address@my_domain.tld>, relay=dovecot, delay=56,
      delays=56/0/0/0, dsn=2.0.0, status=sent (delivered via dovecot service)

      Dec 6 23:30:51 machinename postfix/qmgr[4628]: 3653E371BAA1: removed


      And the mail is indeed delivered. In master.cf the submission-part
      looks like this:


      submission inet n - - - - smtpd
      -o smtpd_tls_security_level=encrypt
      -o smtpd_sasl_auth_enable=yes
      -o smtpd_sasl_type=dovecot
      -o smtpd_sasl_path=private/auth
      -o smtpd_sasl_security_options=noanonymous
      -o smtpd_sasl_local_domain=$myhostname
      -o smtpd_client_restrictions=
      permit_sasl_authenticated
      reject
      -o
      smtpd_sender_login_maps=proxy:mysql:/etc/postfix/mysql_sender_login_maps.cf
      -o smtpd_sender_restrictions=reject_sender_login_mismatch
      -o smtpd_recipient_restrictions=
      reject_non_fqdn_recipient
      reject_unknown_recipient_domain
      permit_sasl_authenticated
      reject


      And postconf -n on the server my_address gives:


      alias_maps = hash:/etc/aliases

      bounce_template_file = /etc/postfix/bounce.cf

      broken_sasl_auth_clients = yes

      config_directory = /etc/postfix

      delay_warning_time = 4

      disable_vrfy_command = yes

      inet_interfaces = all

      maximal_queue_lifetime = 15

      myhostname = machinename.my_domain.tld

      mynetworks = 127.0.0.0/8

      recipient_canonical_classes = envelope_recipient

      recipient_canonical_maps = hash:/etc/postfix/pfix-no-srs.cf,
      tcp:127.0.0.1:10002

      sender_canonical_classes = envelope_sender

      sender_canonical_maps = hash:/etc/postfix/pfix-no-srs.cf,
      tcp:127.0.0.1:10001

      smtp_tls_security_level = may

      smtp_tls_session_cache_database =
      btree:$data_directory/smtp_tls_session_cache

      smtpd_data_restrictions =
      reject_unauth_pipelining
      reject_multi_recipient_bounce
      permit

      smtpd_helo_required = yes

      smtpd_recipient_restrictions = permit_mynetworks
      permit_sasl_authenticated
      reject_unauth_destination
      warn_if_reject reject_invalid_helo_hostname
      warn_if_reject reject_non_fqdn_helo_hostname
      warn_if_reject reject_non_fqdn_sender
      warn_if_reject reject_non_fqdn_recipient
      warn_if_reject reject_unknown_sender_domain
      warn_if_reject reject_unknown_recipient_domain
      warn_if_reject reject_rbl_client truncate.gbudb.net
      check_policy_service unix:private/spfcheck
      permit

      smtpd_sasl_auth_enable = yes

      smtpd_sasl_exceptions_networks = $mynetworks

      smtpd_sasl_path = private/auth

      smtpd_sasl_security_options = noanonymous

      smtpd_sasl_type = dovecot

      smtpd_tls_ask_ccert = yes

      smtpd_tls_cert_file = /etc/ssl/self-signed/smtpd.crt

      smtpd_tls_key_file = /etc/ssl/self-signed/smtpd.key

      smtpd_tls_loglevel = 1

      smtpd_tls_received_header = yes

      smtpd_tls_security_level = may

      smtpd_tls_session_cache_database =
      btree:$data_directory/smtpd_tls_session_cache

      tls_random_source = dev:/dev/urandom

      transport_maps = hash:/etc/postfix/transport.cf

      virtual_alias_maps =
      proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf

      virtual_gid_maps = static:5000

      virtual_mailbox_base = /home/vmail

      virtual_mailbox_domains =
      proxy:mysql:/etc/postfix/mysql_virtual_domains_maps.cf

      virtual_mailbox_maps =
      proxy:mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf

      virtual_minimum_uid = 5000

      virtual_transport = dovecot

      virtual_uid_maps = static:5000

      Any pointers / help will be greatly appreciated and thanks for reading.
      Cheers, Titanus
    • Wietse Venema
      ... Most Postfix configurations use permit_mynetworks which by default allows relaying from local networks. Wietse
      Message 2 of 7 , Dec 6, 2012
      • 0 Attachment
        Titanus Eramius:
        > However, trying to learn a little I played around with telnet from my
        > computer today, and was able to relay mail through the servers from the
        > internet, without having to log in.

        Most Postfix configurations use "permit_mynetworks" which
        by default allows relaying from local networks.

        Wietse
      • /dev/rob0
        ... That need not be your highest concern. ... What about when your server is the final destination? ... See reject_unknown_sender_domain if you want to reject
        Message 3 of 7 , Dec 6, 2012
        • 0 Attachment
          On Fri, Dec 07, 2012 at 01:23:21AM +0100, Titanus Eramius wrote:
          > My highest concern is to setup an open relay by accident, so
          > in the process I've used an online anti-spam tester several
          > times: http://www.antispam-ufrj.pads.ufrj.br/test-relay.html

          That need not be your highest concern.

          > It has always (and still does) reported the servers to reject
          > relaying.
          >
          > I therefore thought it was only possible to relay mail through the
          > servers if a valid username (an active email-address) and a password
          > were given to the server (unless it's a systemuser logged in through
          > ssh). That is how I would like the servers to behave.

          What about when your server is the final destination?

          > However, trying to learn a little I played around with telnet from
          > my computer today, and was able to relay mail through the servers
          > from the internet, without having to log in.
          >
          > It appears though, that it's only possible to relay mail if the
          > server holds the address in the database, which suggest that the
          > servers only are open to some limited backscatter, since the
          > recipient address has to be known and given to Postfix. Some
          > testing seems to support this.
          >
          > Even so, I would like Postfix to deny relaying in this case also,
          > if at all possible.
          >
          > A telnet session goes like this, on either the server containing
          > my_address or the backup MX:
          >
          > $ telnet X.X.X.X 25
          > Trying X.X.X.X...
          > Connected to X.X.X.X.
          > Escape character is '^]'.
          > 220 machinename.domain.tld ESMTP Postfix
          > EHLO fake-name.domain.tld
          > 250-machinename.domain.tld
          > 250-PIPELINING
          > 250-SIZE 10240000
          > 250-ETRN
          > 250-STARTTLS
          > 250-AUTH PLAIN LOGIN
          > 250-AUTH=PLAIN LOGIN
          > 250-ENHANCEDSTATUSCODES
          > 250-8BITMIME
          > 250 DSN
          > $ MAIL FROM:spam@...

          See reject_unknown_sender_domain if you want to reject mail from
          senders in nonexisting domains (a good idea.)

          > 250 2.1.0 Ok
          > $ RCPT TO:my_address@my_domain.tld

          Your munging makes it hard to say for sure, but I'm going to go out
          on a limb and venture a guess that you host "my_domain.tld" on this
          Postfix.

          That's not what "relaying" means. That's "accepting for delivery."
          "Relaying" means taking mail for some OTHER site and sending it on
          for the client.

          What exactly are you trying to prevent here?

          > 250 2.1.5 Ok
          > DATA
          > 354 End data with <CR><LF>.<CR><LF>
          > Test something
          > .
          > 250 2.0.0 Ok: queued as 3653E371BAA1
          > quit
          > 221 2.0.0 Bye
          > Connection closed by foreign host.
          >
          > Then grep'ing the query ID from the log gives 5 lines:
          >
          > Dec 6 23:30:40 machinename postfix/smtpd[3184]: 3653E371BAA1:
          > client=unknown[my wan-IP]
          > Dec 6 23:30:51 machinename postfix/cleanup[3557]: 3653E371BAA1:
          > message-id=<>
          > Dec 6 23:30:51 machinename postfix/qmgr[4628]: 3653E371BAA1:
          > from=<SRS0=nFZn=KA=dont-exists.tld=spam@my_domin.tld>, size=379,

          That's a different sender than you showed. If you're going to mung,
          do be consistent!

          > nrcpt=1 (queue active)
          > Dec 6 23:30:51 machinename postfix/pipe[3577]: 3653E371BAA1:
          > to=<my_address@my_domain.tld>, relay=dovecot, delay=56,
          > delays=56/0/0/0, dsn=2.0.0, status=sent (delivered via dovecot
          > service)

          See, you accepted this for final delivery. You did not relay.

          > Dec 6 23:30:51 machinename postfix/qmgr[4628]: 3653E371BAA1:
          > removed
          >
          >
          > And the mail is indeed delivered. In master.cf the
          > submission-part looks like this:

          So? Your telnet was to port 25.
          --
          http://rob0.nodns4.us/ -- system administration and consulting
          Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
        • Noel Jones
          ... *** Sending TO YOUR OWN DOMAIN is NOT relaying *** This is /exactly/ the same process any MTA, or mail client, or spam bot will use to send mail to you.
          Message 4 of 7 , Dec 6, 2012
          • 0 Attachment
            On 12/6/2012 6:23 PM, Titanus Eramius wrote:
            > My highest concern is to setup an open relay by accident, so in the

            ...

            > A telnet session goes like this, on either the server containing
            > my_address or the backup MX:
            >
            > $ telnet X.X.X.X 25
            ...
            > $ MAIL FROM:spam@...
            > 250 2.1.0 Ok
            > $ RCPT TO:my_address@my_domain.tld

            *** Sending TO YOUR OWN DOMAIN is NOT relaying ***

            This is /exactly/ the same process any MTA, or mail client, or spam
            bot will use to send mail to you. Nothing special about telnet; you
            could have used a command-line SMTP such as mini_sendmail, or spent
            a few minutes setting up Thunderbird for testing. Nothing of
            interest here.



            -- Noel Jones
          • Titanus Eramius
            On Thu, 6 Dec 2012 20:32:17 -0600 ... Thanks for the reply. I am not sure I follow here, could you please elaborate a bit? ... Yes, sorry about the munging and
            Message 5 of 7 , Dec 7, 2012
            • 0 Attachment
              On Thu, 6 Dec 2012 20:32:17 -0600
              /dev/rob0 <rob0@...> wrote:

              > On Fri, Dec 07, 2012 at 01:23:21AM +0100, Titanus Eramius wrote:
              > > My highest concern is to setup an open relay by accident, so
              > > in the process I've used an online anti-spam tester several
              > > times: http://www.antispam-ufrj.pads.ufrj.br/test-relay.html
              >
              > That need not be your highest concern.

              Thanks for the reply. I am not sure I follow here, could you please
              elaborate a bit?

              ...
              > Your munging makes it hard to say for sure, but I'm going to go out
              > on a limb and venture a guess that you host "my_domain.tld" on this
              > Postfix.
              >
              > That's not what "relaying" means. That's "accepting for delivery."
              > "Relaying" means taking mail for some OTHER site and sending it on
              > for the client.
              >
              > What exactly are you trying to prevent here?
              ...
              > So? Your telnet was to port 25.

              Yes, sorry about the munging and the inconsistency, I'm not sure why I
              did that. I see your point about submission and port 25, and I
              guess I still have some learning to do. Thanks for the pointer.

              In that light I realize my question is wrong, and I hope instead the
              following example might help to show what I mean.

              The example is without munging, and Postfix accepts a mail
              through telnet, and locally hands it over to Dovecot, which in turn
              delivers the mail.

              The delivery address exists on the server, and if it doesn't, then
              Postfix says "Recipient address rejected: User unknown in virtual
              mailbox table" just as it says "Relay access denied" if I try to relay
              mail through Postfix.

              $ dig nt-data.dk mx
              ;; ANSWER SECTION:
              nt-data.dk. 5860 IN MX 10 mx01.nt-data.dk.
              ...

              mx01.nt-data.dk. 5860 IN A 94.247.168.138
              ...

              titanus@asrock:~$ telnet 94.247.168.138 25
              Trying 94.247.168.138...
              Connected to 94.247.168.138.
              Escape character is '^]'.
              220 ntdata.nt-data.dk ESMTP Postfix
              EHLO fake
              250-ntdata.nt-data.dk
              250-PIPELINING
              250-SIZE 10240000
              250-ETRN
              250-STARTTLS
              250-AUTH PLAIN LOGIN
              250-AUTH=PLAIN LOGIN
              250-ENHANCEDSTATUSCODES
              250-8BITMIME
              250 DSN
              MAIL FROM:spam@...
              250 2.1.0 Ok
              RCPT TO:main@...
              250 2.1.5 Ok
              DATA
              354 End data with <CR><LF>.<CR><LF>
              content here
              .
              250 2.0.0 Ok: queued as EDB151746A80
              quit
              221 2.0.0 Bye
              Connection closed by foreign host.

              The maillog on the server looks like this:

              titanus@ntdata:~$ sudo cat /var/log/mail.log | grep "EDB151746A80"

              Dec 7 17:51:38 ntdata postfix/smtpd[26112]: EDB151746A80:
              client=unknown[92.243.255.38]

              Dec 7 17:51:51 ntdata postfix/cleanup[26118]: EDB151746A80:
              message-id=<>

              Dec 7 17:51:51 ntdata postfix/qmgr[3981]: EDB151746A80:
              from=<SRS0=QfAL=KB=veryfakeaddress548562.tld=spam@...>,
              size=396, nrcpt=1 (queue active)

              Dec 7 17:51:51 ntdata postfix/pipe[26119]: EDB151746A80:
              to=<main@...>, relay=dovecot, delay=36, delays=36/0.01/0/0.17,
              dsn=2.0.0, status=sent (delivered via dovecot service)

              Dec 7 17:51:51 ntdata postfix/qmgr[3981]: EDB151746A80: removed


              If at all possible, I would like the system not to accept the mail.

              Cheers
            • mouss
              ... mew :) you like cats too? or is it the pipe that you like? $ sudo grep .... /var/log/mail.log saves a few keystorkes .... keep
              Message 6 of 7 , Dec 9, 2012
              • 0 Attachment
                Le 07/12/2012 18:22, Titanus Eramius a écrit :
                > [snip]
                > titanus@asrock:~$ telnet 94.247.168.138 25
                > Trying 94.247.168.138...
                > Connected to 94.247.168.138.
                > Escape character is '^]'.
                > 220 ntdata.nt-data.dk ESMTP Postfix
                > EHLO fake
                > 250-ntdata.nt-data.dk
                > 250-PIPELINING
                > 250-SIZE 10240000
                > 250-ETRN
                > 250-STARTTLS
                > 250-AUTH PLAIN LOGIN
                > 250-AUTH=PLAIN LOGIN
                > 250-ENHANCEDSTATUSCODES
                > 250-8BITMIME
                > 250 DSN
                > MAIL FROM:spam@...
                > 250 2.1.0 Ok
                > RCPT TO:main@...
                > 250 2.1.5 Ok
                > DATA
                > 354 End data with <CR><LF>.<CR><LF>
                > content here
                > .
                > 250 2.0.0 Ok: queued as EDB151746A80
                > quit
                > 221 2.0.0 Bye
                > Connection closed by foreign host.
                >
                > The maillog on the server looks like this:
                >
                > titanus@ntdata:~$ sudo cat /var/log/mail.log | grep "EDB151746A80"

                <humour>
                mew :) you like cats too? or is it the pipe that you like?

                $ sudo grep "...." /var/log/mail.log

                saves a few keystorkes ....
                </humour>

                keep reading. answer below.

                >
                > Dec 7 17:51:38 ntdata postfix/smtpd[26112]: EDB151746A80:
                > client=unknown[92.243.255.38]
                >
                > Dec 7 17:51:51 ntdata postfix/cleanup[26118]: EDB151746A80:
                > message-id=<>
                >
                > Dec 7 17:51:51 ntdata postfix/qmgr[3981]: EDB151746A80:
                > from=<SRS0=QfAL=KB=veryfakeaddress548562.tld=spam@...>,
                > size=396, nrcpt=1 (queue active)
                >
                > Dec 7 17:51:51 ntdata postfix/pipe[26119]: EDB151746A80:
                > to=<main@...>, relay=dovecot, delay=36, delays=36/0.01/0/0.17,
                > dsn=2.0.0, status=sent (delivered via dovecot service)
                >
                > Dec 7 17:51:51 ntdata postfix/qmgr[3981]: EDB151746A80: removed
                >
                >
                > If at all possible, I would like the system not to accept the mail.
                >

                why not? because you sent it using the telnet client program? there is
                no fundamental difference between mail sent using a "standard" MUA
                (thunderbird, outlook, ...) or a program such as telnet, netcat, ... or
                a script using perl, python, php, ...

                and no, spammers do not use the telnet program. that would be too slow!
                they (generally) use spam bots, which can send masse mails in a short
                time. trying to detect such bots is teh subject of anti-spam measures
                such as postcreen, greylisting, spam filters (that look for specific
                headers or other).
              • Titanus Eramius
                On Sun, 09 Dec 2012 16:37:12 +0100 ... For some odd reason I kindda do. Maybe it s the concept of a data-pipe itself, but I imagine I from now on is to lacy to
                Message 7 of 7 , Dec 13, 2012
                • 0 Attachment
                  On Sun, 09 Dec 2012 16:37:12 +0100
                  mouss <mouss@...> wrote:

                  > <humour>
                  > mew :) you like cats too? or is it the pipe that you like?
                  >
                  > $ sudo grep "...." /var/log/mail.log
                  >
                  > saves a few keystorkes ....

                  For some odd reason I kindda do. Maybe it's the concept of a data-pipe
                  itself, but I imagine I from now on is to lacy to use it together
                  with grep :)

                  > </humour>

                  > > If at all possible, I would like the system not to accept the mail.
                  > >
                  >
                  > why not? because you sent it using the telnet client program? there is
                  > no fundamental difference between mail sent using a "standard" MUA
                  > (thunderbird, outlook, ...) or a program such as telnet, netcat, ...
                  > or a script using perl, python, php, ...
                  >
                  > and no, spammers do not use the telnet program. that would be too
                  > slow! they (generally) use spam bots, which can send masse mails in a
                  > short time. trying to detect such bots is teh subject of anti-spam
                  > measures such as postcreen, greylisting, spam filters (that look for
                  > specific headers or other).

                  I see.
                  It makes plenty of sense, and yes, off course this could be scriptet as
                  well, I just thought the example with telnet was easy to illustrate.

                  It might just be me and my wicked way of thinking that made me ask this
                  question, but I'm glad I did even though the premises was wrong, since
                  I leaned some new things.

                  Thanks for all the replies.

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