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

Regarding "reject_authenticated_sender_login_mismatch" domain matching

Expand Messages
  • Vytenis Sabaliauskas
    Hello everybody, I m struggling to stop abusing SASL usernames. My idea is to allow any particular SASL username send only from his domain, that is
    Message 1 of 7 , Jun 18, 2014
      Hello everybody,

      I'm struggling to stop abusing SASL usernames. My idea is to allow any particular SASL username send only from his domain, that is "user@..." can send from "anything@...", but not from "user@...".

      I know it should be done with "reject_authenticated_sender_login_mismatch" and "smtpd_sender_login_maps", but what kind of PCRE rules should I write? Or PCRE is not a good option to achieve this?

      Tried these:

      /.*(@.*)/ ${1}

      they return only the domain part, but sending fails with error:

      "Sender address rejected: not owned by user"

      Thanks in advance!
    • D'Arcy J.M. Cain
      On Thu, 19 Jun 2014 08:17:49 +0300 ... I don t know how to do that but I wonder why you want to. The whole point of authentication is to allow your users to
      Message 2 of 7 , Jun 19, 2014
        On Thu, 19 Jun 2014 08:17:49 +0300
        Vytenis Sabaliauskas <vytenis.sabaliauskas@...> wrote:
        > I'm struggling to stop abusing SASL usernames. My idea is to allow any
        > particular SASL username send only from his domain, that is "
        > user@..." can send from "anything@...", but not from "
        > user@...".

        I don't know how to do that but I wonder why you want to. The whole
        point of authentication is to allow your users to get email without
        having to trust the system they are coming in from. If you trust the
        domain then just add it to mynetworks and don't bother with
        authentication. I suggest authentication though so that your users can
        get their email no matter where they are. People are mobile.

        --
        D'Arcy J.M. Cain
        System Administrator, Vex.Net
        http://www.Vex.Net/ IM:darcy@...
        VoIP: sip:darcy@...
      • Wietse Venema
        Vytenis Sabaliauskas: [ Charset UTF-8 unsupported, converting... ] ... The documentation describes exactly what queries Postfix will make (see 1..3 below) and
        Message 3 of 7 , Jun 19, 2014
          Vytenis Sabaliauskas:
          [ Charset UTF-8 unsupported, converting... ]
          > Hello everybody,
          >
          > I'm struggling to stop abusing SASL usernames. My idea is to allow any
          > particular SASL username send only from his domain, that is "
          > user@..." can send from "anything@...", but not from "
          > user@...".
          >
          > I know it should be done with "reject_authenticated_sender_login_mismatch"
          > and "smtpd_sender_login_maps", but what kind of PCRE rules should I write?
          > Or PCRE is not a good option to achieve this?

          The documentation describes exactly what queries Postfix will make
          (see 1..3 below) and what the result of the queries must be (see
          last paragraph).

          The documentation describes DB, DBM, NIS, LDAP or SQL queries. By
          using PCRE you just add unnecessary complexity.

          Wietse

          smtpd_sender_login_maps (default: empty)
          Optional lookup table with the SASL login names that own sender (MAIL
          FROM) addresses.

          Specify zero or more "type:name" lookup tables, separated by whitespace
          of comma. Tables will be searched in the specified order until a match
          is found. With lookups from indexed files such as DB or DBM, or from
          networked tables such as NIS, LDAP or SQL, the following search opera-
          tions are done with a sender address of user@domain:

          1) user@domain
          This table lookup is always done and has the highest precedence.

          2) user
          This table lookup is done only when the domain part of the
          sender address matches $myorigin, $mydestination, $inet_inter-
          faces or $proxy_interfaces.

          3) @domain
          This table lookup is done last and has the lowest precedence.

          In all cases the result of table lookup must be either "not found" or a
          list of SASL login names separated by comma and/or whitespace.
        • Larry Stone
          ... Whoa, whoa, whoa. The original poster was asking about sending email. You re talking about getting email which is the role of an IMAP or POP server such as
          Message 4 of 7 , Jun 19, 2014
            On Thu, 19 Jun 2014, D'Arcy J.M. Cain wrote:

            > On Thu, 19 Jun 2014 08:17:49 +0300
            > Vytenis Sabaliauskas <vytenis.sabaliauskas@...> wrote:
            >> I'm struggling to stop abusing SASL usernames. My idea is to allow any
            >> particular SASL username send only from his domain, that is "
            >> user@..." can send from "anything@...", but not from "
            >> user@...".
            >
            > I don't know how to do that but I wonder why you want to. The whole
            > point of authentication is to allow your users to get email without
            > having to trust the system they are coming in from. If you trust the
            > domain then just add it to mynetworks and don't bother with
            > authentication. I suggest authentication though so that your users can
            > get their email no matter where they are. People are mobile.

            Whoa, whoa, whoa. The original poster was asking about sending email.
            You're talking about getting email which is the role of an IMAP or POP
            server such as Dovecot, not Postfix. Besides that, mynetworks defines
            trusted IP addresses, not domains.

            -- Larry Stone
            lstone19@...
          • D'Arcy J.M. Cain
            On Thu, 19 Jun 2014 09:23:45 -0500 (CDT) ... My mistake but get to send and that s what I meant to say. Authenticating before sending is the best
            Message 5 of 7 , Jun 19, 2014
              On Thu, 19 Jun 2014 09:23:45 -0500 (CDT)
              Larry Stone <lstone19@...> wrote:
              > On Thu, 19 Jun 2014, D'Arcy J.M. Cain wrote:
              > > I don't know how to do that but I wonder why you want to. The whole
              > > point of authentication is to allow your users to get email without
              > > having to trust the system they are coming in from. If you trust
              > > the domain then just add it to mynetworks and don't bother with
              > > authentication. I suggest authentication though so that your users
              > > can get their email no matter where they are. People are mobile.
              >
              > Whoa, whoa, whoa. The original poster was asking about sending email.
              > You're talking about getting email which is the role of an IMAP or

              My mistake but "get" to "send" and that's what I meant to say.
              Authenticating before sending is the best protection. Of course, you
              trust that the user's account hasn't been compromised but that's always
              an issue anyway.

              > POP server such as Dovecot, not Postfix. Besides that, mynetworks
              > defines trusted IP addresses, not domains.

              Sure. I was using shorthand here but yes I should have said "...add
              the sender's IP address to mynetworks..." I would think that he wanted
              to guarantee that an email claiming to be from a particular domain is
              really coming from there anyway.

              --
              D'Arcy J.M. Cain
              System Administrator, Vex.Net
              http://www.Vex.Net/ IM:darcy@...
              VoIP: sip:darcy@...
            • Vytenis Sabaliauskas
              Perhaps I have expressed it wrong. Many of our users use alias es as FROM, office scanners, scripts, etc. I have implemented this solution in our legacy
              Message 6 of 7 , Jun 19, 2014

                Perhaps I have expressed it wrong.

                Many of our users use alias'es as FROM, office scanners, scripts, etc. I have implemented this solution in our legacy systems. Limiting to a domain had a lower impact. Most of leaked SMTP credentials use spoofed senders (telekom.de, gmail.com, etc.). This blocked ~95% of our outbound spam. Still fine tuning it.

                Now I'm not 100% Postfix'ish, but searching the web gave me no cheap solution how to implement it in Postfix.



                > > I don't know how to do that but I wonder why you want to.  The whole
                > > point of authentication is to allow your users to get email without
                > > having to trust the system they are coming in from.  If you trust
                > > the domain then just add it to mynetworks and don't bother with
                > > authentication.  I suggest authentication though so that your users
                > > can get their email no matter where they are.  People are mobile.
                >
                > Whoa, whoa, whoa. The original poster was asking about sending email.
                > You're talking about getting email which is the role of an IMAP or

                My mistake but "get" to "send" and that's what I meant to say.
                Authenticating before sending is the best protection.  Of course, you
                trust that the user's account hasn't been compromised but that's always
                an issue anyway.

                > POP server such as Dovecot, not Postfix. Besides that, mynetworks
                > defines trusted IP addresses, not domains.

                Sure.  I was using shorthand here but yes I should have said "...add
                the sender's IP address to mynetworks..."  I would think that he wanted
                to guarantee that an email claiming to be from a particular domain is
                really coming from there anyway.

                --
                D'Arcy J.M. Cain
                System Administrator, Vex.Net
                http://www.Vex.Net/ IM:darcy@...
                VoIP: sip:darcy@...



                --
                V.
              • lists@rhsoft.net
                why don t you read docs you are pointed to? reject_authenticated_sender_login_mismatch is using smtpd_sender_login_maps what *excatly* is your problem with
                Message 7 of 7 , Jun 19, 2014
                  why don't you read docs you are pointed to?

                  "reject_authenticated_sender_login_mismatch" is using "smtpd_sender_login_maps"
                  what *excatly* is your problem with the documentation below?
                  _________________________________________

                  http://www.postfix.org/postconf.5.html

                  smtpd_sender_login_maps (default: empty)

                  Optional lookup table with the SASL login names that own sender (MAIL FROM) addresses.

                  Specify zero or more "type:name" lookup tables, separated by whitespace of comma. Tables will be searched in
                  the specified order until a match is found. With lookups from indexed files such as DB or DBM, or from networked
                  tables such as NIS, LDAP or SQL, the following search operations are done with a sender address of user@domain:

                  1) user@domain
                  This table lookup is always done and has the highest precedence.
                  2) user
                  This table lookup is done only when the domain part of the sender address matches $myorigin,
                  $mydestination, $inet_interfaces or $proxy_interfaces.
                  3) @domain
                  This table lookup is done last and has the lowest precedence.

                  In all cases the result of table lookup must be either "not found" or a list of SASL login names separated by
                  comma and/or whitespace.

                  Am 20.06.2014 00:43, schrieb Vytenis Sabaliauskas:
                  > Perhaps I have expressed it wrong.
                  >
                  > Many of our users use alias'es as FROM, office scanners, scripts, etc. I have implemented this solution in our
                  > legacy systems. Limiting to a domain had a lower impact. Most of leaked SMTP credentials use spoofed senders
                  > (telekom.de <http://telekom.de>, gmail.com <http://gmail.com>, etc.). This blocked ~95% of our outbound spam. Still
                  > fine tuning it.
                  >
                  > Now I'm not 100% Postfix'ish, but searching the web gave me no cheap solution how to implement it in Postfix.
                  >
                  >
                  >
                  > > > I don't know how to do that but I wonder why you want to. The whole
                  > > > point of authentication is to allow your users to get email without
                  > > > having to trust the system they are coming in from. If you trust
                  > > > the domain then just add it to mynetworks and don't bother with
                  > > > authentication. I suggest authentication though so that your users
                  > > > can get their email no matter where they are. People are mobile.
                  > >
                  > > Whoa, whoa, whoa. The original poster was asking about sending email.
                  > > You're talking about getting email which is the role of an IMAP or
                  >
                  > My mistake but "get" to "send" and that's what I meant to say.
                  > Authenticating before sending is the best protection. Of course, you
                  > trust that the user's account hasn't been compromised but that's always
                  > an issue anyway.
                  >
                  > > POP server such as Dovecot, not Postfix. Besides that, mynetworks
                  > > defines trusted IP addresses, not domains.
                  >
                  > Sure. I was using shorthand here but yes I should have said "...add
                  > the sender's IP address to mynetworks..." I would think that he wanted
                  > to guarantee that an email claiming to be from a particular domain is
                  > really coming from there anyway.
                Your message has been successfully submitted and would be delivered to recipients shortly.