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

Re: Avoiding (trivial) spoofed "mail from"

Expand Messages
  • Noel Jones
    ... If you have a large number of domains, keep a separate list of the domains and let the computer build the different tables for you. Use a Makefile to make
    Message 1 of 25 , Dec 1, 2008
      Roman Medina-Heigl Hernandez wrote:
      > Noel Jones escribió:
      >> Roman Medina-Heigl Hernandez wrote:
      >>> Hello,
      >>>
      >>> Spammers often send (forged) mail where "mail from" address is the
      >>> same as
      >>> "rcpt to" address. An extension of that could be using a "mail from"
      >>> address where src domain is one of our valid virtual domains. I can only
      >>> think of 3 cases:
      >>> 1) Src IP is 127.0.0.1 -> Mail should pass (eg: sent by webmail,
      >>> installed
      >>> on the same MTA host).
      >>> 2) Authenticated sender -> Legit users authenticated by SASL -> Should
      >>> pass
      >>> 3) All the rest -> Should be rejected (SPAM) (assuming a simple
      >>> single-MTA
      >>> config, where MX -receiving mail server- is the same as MTA -outbound
      >>> sending mail server-)
      >>>
      >>> Which is the best/preferred Postfix config to filter out that kind of
      >>> spam?
      >>>
      >>> I have all my valid domains in:
      >>> virtual_mailbox_domains = hash:/etc/postfix/vdomain
      >>>
      >>> The current format of /etc/postfix/vdomain is:
      >>> domain1 whatever
      >>> domain2 whatever
      >>>
      >>> So perhaps I could do somthing like:
      >>> smtpd_sender_restrictions =
      >>> smtpd_recipient_restrictions =
      >>> permit_mynetworks,
      >>> reject_unauth_destination,
      >>> XXXXX,
      >>> permit
      >>>
      >>> where XXXX could be some kind of "check_sender_access" clausule,
      >>> rejecting
      >>> domains listed in $virtual_mailbox_domains. How could I implement
      >>> this? Is
      >>> there any other preferred solution?
      >> Yes, you can use a map for this;
      >> XXXX above =
      >> check_sender_access hash:/etc/postfix/mydomains
      >>
      >> # mydomains
      >> example.com REJECT inside sender not allowed
      >> example.net REJECT inside sender not allowed
      >> ...
      >
      > So there is no other way to do this without having to "duplicate" the
      > same/similar hash file (/etc/postfix/vdomain and /etc/postfix/mydomains). I
      > thought perhaps it could exist some directive of the form:
      > reject_mydestination_domain_sender or something similar to avoid
      > duplicating domain databases ;-)).

      If you have a large number of domains, keep a separate list of
      the domains and let the computer build the different tables
      for you. Use a Makefile to make it easy.


      >
      >> Note this will reject some legit mail. Spamassassin is probably a
      >
      > Could you elaborate on that legit mail cases? Examples? It's very important
      > for me and I couldn't figure any legit cases (apart from the ones I already
      > mentioned).

      Some web invites / rotten mail lists / web notifications etc.
      will arrive with the recipient's address as the sender. While
      this is generally poor form, a few legit sites do it. I don't
      have any specific examples, but know they exist. "trust me"

      --
      Noel Jones
    • Roman Medina-Heigl Hernandez
      ... Or I could use two different mysql queries, over the same table containing the vdomains... ... Yes, you re right (I trust you! :-)). I did a quick search
      Message 2 of 25 , Dec 1, 2008
        Noel Jones escribió:

        > If you have a large number of domains, keep a separate list of the domains and let the computer build the different tables for you. Use a Makefile to make it easy.

        Or I could use two different mysql queries, over the same table containing
        the vdomains...

        > Some web invites / rotten mail lists / web notifications etc. will
        > arrive with the recipient's address as the sender. While this is
        > generally poor form, a few legit sites do it. I don't have any specific
        > examples, but know they exist. "trust me"

        Yes, you're right (I trust you! :-)). I did a quick search in my inbox and
        found an example: notices from Ubuntu bug tracking system ("Launchpad" at
        canonical.com) use that (poor) technique. But I'm wondering:
        1) How often could you find this "nasty errors" (yes, difficult question;
        impossible to answer, I'd add)
        2) How important are this kind of "notices"...

        Although it's a personal opinion, it seems that I can afford "loosing" such
        mails... On the other hand, perhaps they're identifiable by other means, I
        mean, headers, such as:

        Return-Path: <bounces@...>
        X-Original-To: roman@...
        Delivered-To: roman@...
        ...
        Received: from gangotri.ubuntu.com (localhost.localdomain [127.0.0.1])
        by gangotri.ubuntu.com (Postfix) with ESMTP id 0C222318376
        for <roman@...>; Fri, 28 Jul 2006 04:10:09 +0100 (BST)
        From: RoMaNSoFt <roman@...>
        Reply-To: Bug 26119 <26119@...>
        Sender: bounces@...
        X-Launchpad-Bug: distribution=ubuntu; sourcepackage=linux-source-2.6.15;
        component=main; status=Needs Info; importance=Medium;
        assignee=ben.collins@...;
        To: roman@...
        Errors-To: bounces@...
        X-Generated-By: Launchpad (canonical.com)

        Perhaps the "reply-to" header could be an indication of this kind of notices?

        You are (again) right, perhaps spamassasin is better for performing this
        kind of check... with the added bonus that filtered mail is not dropped,
        but quarantined (so you could always rescue a false negative). Do you know
        "how well" does it (SA) perform at blocking this spam case (src dom=dst
        dom) while recognizing "legit" (but nasty) notices?

        For the very same reason, isn't it better to let Spamassassin make
        "intelligent" SPF-checks instead of using some other policy server with
        Postfix?

        Thank you for your responses.

        --

        Saludos,
        -Roman

        PGP Fingerprint:
        09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742
        [Key ID: 0xEAD56742. Available at KeyServ]
      • Noel Jones
        ... The whole idea of SpamAssassin scoring is that the spamminess of of messages comes from lots of little things - some positive scores, some negative scores
        Message 3 of 25 , Dec 1, 2008
          Roman Medina-Heigl Hernandez wrote:
          > Noel Jones escribió:

          > You are (again) right, perhaps spamassasin is better for performing this
          > kind of check... with the added bonus that filtered mail is not dropped,
          > but quarantined (so you could always rescue a false negative). Do you know
          > "how well" does it (SA) perform at blocking this spam case (src dom=dst
          > dom) while recognizing "legit" (but nasty) notices?
          >
          > For the very same reason, isn't it better to let Spamassassin make
          > "intelligent" SPF-checks instead of using some other policy server with
          > Postfix?

          The whole idea of SpamAssassin scoring is that the spamminess
          of of messages comes from lots of little things - some
          positive scores, some negative scores - that usually adds up
          to something that accurately represents whether a message is
          spam or not. No one rule (unless it's a rare 100% guaranteed
          spam indicator) ever decides on its own that a message is spam.

          While a message might exhibit the From=To and SPF errors
          described above, most legit mail still wouldn't trigger enough
          points to get into the "likely spam" range.

          SpamAssassin itself isn't 100% accurate, but it does fairly
          well with a very wide range of junk. It's a good tool to use,
          but you need more than one tool.
          Selective RBLs (zen.spamhaus.org is highly recommended),
          ClamAV with the Sanesecurity add-on signatures, and careful
          postfix checks can reject a lot of spam before SpamAssassin
          ever sees it.

          It's also important to note that the settings you use depend
          on your user base and your goals - there is no
          one-size-fits-all solution, which is why you'll never see such
          a thing posted here. Your best bet is to lurk on the list for
          a while or browse the archives to learn what might work well
          in your situation.

          --
          Noel Jones
        • DJ Lucas
          ... Maybe I m incorrect, but I believe there was a subtle misunderstanding in the above conversation. The From: header is not the same as MAIL FROM: command
          Message 4 of 25 , Dec 1, 2008
            Roman Medina-Heigl Hernandez wrote:
            > Yes, you're right (I trust you! :-)). I did a quick search in my inbox and
            > found an example: notices from Ubuntu bug tracking system ("Launchpad" at
            > canonical.com) use that (poor) technique. But I'm wondering:
            > 1) How often could you find this "nasty errors" (yes, difficult question;
            > impossible to answer, I'd add)
            > 2) How important are this kind of "notices"...
            >
            > Although it's a personal opinion, it seems that I can afford "loosing" such
            > mails... On the other hand, perhaps they're identifiable by other means, I
            > mean, headers, such as:
            >
            > Return-Path: <bounces@...>
            > X-Original-To: roman@...
            > Delivered-To: roman@...
            > ...
            > Received: from gangotri.ubuntu.com (localhost.localdomain [127.0.0.1])
            > by gangotri.ubuntu.com (Postfix) with ESMTP id 0C222318376
            > for <roman@...>; Fri, 28 Jul 2006 04:10:09 +0100 (BST)
            > From: RoMaNSoFt <roman@...>
            >
            Maybe I'm incorrect, but I believe there was a subtle misunderstanding
            in the above conversation. The From: header is not the same as MAIL
            FROM: command in smtp transaction. MAIL FROM for this message was
            bounces@.... Feel fee to find that message in your logs and
            verify. Anyway, the Postfix directive you are looking for is
            "reject_unauthenticated_sender_login_mismatch".

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

            That said, cheap web scripts often do use the recipient's address in the
            transaction. Latest complaint I had was from some star rewards thing
            for frequent visits to a restaurant (for which I promptly replied:
            "choose a different restaurant" ;-) ).

            Take the following two manual transactions as an example with the smtpd
            sender restriction above (only slightly altered to avoid giving away
            unnecessary info and posting a real address in plain text on the internet):

            [dj@name25 ~]# telnet mail.lucasit.com 25
            Trying 192.168.xxx.xxx...
            Connected to mail.lucasit.com.
            Escape character is '^]'.
            220 postal.lucasit.com ESMTP Postfix
            ehlo somehost.lucasit.com
            250-postal.lucasit.com
            250-PIPELINING
            250-SIZE 10240000
            250-VRFY
            250-ETRN
            250-STARTTLS
            250-ENHANCEDSTATUSCODES
            250-8BITMIME
            250 DSN
            MAIL FROM: nouser@...
            250 2.1.0 Ok
            RCPT TO: nouser@...
            553 5.7.1 <nouser@...>: Sender address rejected: not logged in
            quit
            221 2.0.0 Bye
            Connection closed by foreign host.
            [dj@name25 ~]#


            [dj@name25 ~]# telnet mail.lucasit.com 25
            Trying 192.168.xxx.xxx...
            Connected to mail.lucasit.com.
            Escape character is '^]'.
            220 postal.lucasit.com ESMTP Postfix
            ehlo somehost@...
            250-postal.lucasit.com
            250-PIPELINING
            250-SIZE 10240000
            250-VRFY
            250-ETRN
            250-STARTTLS
            250-ENHANCEDSTATUSCODES
            250-8BITMIME
            250 DSN
            MAIL FROM: bounces@...
            250 2.1.0 Ok
            RCPT TO: nouser@...
            450 4.2.0 <nouser@...>: Recipient address rejected: Greylisted,
            see http://postgrey.schweikert.ch/help/lucasit.com.html
            quit
            221 2.0.0 Bye
            Connection closed by foreign host.
            [dj@name25 ~]#

            HTH

            -- DJ Lucas


            --
            This message has been scanned for viruses and
            dangerous content, and is believed to be clean.
          • DJ Lucas
            ... Coincidently, I just corrected a mis-configuration in my server as a result of that example. Commented out helo restrictions a really long time ago...they
            Message 5 of 25 , Dec 1, 2008
              DJ Lucas wrote:
              >
              > ehlo somehost@...
              Coincidently, I just corrected a mis-configuration in my server as a
              result of that example. Commented out helo restrictions a really long
              time ago...they must not have been doing too much. :-)

              -- DJ Lucas

              --
              This message has been scanned for viruses and
              dangerous content, and is believed to be clean.
            • Roman Medina-Heigl Hernandez
              ... Thank you for the correction, you are right: my example is wrong but that doesn t change the fact we were discussing since Noel and I were always referring
              Message 6 of 25 , Dec 2, 2008
                DJ Lucas escribió:
                >> Return-Path: <bounces@...>
                >> X-Original-To: roman@...
                >> Delivered-To: roman@...
                >> ...
                >> Received: from gangotri.ubuntu.com (localhost.localdomain [127.0.0.1])
                >> by gangotri.ubuntu.com (Postfix) with ESMTP id 0C222318376
                >> for <roman@...>; Fri, 28 Jul 2006 04:10:09 +0100 (BST)
                >> From: RoMaNSoFt <roman@...>
                >>
                > Maybe I'm incorrect, but I believe there was a subtle misunderstanding
                > in the above conversation. The From: header is not the same as MAIL
                > FROM: command in smtp transaction. MAIL FROM for this message was
                > bounces@.... Feel fee to find that message in your logs and

                Thank you for the correction, you are right: my example is wrong but that
                doesn't change the fact we were discussing since Noel and I were always
                referring to the "mail from" (i.e. the sender). If some silly ticket system
                spoofs the "From" header, there is a good chance that it spoofs the "mail
                from" too...

                > verify. Anyway, the Postfix directive you are looking for is
                > "reject_unauthenticated_sender_login_mismatch".
                > http://www.postfix.org/postconf.5.html#reject_unauthenticated_sender_login_mismatch

                Yes, I think that's the directive I was looking for.

                > That said, cheap web scripts often do use the recipient's address in the
                > transaction. Latest complaint I had was from some star rewards thing
                > for frequent visits to a restaurant (for which I promptly replied:
                > "choose a different restaurant" ;-) ).
                >
                > Take the following two manual transactions as an example with the smtpd
                > sender restriction above (only slightly altered to avoid giving away
                > unnecessary info and posting a real address in plain text on the internet):
                >
                > [dj@name25 ~]# telnet mail.lucasit.com 25
                > Trying 192.168.xxx.xxx...
                > Connected to mail.lucasit.com.
                > Escape character is '^]'.
                > 220 postal.lucasit.com ESMTP Postfix
                > ehlo somehost.lucasit.com
                > 250-postal.lucasit.com
                > 250-PIPELINING

                Isn't a good idea to disable pipelining? (many people recommends it to
                reduce spam).

                > 250-SIZE 10240000
                > 250-VRFY
                > 250-ETRN
                > 250-STARTTLS
                > 250-ENHANCEDSTATUSCODES
                > 250-8BITMIME
                > 250 DSN
                > MAIL FROM: nouser@...
                > 250 2.1.0 Ok
                > RCPT TO: nouser@...
                > 553 5.7.1 <nouser@...>: Sender address rejected: not logged in

                Nice. That's what I'd like to set-up. Nevertheless, I tried to reproduce in
                a test system, with no luck :-(. It should be trivial, but I cannot find
                the error. Could you help me?

                My setup is quite simple (using virtual domains and Amavis to "mark"
                virus/spam messages):

                hsnew:/etc/postfix# postconf -n
                alias_maps = hash:/etc/aliases
                append_dot_mydomain = no
                biff = no
                broken_sasl_auth_clients = yes
                command_directory = /usr/sbin
                config_directory = /etc/postfix
                content_filter = amavisfeed:[127.0.0.1]:10024
                daemon_directory = /usr/lib/postfix
                delay_warning_time = 4
                disable_vrfy_command = yes
                mail_name = mxhs
                mailbox_command = procmail -a "$EXTENSION"
                message_size_limit = 28311552
                mydestination = $myhostname localhost localhost.$mydomain
                myhostname = hsnew.rs-labs.es
                mynetworks = 127.0.0.2, 127.0.0.3
                myorigin = $myhostname
                recipient_delimiter = +
                relay_domains = hash:/etc/postfix/listas hash:/etc/postfix/mxbackup
                relocated_maps = hash:/etc/postfix/relocated
                show_user_unknown_table_name = no
                smtp_sasl_auth_enable = yes
                smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
                smtp_sasl_security_options = noplaintext
                smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache
                smtpd_recipient_restrictions = reject_non_fqdn_recipient,
                permit_mynetworks, permit_sasl_authenticated,
                reject_unauthenticated_sender_login_mismatch, check_recipient_access
                hash:/etc/postfix/recipient_access_non_trusted, reject_unauth_destination
                smtpd_sasl_auth_enable = yes
                smtpd_sasl_path = smtpd
                smtpd_sasl_security_options = noanonymous
                smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
                smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
                smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
                smtpd_use_tls = yes
                transport_maps = hash:/etc/postfix/listas
                virtual_alias_maps = hash:/etc/postfix/valias
                virtual_mailbox_domains = hash:/etc/postfix/vdomain
                virtual_mailbox_maps = hash:/etc/postfix/vuser
                virtual_transport = lmtp:unix:/private/cyrus
                hsnew:/etc/postfix# cat vuser
                roman@... whatever
                hsnew:/etc/postfix# cat vdomain
                rs-labs.es whatever
                hsnew:/etc/postfix#


                From another host ("not trusted"), I'm sending a very simple mail:
                root@mta-mad:/tmp# cat mail
                helo k
                mail from:roman@...
                rcpt to:roman@...
                data
                subject: prueba
                .
                quit
                root@mta-mad:/tmp# nc hsnew.rs-labs.es 25 <mail
                220 hsnew.rs-labs.es ESMTP Sendmail 8.14.2/8.14.1
                250 hsnew.rs-labs.es
                250 2.1.0 Ok
                250 2.1.5 Ok
                354 End data with <CR><LF>.<CR><LF>
                250 2.0.0 Ok: queued as 3A4F6982AA
                221 2.0.0 Bye
                root@mta-mad:/tmp#


                My receiving MTA logs the following:

                Dec 2 16:34:12 hsnew postfix/smtpd[3697]: connect from
                207-150-162-19.static.sagonet.net[207.150.162.19]
                Dec 2 16:34:12 hsnew postfix/smtpd[3697]: 3A4F6982AA:
                client=207-150-162-19.static.sagonet.net[207.150.162.19]
                Dec 2 16:34:12 hsnew postfix/cleanup[3702]: 3A4F6982AA:
                message-id=<20081202153412.3A4F6982AA@...-labs.es>
                Dec 2 16:34:12 hsnew postfix/qmgr[3666]: 3A4F6982AA:
                from=<roman@...>, size=362, nrcpt=1 (queue active)
                Dec 2 16:34:12 hsnew postfix/smtpd[3697]: disconnect from
                207-150-162-19.static.sagonet.net[207.150.162.19]
                Dec 2 16:34:15 hsnew postfix/smtpd[3706]: connect from localhost[127.0.0.1]
                Dec 2 16:34:16 hsnew postfix/smtpd[3706]: EAF0A982BB:
                client=localhost[127.0.0.1]
                Dec 2 16:34:16 hsnew postfix/cleanup[3702]: EAF0A982BB:
                message-id=<20081202153412.3A4F6982AA@...-labs.es>
                Dec 2 16:34:16 hsnew postfix/smtpd[3706]: disconnect from localhost[127.0.0.1]
                Dec 2 16:34:16 hsnew postfix/qmgr[3666]: EAF0A982BB:
                from=<roman@...>, size=805, nrcpt=1 (queue active)
                Dec 2 16:34:16 hsnew cyrus/master[3708]: about to exec
                /usr/lib/cyrus/bin/lmtpd
                Dec 2 16:34:16 hsnew amavis[3311]: (03311-01) Passed BAD-HEADER,
                [207.150.162.19] [207.150.162.19] <roman@...> -> <roman@...>,
                Message-ID: <20081202153412.3A4F6982AA@...-labs.es>, mail_id:
                NHfrTekZSsR4, Hits: 4.594, queued_as: EAF0A982BB, 3522 ms
                Dec 2 16:34:16 hsnew postfix/lmtp[3703]: 3A4F6982AA:
                to=<roman@...>, relay=127.0.0.1[127.0.0.1]:10024, delay=3.9,
                delays=0.08/0.03/0.76/3.1, dsn=2.6.0, status=sent (250 2.6.0 Ok,
                id=03311-01, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as EAF0A982BB)
                Dec 2 16:34:16 hsnew postfix/qmgr[3666]: 3A4F6982AA: removed
                Dec 2 16:34:16 hsnew cyrus/lmtpunix[3708]: executed
                Dec 2 16:34:16 hsnew cyrus/lmtpunix[3708]: accepted connection
                Dec 2 16:34:16 hsnew cyrus/lmtpunix[3708]: lmtp connection preauth'd as
                postman
                Dec 2 16:34:16 hsnew cyrus/lmtpunix[3708]: duplicate_check:
                <20081202153412.3A4F6982AA@...-labs.es> rs-labs.es!user.roman 0
                Dec 2 16:34:16 hsnew cyrus/lmtpunix[3708]: duplicate_check:
                <20081202153412.3A4F6982AA@...-labs.es> rs-labs.es!user.roman 0
                Dec 2 16:34:16 hsnew cyrus/lmtpunix[3708]: mystore: starting txn 2147484444
                Dec 2 16:34:16 hsnew cyrus/lmtpunix[3708]: mystore: committing txn 2147484444
                Dec 2 16:34:16 hsnew cyrus/lmtpunix[3708]: duplicate_mark:
                <20081202153412.3A4F6982AA@...-labs.es> rs-labs.es!user.roman
                1228232056 134537227
                Dec 2 16:34:16 hsnew cyrus/lmtpunix[3708]: Delivered:
                <20081202153412.3A4F6982AA@...-labs.es> to mailbox: rs-labs.es!user.roman
                Dec 2 16:34:16 hsnew cyrus/lmtpunix[3708]: mystore: starting txn 2147484445
                Dec 2 16:34:16 hsnew cyrus/lmtpunix[3708]: mystore: committing txn 2147484445
                Dec 2 16:34:16 hsnew cyrus/lmtpunix[3708]: duplicate_mark:
                <20081202153412.3A4F6982AA@...-labs.es> .roman+@....
                1228232056 0
                Dec 2 16:34:16 hsnew postfix/lmtp[3707]: EAF0A982BB:
                to=<roman@...>, relay=hsnew.rs-labs.es[/private/cyrus], delay=0.41,
                delays=0.12/0.01/0.14/0.13, dsn=2.1.5, status=sent (250 2.1.5 Ok)
                Dec 2 16:34:16 hsnew postfix/qmgr[3666]: EAF0A982BB: removed

                Why is the mail not being rejected due to
                reject_unauthenticated_sender_login_mismatch? I must have a silly bug but I
                couldn't find it... :-(

                TIA.
                -Román
              • Roman Medina-Heigl Hernandez
                ... I got to solve it by: smtpd_sender_login_maps = $virtual_mailbox_maps But it seems tricky, since you have to explicitly define a login map... I think
                Message 7 of 25 , Dec 2, 2008
                  Roman Medina-Heigl Hernandez escribió:
                  > DJ Lucas escribió:
                  >>> Return-Path: <bounces@...>
                  >>> X-Original-To: roman@...
                  >>> Delivered-To: roman@...
                  >>> ...
                  >>> Received: from gangotri.ubuntu.com (localhost.localdomain [127.0.0.1])
                  >>> by gangotri.ubuntu.com (Postfix) with ESMTP id 0C222318376
                  >>> for <roman@...>; Fri, 28 Jul 2006 04:10:09 +0100 (BST)
                  >>> From: RoMaNSoFt <roman@...>
                  >>>
                  >> Maybe I'm incorrect, but I believe there was a subtle misunderstanding
                  >> in the above conversation. The From: header is not the same as MAIL
                  >> FROM: command in smtp transaction. MAIL FROM for this message was
                  >> bounces@.... Feel fee to find that message in your logs and
                  >
                  > Thank you for the correction, you are right: my example is wrong but that
                  > doesn't change the fact we were discussing since Noel and I were always
                  > referring to the "mail from" (i.e. the sender). If some silly ticket system
                  > spoofs the "From" header, there is a good chance that it spoofs the "mail
                  > from" too...
                  >
                  >> verify. Anyway, the Postfix directive you are looking for is
                  >> "reject_unauthenticated_sender_login_mismatch".
                  >> http://www.postfix.org/postconf.5.html#reject_unauthenticated_sender_login_mismatch
                  >
                  > Yes, I think that's the directive I was looking for.
                  >
                  >> That said, cheap web scripts often do use the recipient's address in the
                  >> transaction. Latest complaint I had was from some star rewards thing
                  >> for frequent visits to a restaurant (for which I promptly replied:
                  >> "choose a different restaurant" ;-) ).
                  >>
                  >> Take the following two manual transactions as an example with the smtpd
                  >> sender restriction above (only slightly altered to avoid giving away
                  >> unnecessary info and posting a real address in plain text on the internet):
                  >>
                  >> [dj@name25 ~]# telnet mail.lucasit.com 25
                  >> Trying 192.168.xxx.xxx...
                  >> Connected to mail.lucasit.com.
                  >> Escape character is '^]'.
                  >> 220 postal.lucasit.com ESMTP Postfix
                  >> ehlo somehost.lucasit.com
                  >> 250-postal.lucasit.com
                  >> 250-PIPELINING
                  >
                  > Isn't a good idea to disable pipelining? (many people recommends it to
                  > reduce spam).
                  >
                  >> 250-SIZE 10240000
                  >> 250-VRFY
                  >> 250-ETRN
                  >> 250-STARTTLS
                  >> 250-ENHANCEDSTATUSCODES
                  >> 250-8BITMIME
                  >> 250 DSN
                  >> MAIL FROM: nouser@...
                  >> 250 2.1.0 Ok
                  >> RCPT TO: nouser@...
                  >> 553 5.7.1 <nouser@...>: Sender address rejected: not logged in
                  >
                  > Nice. That's what I'd like to set-up. Nevertheless, I tried to reproduce in
                  > a test system, with no luck :-(. It should be trivial, but I cannot find
                  > the error. Could you help me?
                  >
                  > My setup is quite simple (using virtual domains and Amavis to "mark"
                  > virus/spam messages):
                  >
                  > hsnew:/etc/postfix# postconf -n
                  > alias_maps = hash:/etc/aliases
                  > append_dot_mydomain = no
                  > biff = no
                  > broken_sasl_auth_clients = yes
                  > command_directory = /usr/sbin
                  > config_directory = /etc/postfix
                  > content_filter = amavisfeed:[127.0.0.1]:10024
                  > daemon_directory = /usr/lib/postfix
                  > delay_warning_time = 4
                  > disable_vrfy_command = yes
                  > mail_name = mxhs
                  > mailbox_command = procmail -a "$EXTENSION"
                  > message_size_limit = 28311552
                  > mydestination = $myhostname localhost localhost.$mydomain
                  > myhostname = hsnew.rs-labs.es
                  > mynetworks = 127.0.0.2, 127.0.0.3
                  > myorigin = $myhostname
                  > recipient_delimiter = +
                  > relay_domains = hash:/etc/postfix/listas hash:/etc/postfix/mxbackup
                  > relocated_maps = hash:/etc/postfix/relocated
                  > show_user_unknown_table_name = no
                  > smtp_sasl_auth_enable = yes
                  > smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
                  > smtp_sasl_security_options = noplaintext
                  > smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache
                  > smtpd_recipient_restrictions = reject_non_fqdn_recipient,
                  > permit_mynetworks, permit_sasl_authenticated,
                  > reject_unauthenticated_sender_login_mismatch, check_recipient_access
                  > hash:/etc/postfix/recipient_access_non_trusted, reject_unauth_destination
                  > smtpd_sasl_auth_enable = yes
                  > smtpd_sasl_path = smtpd
                  > smtpd_sasl_security_options = noanonymous
                  > smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
                  > smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
                  > smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
                  > smtpd_use_tls = yes
                  > transport_maps = hash:/etc/postfix/listas
                  > virtual_alias_maps = hash:/etc/postfix/valias
                  > virtual_mailbox_domains = hash:/etc/postfix/vdomain
                  > virtual_mailbox_maps = hash:/etc/postfix/vuser
                  > virtual_transport = lmtp:unix:/private/cyrus
                  > hsnew:/etc/postfix# cat vuser
                  > roman@... whatever
                  > hsnew:/etc/postfix# cat vdomain
                  > rs-labs.es whatever
                  > hsnew:/etc/postfix#
                  >
                  >
                  > From another host ("not trusted"), I'm sending a very simple mail:
                  > root@mta-mad:/tmp# cat mail
                  > helo k
                  > mail from:roman@...
                  > rcpt to:roman@...
                  > data
                  > subject: prueba
                  > .
                  > quit
                  > root@mta-mad:/tmp# nc hsnew.rs-labs.es 25 <mail
                  > 220 hsnew.rs-labs.es ESMTP Sendmail 8.14.2/8.14.1
                  > 250 hsnew.rs-labs.es
                  > 250 2.1.0 Ok
                  > 250 2.1.5 Ok
                  > 354 End data with <CR><LF>.<CR><LF>
                  > 250 2.0.0 Ok: queued as 3A4F6982AA
                  > 221 2.0.0 Bye
                  > root@mta-mad:/tmp#
                  >
                  >
                  > My receiving MTA logs the following:
                  >
                  > Dec 2 16:34:12 hsnew postfix/smtpd[3697]: connect from
                  > 207-150-162-19.static.sagonet.net[207.150.162.19]
                  > Dec 2 16:34:12 hsnew postfix/smtpd[3697]: 3A4F6982AA:
                  > client=207-150-162-19.static.sagonet.net[207.150.162.19]
                  > Dec 2 16:34:12 hsnew postfix/cleanup[3702]: 3A4F6982AA:
                  > message-id=<20081202153412.3A4F6982AA@...-labs.es>
                  > Dec 2 16:34:12 hsnew postfix/qmgr[3666]: 3A4F6982AA:
                  > from=<roman@...>, size=362, nrcpt=1 (queue active)
                  > Dec 2 16:34:12 hsnew postfix/smtpd[3697]: disconnect from
                  > 207-150-162-19.static.sagonet.net[207.150.162.19]
                  > Dec 2 16:34:15 hsnew postfix/smtpd[3706]: connect from localhost[127.0.0.1]
                  > Dec 2 16:34:16 hsnew postfix/smtpd[3706]: EAF0A982BB:
                  > client=localhost[127.0.0.1]
                  > Dec 2 16:34:16 hsnew postfix/cleanup[3702]: EAF0A982BB:
                  > message-id=<20081202153412.3A4F6982AA@...-labs.es>
                  > Dec 2 16:34:16 hsnew postfix/smtpd[3706]: disconnect from localhost[127.0.0.1]
                  > Dec 2 16:34:16 hsnew postfix/qmgr[3666]: EAF0A982BB:
                  > from=<roman@...>, size=805, nrcpt=1 (queue active)
                  > Dec 2 16:34:16 hsnew cyrus/master[3708]: about to exec
                  > /usr/lib/cyrus/bin/lmtpd
                  > Dec 2 16:34:16 hsnew amavis[3311]: (03311-01) Passed BAD-HEADER,
                  > [207.150.162.19] [207.150.162.19] <roman@...> -> <roman@...>,
                  > Message-ID: <20081202153412.3A4F6982AA@...-labs.es>, mail_id:
                  > NHfrTekZSsR4, Hits: 4.594, queued_as: EAF0A982BB, 3522 ms
                  > Dec 2 16:34:16 hsnew postfix/lmtp[3703]: 3A4F6982AA:
                  > to=<roman@...>, relay=127.0.0.1[127.0.0.1]:10024, delay=3.9,
                  > delays=0.08/0.03/0.76/3.1, dsn=2.6.0, status=sent (250 2.6.0 Ok,
                  > id=03311-01, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as EAF0A982BB)
                  > Dec 2 16:34:16 hsnew postfix/qmgr[3666]: 3A4F6982AA: removed
                  > Dec 2 16:34:16 hsnew cyrus/lmtpunix[3708]: executed
                  > Dec 2 16:34:16 hsnew cyrus/lmtpunix[3708]: accepted connection
                  > Dec 2 16:34:16 hsnew cyrus/lmtpunix[3708]: lmtp connection preauth'd as
                  > postman
                  > Dec 2 16:34:16 hsnew cyrus/lmtpunix[3708]: duplicate_check:
                  > <20081202153412.3A4F6982AA@...-labs.es> rs-labs.es!user.roman 0
                  > Dec 2 16:34:16 hsnew cyrus/lmtpunix[3708]: duplicate_check:
                  > <20081202153412.3A4F6982AA@...-labs.es> rs-labs.es!user.roman 0
                  > Dec 2 16:34:16 hsnew cyrus/lmtpunix[3708]: mystore: starting txn 2147484444
                  > Dec 2 16:34:16 hsnew cyrus/lmtpunix[3708]: mystore: committing txn 2147484444
                  > Dec 2 16:34:16 hsnew cyrus/lmtpunix[3708]: duplicate_mark:
                  > <20081202153412.3A4F6982AA@...-labs.es> rs-labs.es!user.roman
                  > 1228232056 134537227
                  > Dec 2 16:34:16 hsnew cyrus/lmtpunix[3708]: Delivered:
                  > <20081202153412.3A4F6982AA@...-labs.es> to mailbox: rs-labs.es!user.roman
                  > Dec 2 16:34:16 hsnew cyrus/lmtpunix[3708]: mystore: starting txn 2147484445
                  > Dec 2 16:34:16 hsnew cyrus/lmtpunix[3708]: mystore: committing txn 2147484445
                  > Dec 2 16:34:16 hsnew cyrus/lmtpunix[3708]: duplicate_mark:
                  > <20081202153412.3A4F6982AA@...-labs.es> .roman+@....
                  > 1228232056 0
                  > Dec 2 16:34:16 hsnew postfix/lmtp[3707]: EAF0A982BB:
                  > to=<roman@...>, relay=hsnew.rs-labs.es[/private/cyrus], delay=0.41,
                  > delays=0.12/0.01/0.14/0.13, dsn=2.1.5, status=sent (250 2.1.5 Ok)
                  > Dec 2 16:34:16 hsnew postfix/qmgr[3666]: EAF0A982BB: removed
                  >
                  > Why is the mail not being rejected due to
                  > reject_unauthenticated_sender_login_mismatch? I must have a silly bug but I
                  > couldn't find it... :-(

                  I got to solve it by:
                  smtpd_sender_login_maps = $virtual_mailbox_maps

                  But it seems tricky, since you have to explicitly define a login map... I
                  think (please, correct me if I'm wrong) the point is: "if you don't define
                  $smtpd_sender_login_maps, Postfix doesn't know where a "login mismatch"
                  could exist. Yes, it's true but:
                  - wouldn't it be clever to assume SASL login should be equal to the sender,
                  if not explicitly defined otherwise? (so no login map is necessary, except
                  when login users are different from sender).
                  - SASL works ok without defining $smtpd_sender_login_maps so you can
                  perfectly differentiate "authenticated_sender" vs "unauthenticated_sender",
                  without having any map? Why is it necessary to define
                  $smtpd_sender_login_maps? It's confussing...

                  Finally, if you have to define $smtpd_sender_login_maps, it would be
                  equivalent to use my former propposed method, with check_sender_access (see
                  my first post on this thread and the second one by Noel), in the sense that
                  you have to create an extra db file, and even worse than my first solution,
                  since first one seems more restrictive (it could reject
                  non_valid@... -> valid_user@..., while second one only can
                  reject valid@... -> valid@..., because only valid users are
                  included in $virtual_mailbox_maps).

                  I'd like hearing from you...

                  Cheers,
                  -Román
                • Noel Jones
                  ... No, do not disable pipelining. I can t imagine it makes any significant difference in spam, at the expense of extra burden for you and everyone you
                  Message 8 of 25 , Dec 2, 2008
                    Roman Medina-Heigl Hernandez wrote:

                    >> [dj@name25 ~]# telnet mail.lucasit.com 25
                    >> Trying 192.168.xxx.xxx...
                    >> Connected to mail.lucasit.com.
                    >> Escape character is '^]'.
                    >> 220 postal.lucasit.com ESMTP Postfix
                    >> ehlo somehost.lucasit.com
                    >> 250-postal.lucasit.com
                    >> 250-PIPELINING
                    >
                    > Isn't a good idea to disable pipelining? (many people recommends it to
                    > reduce spam).

                    No, do not disable pipelining. I can't imagine it makes any
                    significant difference in spam, at the expense of extra burden
                    for you and everyone you exchange mail with. Pipelining is
                    useful.

                    --
                    Noel Jones
                  • mouss
                    ... do not reuse maps this way. use a script to generate each map instead (or use note that smtpd_sender_login_maps returns one or more logins, while
                    Message 9 of 25 , Dec 2, 2008
                      Roman Medina-Heigl Hernandez a écrit :
                      >> Why is the mail not being rejected due to
                      >> reject_unauthenticated_sender_login_mismatch? I must have a silly bug but I
                      >> couldn't find it... :-(
                      >
                      > I got to solve it by:
                      > smtpd_sender_login_maps = $virtual_mailbox_maps
                      >

                      do not reuse maps this way. use a script to generate each map instead
                      (or use

                      note that smtpd_sender_login_maps returns one or more logins, while
                      virtual_mailbox_maps returns the path to the mailbox.

                      > But it seems tricky, since you have to explicitly define a login map... I
                      > think (please, correct me if I'm wrong) the point is: "if you don't define
                      > $smtpd_sender_login_maps, Postfix doesn't know where a "login mismatch"
                      > could exist. Yes, it's true but:
                      > - wouldn't it be clever to assume SASL login should be equal to the sender,
                      > if not explicitly defined otherwise? (so no login map is necessary, except
                      > when login users are different from sender).
                      > - SASL works ok without defining $smtpd_sender_login_maps so you can
                      > perfectly differentiate "authenticated_sender" vs "unauthenticated_sender",
                      > without having any map? Why is it necessary to define
                      > $smtpd_sender_login_maps? It's confussing...
                      >
                      > Finally, if you have to define $smtpd_sender_login_maps, it would be
                      > equivalent to use my former propposed method, with check_sender_access (see
                      > my first post on this thread and the second one by Noel), in the sense that
                      > you have to create an extra db file, and even worse than my first solution,
                      > since first one seems more restrictive (it could reject
                      > non_valid@... -> valid_user@..., while second one only can
                      > reject valid@... -> valid@..., because only valid users are
                      > included in $virtual_mailbox_maps).
                      >
                      > I'd like hearing from you...
                      >
                      > Cheers,
                      > -Román
                      >
                    • J.P. Trosclair
                      ... I have been working on a similar if not the exact same problem from what I ve seen in this thread. The problem being from = to address and how to stop spam
                      Message 10 of 25 , Dec 2, 2008
                        Roman Medina-Heigl Hernandez wrote:
                        > DJ Lucas escribió:
                        >>> Return-Path: <bounces@...>
                        >>> X-Original-To: roman@...
                        >>> Delivered-To: roman@...
                        >>> ...
                        >>> Received: from gangotri.ubuntu.com (localhost.localdomain [127.0.0.1])
                        >>> by gangotri.ubuntu.com (Postfix) with ESMTP id 0C222318376
                        >>> for <roman@...>; Fri, 28 Jul 2006 04:10:09 +0100 (BST)
                        >>> From: RoMaNSoFt <roman@...>
                        >>>
                        >> Maybe I'm incorrect, but I believe there was a subtle misunderstanding
                        >> in the above conversation. The From: header is not the same as MAIL
                        >> FROM: command in smtp transaction. MAIL FROM for this message was
                        >> bounces@.... Feel fee to find that message in your logs and
                        >
                        > Thank you for the correction, you are right: my example is wrong but that
                        > doesn't change the fact we were discussing since Noel and I were always
                        > referring to the "mail from" (i.e. the sender). If some silly ticket system
                        > spoofs the "From" header, there is a good chance that it spoofs the "mail
                        > from" too...
                        >
                        >> verify. Anyway, the Postfix directive you are looking for is
                        >> "reject_unauthenticated_sender_login_mismatch".
                        >> http://www.postfix.org/postconf.5.html#reject_unauthenticated_sender_login_mismatch
                        >
                        > Yes, I think that's the directive I was looking for.
                        >
                        >> That said, cheap web scripts often do use the recipient's address in the
                        >> transaction. Latest complaint I had was from some star rewards thing
                        >> for frequent visits to a restaurant (for which I promptly replied:
                        >> "choose a different restaurant" ;-) ).
                        >>

                        I have been working on a similar if not the exact same problem from what
                        I've seen in this thread. The problem being from = to address and how to
                        stop spam that does this. My idea for a solution to this problem was to
                        require any mail claiming to be from a local account to authenticate
                        first when arriving from outside of the network and heading to a local
                        mailbox. As it has already been pointed out, there are cases where you
                        have false positives, in fact I found one yesterday with a user's
                        blackberry setup shortly after I set it up. I'm thinking that utilizing
                        check_client_access before check_sender_access under
                        smtpd_recipient_restrictions and adding exceptions for these few cases
                        is a sound solution. It's obviously not perfect because of the
                        administration overhead of having to watch for these special
                        circumstances. I have yet to test this. Any thoughts on this approach?
                      • Noel Jones
                        ... Very likely there are other, better ways to combat this spam. Look for other traits you can use to reject it. some things to look for: - client listed on
                        Message 11 of 25 , Dec 2, 2008
                          J.P. Trosclair wrote:
                          > I have been working on a similar if not the exact same problem from what
                          > I've seen in this thread. The problem being from = to address and how to
                          > stop spam that does this. My idea for a solution to this problem was to
                          > require any mail claiming to be from a local account to authenticate
                          > first when arriving from outside of the network and heading to a local
                          > mailbox. As it has already been pointed out, there are cases where you
                          > have false positives, in fact I found one yesterday with a user's
                          > blackberry setup shortly after I set it up. I'm thinking that utilizing
                          > check_client_access before check_sender_access under
                          > smtpd_recipient_restrictions and adding exceptions for these few cases
                          > is a sound solution. It's obviously not perfect because of the
                          > administration overhead of having to watch for these special
                          > circumstances. I have yet to test this. Any thoughts on this approach?
                          >

                          Very likely there are other, better ways to combat this spam.
                          Look for other traits you can use to reject it.

                          some things to look for:
                          - client listed on some RBL
                          - client name that looks dynamic
                          - using your domain or IP as HELO
                          - unusual headers
                          - body text unlikely to be found in legit mail

                          If that doesn't help, consider adding SpamAssassin and/or ClamAV.

                          --
                          Noel Jones
                        • DJ Lucas
                          ... I am, by no means, anything even close to expert WRT the whole SMTP process, but, I do think that I can provide (or at least what I believe to be) a valid,
                          Message 12 of 25 , Dec 2, 2008
                            Noel Jones wrote:
                            >
                            > Very likely there are other, better ways to combat this spam. Look
                            > for other traits you can use to reject it.
                            >
                            I am, by no means, anything even close to expert WRT the whole SMTP
                            process, but, I do think that I can provide (or at least what I believe
                            to be) a valid, albeit opinionated, counter argument. See below.
                            > some things to look for:
                            > - client listed on some RBL
                            > - client name that looks dynamic
                            > - using your domain or IP as HELO
                            > - unusual headers
                            > - body text unlikely to be found in legit mail
                            >
                            > If that doesn't help, consider adding SpamAssassin and/or ClamAV.
                            From my POV, this one check saves me a small few (100, 200?) DNS/RBL
                            lookups per month and a few CPU cycles by not getting to header checks,
                            body checks, and finally SA (which is probably the most expensive check
                            in the stack, followed immediately by virus scanning). I can probably
                            parse my logs and give a real number, but it would seem insignificant to
                            those running large servers. It is my _choice_ to be as efficient as
                            possible.

                            <IMO>
                            Please correct me if I've made an invalid assumption (but do take notice
                            of the "IMO" qualifier!)

                            I can find absolutely no reason to inadvertently mislead, or worse,
                            intentionally deceive the recipient by forging the envelope sender's
                            address. In fact, the only reason I can see, is to intentionally
                            deceive the recipient. Is there any other reason?

                            It is plain irresponsible, even if allowed by RFC. Even more so given
                            that most (all?) mail clients will honor the from header and display it,
                            in big, bright, flashy, bold text, in a prominent location for the end
                            user to see (and reply to). Maybe I've missed something, but I really
                            cannot find a good reason to allow it. Even the BlackBerry example
                            given above is an example of poor practice in my opinion, but it can be
                            an ALLOWed exception if it is out of your control.

                            But that is all a matter of principal, not a technical reason. The
                            technical reason (minor increase in efficiency) was above, but I also
                            provide one more weak technical argument. Another possible (but pretty
                            unlikely now days) side effect of allowing such message mangling to
                            occur is that it could lead to backscatter if an intermediate server is
                            mis-configured. That is not my problem if it is 'properly' denied at
                            the door and not allowed (either direction) by my server.
                            </IMO>

                            That particular Postfix directive was created for some reason, so
                            somebody, somewhere must agree. Anyway, bottom line, it is my server.
                            I try to protect my small number of users from the outside world (and
                            themselves) as best I can. If they don't like my policy, they can find
                            another place to put their mail. Others may not be lucky enough to be
                            able to enforce such a policy, as the counter argument would be to find
                            a less rigid admin. ;-) What is 'acceptable' has to be determined on a
                            site by site basis. If it works for this site...great! If it doesn't,
                            then get rid of it.

                            I hope that came off as a constructive, alternative vantage point rather
                            than being argumentative. :-)

                            -- DJ Lucas


                            --
                            This message has been scanned for viruses and
                            dangerous content, and is believed to be clean.
                          • mouss
                            ... some services use the user address because they believe that they are acting on behalf of the user. examples include - send to a friend (postcard,
                            Message 13 of 25 , Dec 3, 2008
                              DJ Lucas a écrit :
                              > Noel Jones wrote:
                              >>
                              >> Very likely there are other, better ways to combat this spam. Look
                              >> for other traits you can use to reject it.
                              >>
                              > I am, by no means, anything even close to expert WRT the whole SMTP
                              > process, but, I do think that I can provide (or at least what I believe
                              > to be) a valid, albeit opinionated, counter argument. See below.
                              >> some things to look for:
                              >> - client listed on some RBL
                              >> - client name that looks dynamic
                              >> - using your domain or IP as HELO
                              >> - unusual headers
                              >> - body text unlikely to be found in legit mail
                              >>
                              >> If that doesn't help, consider adding SpamAssassin and/or ClamAV.
                              > From my POV, this one check saves me a small few (100, 200?) DNS/RBL
                              > lookups per month and a few CPU cycles by not getting to header checks,
                              > body checks, and finally SA (which is probably the most expensive check
                              > in the stack, followed immediately by virus scanning). I can probably
                              > parse my logs and give a real number, but it would seem insignificant to
                              > those running large servers. It is my _choice_ to be as efficient as
                              > possible.
                              >
                              > <IMO>
                              > Please correct me if I've made an invalid assumption (but do take notice
                              > of the "IMO" qualifier!)
                              >
                              > I can find absolutely no reason to inadvertently mislead, or worse,
                              > intentionally deceive the recipient by forging the envelope sender's
                              > address. In fact, the only reason I can see, is to intentionally
                              > deceive the recipient. Is there any other reason?

                              some services use the "user" address because they believe that they are
                              acting on behalf of the user. examples include

                              - "send to a friend" (postcard, article, ...), "invite a friend",
                              "sell/buy/offer...", ...

                              - interfaces to mailing lists such as nabble

                              - user posting via his ISP/hotel/.... relay.

                              - "classical" forwarding (.forward, aliases, ...)


                              SPF, DKIM and other anti-spam measures (such as the one discussed here)
                              are rendering these problematic. but you can't simply call this "poor
                              practice" or "deceptive practice".

                              so yes, you can establish a policy that states "nobody can use our
                              addresses in the envelope sender except from trusted networks or via
                              secure submission on port 587". but you must be aware of the
                              implications so that you can explain them to your users.

                              note that the envelope sender is not used to deceive the user, because
                              the user does not see it. it is generally used to fool "silly
                              whitelists" (some people whitelist their own domains, ...).

                              spammers who want to deceive the user forge the From: header.


                              > It is plain irresponsible, even if allowed by RFC. Even more so given
                              > that most (all?) mail clients will honor the from header and display it,
                              > in big, bright, flashy, bold text, in a prominent location for the end
                              > user to see (and reply to). Maybe I've missed something, but I really
                              > cannot find a good reason to allow it. Even the BlackBerry example
                              > given above is an example of poor practice in my opinion, but it can be
                              > an ALLOWed exception if it is out of your control.
                              >
                              > But that is all a matter of principal, not a technical reason. The
                              > technical reason (minor increase in efficiency) was above, but I also
                              > provide one more weak technical argument. Another possible (but pretty
                              > unlikely now days) side effect of allowing such message mangling to
                              > occur is that it could lead to backscatter if an intermediate server is
                              > mis-configured. That is not my problem if it is 'properly' denied at
                              > the door and not allowed (either direction) by my server.
                              > </IMO>
                              >


                              > That particular Postfix directive was created for some reason, so
                              > somebody, somewhere must agree. Anyway, bottom line, it is my server.
                              > I try to protect my small number of users from the outside world (and
                              > themselves) as best I can. If they don't like my policy, they can find
                              > another place to put their mail. Others may not be lucky enough to be
                              > able to enforce such a policy, as the counter argument would be to find
                              > a less rigid admin. ;-) What is 'acceptable' has to be determined on a
                              > site by site basis. If it works for this site...great! If it doesn't,
                              > then get rid of it.
                              >
                              > I hope that came off as a constructive, alternative vantage point rather
                              > than being argumentative. :-)
                              >
                            • Noel Jones
                              ... I agree with you. But the reality is that a large number of legit senders will use the recipient or some other valid user in your domain as the envelope
                              Message 14 of 25 , Dec 3, 2008
                                DJ Lucas wrote:
                                > Noel Jones wrote:
                                >>
                                >> Very likely there are other, better ways to combat this spam. Look
                                >> for other traits you can use to reject it.
                                >>
                                > I am, by no means, anything even close to expert WRT the whole SMTP
                                > process, but, I do think that I can provide (or at least what I believe
                                > to be) a valid, albeit opinionated, counter argument. See below.
                                >> some things to look for:
                                >> - client listed on some RBL
                                >> - client name that looks dynamic
                                >> - using your domain or IP as HELO
                                >> - unusual headers
                                >> - body text unlikely to be found in legit mail
                                >>
                                >> If that doesn't help, consider adding SpamAssassin and/or ClamAV.
                                > From my POV, this one check saves me a small few (100, 200?) DNS/RBL
                                > lookups per month and a few CPU cycles by not getting to header checks,
                                > body checks, and finally SA (which is probably the most expensive check
                                > in the stack, followed immediately by virus scanning). I can probably
                                > parse my logs and give a real number, but it would seem insignificant to
                                > those running large servers. It is my _choice_ to be as efficient as
                                > possible.
                                >
                                > <IMO>
                                > Please correct me if I've made an invalid assumption (but do take notice
                                > of the "IMO" qualifier!)
                                >
                                > I can find absolutely no reason to inadvertently mislead, or worse,
                                > intentionally deceive the recipient by forging the envelope sender's
                                > address. In fact, the only reason I can see, is to intentionally
                                > deceive the recipient. Is there any other reason?
                                > It is plain irresponsible, even if allowed by RFC. Even more so given
                                > that most (all?) mail clients will honor the from header and display it,
                                > in big, bright, flashy, bold text, in a prominent location for the end
                                > user to see (and reply to). Maybe I've missed something, but I really
                                > cannot find a good reason to allow it. Even the BlackBerry example
                                > given above is an example of poor practice in my opinion, but it can be
                                > an ALLOWed exception if it is out of your control.
                                >
                                > But that is all a matter of principal, not a technical reason. The
                                > technical reason (minor increase in efficiency) was above, but I also
                                > provide one more weak technical argument. Another possible (but pretty
                                > unlikely now days) side effect of allowing such message mangling to
                                > occur is that it could lead to backscatter if an intermediate server is
                                > mis-configured. That is not my problem if it is 'properly' denied at
                                > the door and not allowed (either direction) by my server.
                                > </IMO>
                                >

                                I agree with you.

                                But the reality is that a large number of legit senders will
                                use the recipient or some other valid user in your domain as
                                the envelope sender.

                                It's perfectly fine for you to have a policy that doesn't
                                allow this, but be aware that there are still some babies in
                                that bathwater.


                                > That particular Postfix directive was created for some reason, so
                                > somebody, somewhere must agree. Anyway, bottom line, it is my server.
                                > I try to protect my small number of users from the outside world (and
                                > themselves) as best I can. If they don't like my policy, they can find
                                > another place to put their mail. Others may not be lucky enough to be
                                > able to enforce such a policy, as the counter argument would be to find
                                > a less rigid admin. ;-) What is 'acceptable' has to be determined on a
                                > site by site basis. If it works for this site...great! If it doesn't,
                                > then get rid of it.

                                I agree completely, I just want you to understand the
                                implication of such a policy. It may work well for you, it
                                may not. Depends greatly on your users and how much
                                collateral damage they are collectively willing to accept, and
                                your authority to enforce such a policy.


                                >
                                > I hope that came off as a constructive, alternative vantage point rather
                                > than being argumentative. :-)
                                >
                                > -- DJ Lucas
                                >
                                >

                                Yes, that's what a discussion is all about.


                                --
                                Noel Jones
                              • LuKreme
                                ... Sure there is. First off, the envelope from is not FOR the user, it s for the mailserver. This address should always be where the physical delivery of
                                Message 15 of 25 , Dec 3, 2008
                                  On 2-Dec-2008, at 20:21, DJ Lucas wrote:
                                  > I can find absolutely no reason to inadvertently mislead, or worse,
                                  > intentionally deceive the recipient by forging the envelope sender's
                                  > address. In fact, the only reason I can see, is to intentionally
                                  > deceive the recipient. Is there any other reason?

                                  Sure there is. First off, the envelope from is not FOR the user, it's
                                  for the mailserver. This address should always be where the
                                  'physical' delivery of the message is originating. The From header is
                                  the PERSON that initiated the message. These are often the same, but
                                  not always.

                                  A perfect example is my mom sends out electronic cards from Jacquie
                                  Lawson<1> which arrive with headers like this:

                                  Return-Path: <cards@...>
                                  Received: from iport3.jacquielawson.com (iport3.jacquielawson.com
                                  [64.14.122.52])
                                  by mail.covisp.net (Postfix) with ESMTP id D4AD9118B83F
                                  for <kreme@...>; Thu, 27 Nov 2008 02:27:05 -0700 (MST)
                                  Date: Thu, 27 Nov 2008 04:27:02 -0500
                                  X-AG-MIPS: ag867
                                  Sender: <cards@...>
                                  From: **my mom**

                                  This is perfectly OK. In fact, this is exactly how this should be
                                  handled. This method is also used when someone is sending, for
                                  example, a petition request where they've 'signed' and want to let
                                  others know to sign also. Many pages (particularly political ones)
                                  have these sorts of "tell your friends" links and they to will use the
                                  person's email/name as the from and their own server info for the
                                  envelope. I would be far more likely to take a look at the FROM_ and
                                  compare it to the Received header than with the From: header, as I
                                  think that is far more likely to spot spam.

                                  Extending this to a physical letter situation it would be like Barack
                                  Obama's campaign sending me a letter that was signed by, say, my mom.
                                  She wrote the letter and signed it, but the campaign office mailed it
                                  in their own envelope. Seems fine to me.

                                  > If they don't like my policy, they can find another place to put
                                  > their mail. Others may not be lucky enough to be able to enforce
                                  > such a policy, as the counter argument would be to find a less rigid
                                  > admin. ;-) What is 'acceptable' has to be determined on a site by
                                  > site basis. If it works for this site...great! If it doesn't, then
                                  > get rid of it.

                                  Just so you know that there are common and legitimate uses for this,
                                  and that you will lose valid emails that, presumably, your users
                                  actually want. And if you are rejecting them, do your users know they
                                  are missing those emails? I mean, are they informed enough that they
                                  can make a real choice about getting MOST of their email from you or
                                  getting ALL of their email from someone else?

                                  <1> I have no connection with Jacquie Lawson. I'm not even a
                                  customer, I am merely a recipient. I do like the cards though.

                                  --
                                  <[TN]FBMachine> i got kicked out of Barnes and Noble once for
                                  moving all the bibles into the fiction section
                                • J.P. Trosclair
                                  ... I don t see how this particular case would be affected. The only forged part was in the header that I can see from your example, not the actual MAIL FROM
                                  Message 16 of 25 , Dec 3, 2008
                                    LuKreme wrote:
                                    > On 2-Dec-2008, at 20:21, DJ Lucas wrote:
                                    >> I can find absolutely no reason to inadvertently mislead, or worse,
                                    >> intentionally deceive the recipient by forging the envelope sender's
                                    >> address. In fact, the only reason I can see, is to intentionally
                                    >> deceive the recipient. Is there any other reason?
                                    >
                                    > Sure there is. First off, the envelope from is not FOR the user, it's
                                    > for the mailserver. This address should always be where the
                                    > 'physical' delivery of the message is originating. The From header is
                                    > the PERSON that initiated the message. These are often the same, but
                                    > not always.
                                    >
                                    > A perfect example is my mom sends out electronic cards from Jacquie
                                    > Lawson<1> which arrive with headers like this:
                                    >
                                    > Return-Path: <cards@...>
                                    > Received: from iport3.jacquielawson.com (iport3.jacquielawson.com
                                    > [64.14.122.52])
                                    > by mail.covisp.net (Postfix) with ESMTP id D4AD9118B83F
                                    > for <kreme@...>; Thu, 27 Nov 2008 02:27:05 -0700 (MST)
                                    > Date: Thu, 27 Nov 2008 04:27:02 -0500
                                    > X-AG-MIPS: ag867
                                    > Sender: <cards@...>
                                    > From: **my mom**
                                    >

                                    I don't see how this particular case would be affected. The only
                                    "forged" part was in the header that I can see from your example, not
                                    the actual MAIL FROM during the initial part of the SMTP conversation.

                                    Currently I have our configuration set to reject mail claiming a MAIL
                                    FROM that originates in our domain if the session has not been
                                    authenticated or coming from the local network.

                                    Example where MAIL FROM is not forged, but From part of header is:
                                    $ telnet mail1.omitted_for_privacy.com 25
                                    Trying x.x.x.x...
                                    Connected to mail1.omitted_for_privacy.com.
                                    Escape character is '^]'.
                                    220 mail1.omitted_for_privacy.com ESMTP
                                    EHLO omitted_for_privacy.com
                                    250-mail1.omitted_for_privacy.com
                                    250-PIPELINING
                                    250-SIZE 2147483647
                                    250-ETRN
                                    250-STARTTLS
                                    250-AUTH LOGIN PLAIN
                                    250-AUTH=LOGIN PLAIN
                                    250-ENHANCEDSTATUSCODES
                                    250-8BITMIME
                                    250 DSN
                                    MAIL FROM:jptrosclair@omitted_for_privacy_totally_different_domain.com
                                    250 2.1.0 Ok
                                    RCPT TO:jptrosclair@omitted_for_privacy.com
                                    250 2.1.5 Ok
                                    DATA
                                    354 End data with <CR><LF>.<CR><LF>
                                    From: jptrosclair@omitted_for_privacy.com
                                    Subject: proof that only the mail from portion is rejected
                                    This email should be accepted by our mail server
                                    .
                                    250 2.0.0 Ok: queued as 241056A006F
                                    QUIT
                                    221 2.0.0 Bye
                                    Connection closed by foreign host.

                                    Example where MAIL FROM is forged:
                                    $ telnet mail1.omitted_for_privacy.com 25
                                    Trying 12.48.244.4...
                                    Connected to mail1.omitted_for_privacy.com.
                                    Escape character is '^]'.
                                    220 mail1.omitted_for_privacy.com ESMTP
                                    EHLO judelawfirm.com
                                    250-mail1.omitted_for_privacy.com
                                    250-PIPELINING
                                    250-SIZE 2147483647
                                    250-ETRN
                                    250-STARTTLS
                                    250-AUTH LOGIN PLAIN
                                    250-AUTH=LOGIN PLAIN
                                    250-ENHANCEDSTATUSCODES
                                    250-8BITMIME
                                    250 DSN
                                    MAIL FROM:jptrosclair@omitted_for_privacy.com
                                    250 2.1.0 Ok
                                    RCPT TO:jptrosclair@omitted_for_privacy.com
                                    554 5.7.1 <jptrosclair@omitted_for_privacy.com>: Sender address
                                    rejected: Not authenticated
                                    QUIT
                                    221 2.0.0 Bye
                                    Connection closed by foreign host.


                                    > This is perfectly OK. In fact, this is exactly how this should be
                                    > handled.

                                    I agree completely, I do not think it's OK to forge the MAIL FROM
                                    portion of the SMTP conversation though. I think this is what DJ Lucas
                                    was getting at.

                                    > This method is also used when someone is sending, for
                                    > example, a petition request where they've 'signed' and want to let
                                    > others know to sign also. Many pages (particularly political ones)
                                    > have these sorts of "tell your friends" links and they to will use the
                                    > person's email/name as the from and their own server info for the
                                    > envelope. I would be far more likely to take a look at the FROM_ and
                                    > compare it to the Received header than with the From: header, as I
                                    > think that is far more likely to spot spam.
                                    >
                                    > Extending this to a physical letter situation it would be like Barack
                                    > Obama's campaign sending me a letter that was signed by, say, my mom.
                                    > She wrote the letter and signed it, but the campaign office mailed it
                                    > in their own envelope. Seems fine to me.
                                    >
                                    >> If they don't like my policy, they can find another place to put
                                    >> their mail. Others may not be lucky enough to be able to enforce
                                    >> such a policy, as the counter argument would be to find a less rigid
                                    >> admin. ;-) What is 'acceptable' has to be determined on a site by
                                    >> site basis. If it works for this site...great! If it doesn't, then
                                    >> get rid of it.
                                    >
                                    > Just so you know that there are common and legitimate uses for this,
                                    > and that you will lose valid emails that, presumably, your users
                                    > actually want. And if you are rejecting them, do your users know they
                                    > are missing those emails? I mean, are they informed enough that they
                                    > can make a real choice about getting MOST of their email from you or
                                    > getting ALL of their email from someone else?
                                    >
                                    > <1> I have no connection with Jacquie Lawson. I'm not even a
                                    > customer, I am merely a recipient. I do like the cards though.
                                    >

                                    At this point I think there is some confusion about what is being stated
                                    is acceptable and what is not.
                                  • DJ Lucas
                                    ... No there isn t. AFAIK, unless I m misunderstanding something, the rest of your message simply puts what I said above in different terms and agrees
                                    Message 17 of 25 , Dec 3, 2008
                                      LuKreme wrote:
                                      > On 2-Dec-2008, at 20:21, DJ Lucas wrote:
                                      >> I can find absolutely no reason to inadvertently mislead, or worse,
                                      >> intentionally deceive the recipient by forging the envelope sender's
                                      >> address. In fact, the only reason I can see, is
                                      >> to intentionally deceive the recipient. Is there any other reason?
                                      >
                                      > Sure there is.

                                      No there isn't. AFAIK, unless I'm misunderstanding something, the rest
                                      of your message simply puts what I said above in different terms and
                                      agrees entirely. **my mom** was in the From header...nowhere else.
                                      The From header can be changed up to say that it came from somebody
                                      else. I don't care about that. The check in question is in the smtp
                                      transaction, not the data.

                                      -- DJ Lucas


                                      --
                                      This message has been scanned for viruses and
                                      dangerous content, and is believed to be clean.
                                    • mouss
                                      ... Yes. there is;-p can we agree to disagree or do we need to contact the UNO?
                                      Message 18 of 25 , Dec 3, 2008
                                        DJ Lucas a écrit :
                                        > LuKreme wrote:
                                        >> On 2-Dec-2008, at 20:21, DJ Lucas wrote:
                                        >>> I can find absolutely no reason to inadvertently mislead, or worse,
                                        >>> intentionally deceive the recipient by forging the envelope sender's
                                        >>> address. In fact, the only reason I can see, is
                                        >>> to intentionally deceive the recipient. Is there any other reason?
                                        >> Sure there is.
                                        >
                                        > No there isn't.

                                        Yes. there is;-p can we agree to disagree or do we need to contact the UNO?

                                        > AFAIK, unless I'm misunderstanding something, the rest
                                        > of your message simply puts what I said above in different terms and
                                        > agrees entirely. **my mom** was in the From header...nowhere else.
                                        > The From header can be changed up to say that it came from somebody
                                        > else. I don't care about that. The check in question is in the smtp
                                        > transaction, not the data.
                                        >
                                        > -- DJ Lucas
                                        >
                                        >
                                      • Roman Medina-Heigl Hernandez
                                        ... Since I m using Cyrus LMTP, I don t have the path to mailbox variable, so I could return whatever in $virtual_mailbox_maps. What I did was to return the
                                        Message 19 of 25 , Dec 4, 2008
                                          mouss escribió:
                                          > Roman Medina-Heigl Hernandez a écrit :
                                          >>> Why is the mail not being rejected due to
                                          >>> reject_unauthenticated_sender_login_mismatch? I must have a silly bug but I
                                          >>> couldn't find it... :-(
                                          >> I got to solve it by:
                                          >> smtpd_sender_login_maps = $virtual_mailbox_maps
                                          >>
                                          >
                                          > do not reuse maps this way. use a script to generate each map instead
                                          > (or use
                                          >
                                          > note that smtpd_sender_login_maps returns one or more logins, while
                                          > virtual_mailbox_maps returns the path to the mailbox.

                                          Since I'm using Cyrus LMTP, I don't have the "path to mailbox" variable, so
                                          I could return whatever in $virtual_mailbox_maps. What I did was to return
                                          the email address (which in turn corresponds to the SASL login).

                                          So now it's perfectly "compatible" to use the same Mysql map for both
                                          variables. I mean:

                                          hsnew:/etc/postfix# cat /etc/postfix/vuser.mysql
                                          # Virtual users (Mysql)
                                          hosts = unix:/var/run/mysqld/mysqld.sock
                                          user = postfix
                                          password = xxxxxxxxxx
                                          dbname = postfix
                                          query = select user from user where user = '%s'

                                          And in main.cf:
                                          virtual_mailbox_maps = mysql:/etc/postfix/vuser.mysql
                                          smtpd_sender_login_maps = mysql:/etc/postfix/vuser.mysql

                                          Ok now? :-)

                                          Cheers,
                                          -r
                                        • LuKreme
                                          ... Ah, I thought you were complaining about mismatches in the From_ and the From: Yes, we agree entirely. -- Dinosaurs are attacking! Throw a
                                          Message 20 of 25 , Dec 4, 2008
                                            On 3-Dec-2008, at 15:44, DJ Lucas wrote:
                                            > LuKreme wrote:
                                            >> On 2-Dec-2008, at 20:21, DJ Lucas wrote:
                                            >>> I can find absolutely no reason to inadvertently mislead, or worse,
                                            >>> intentionally deceive the recipient by forging the envelope sender's
                                            >>> address. In fact, the only reason I can see, is
                                            >>> to intentionally deceive the recipient. Is there any other reason?
                                            >>
                                            >> Sure there is.
                                            >
                                            > No there isn't. AFAIK, unless I'm misunderstanding something, the
                                            > rest
                                            > of your message simply puts what I said above in different terms and
                                            > agrees entirely. **my mom** was in the From header...nowhere else.
                                            > The From header can be changed up to say that it came from somebody
                                            > else. I don't care about that. The check in question is in the smtp
                                            > transaction, not the data.

                                            Ah, I thought you were complaining about mismatches in the From_ and
                                            the From:

                                            <rereading>

                                            Yes, we agree entirely.

                                            --
                                            Dinosaurs are attacking! Throw a barrel!
                                          • LuKreme
                                            ... Maybe. The FROM_ (the envelope from, the SMTP transaction from, etc) should always be the actual source of the message. If acme.tld is sending a message
                                            Message 21 of 25 , Dec 4, 2008
                                              On 3-Dec-2008, at 16:53, mouss wrote:
                                              > DJ Lucas a écrit :
                                              >> LuKreme wrote:
                                              >>> On 2-Dec-2008, at 20:21, DJ Lucas wrote:
                                              >>>> I can find absolutely no reason to inadvertently mislead, or worse,
                                              >>>> intentionally deceive the recipient by forging the envelope
                                              >>>> sender's
                                              >>>> address. In fact, the only reason I can see, is
                                              >>>> to intentionally deceive the recipient. Is there any other reason?
                                              >>> Sure there is.
                                              >>
                                              >> No there isn't.
                                              >
                                              > Yes. there is;-p can we agree to disagree or do we need to contact
                                              > the UNO?

                                              Maybe.

                                              The FROM_ (the envelope from, the SMTP transaction from, etc) should
                                              always be the actual source of the message. If acme.tld is sending a
                                              message on behalf of mom@... then the FROM_ has to be
                                              acme.tld. The From: should be mom@.... there is no reason to
                                              lie in the SMTP transaction about who you are, and spoofing that is
                                              going to be a spam-tag to many servers.

                                              I touched on this in a previous message, the FROM_ and the Received
                                              headers should match up in some way, even if 'matched up' is simply an
                                              SPF match for the FROM_


                                              --
                                              Well I've seen the Heart of Darkness/Read the writing on the
                                              wall/an the voice out in the desert/Was the voice out in the
                                              hall
                                            • mouss
                                              ... I guessed that, but still... see below. ... yes it s better! now if a new admin has to replace you, he won t get mad trying to figure out what s really
                                              Message 22 of 25 , Dec 4, 2008
                                                Roman Medina-Heigl Hernandez a écrit :
                                                > mouss escribió:
                                                >> Roman Medina-Heigl Hernandez a écrit :
                                                >>>> Why is the mail not being rejected due to
                                                >>>> reject_unauthenticated_sender_login_mismatch? I must have a silly bug but I
                                                >>>> couldn't find it... :-(
                                                >>> I got to solve it by:
                                                >>> smtpd_sender_login_maps = $virtual_mailbox_maps
                                                >>>
                                                >> do not reuse maps this way. use a script to generate each map instead
                                                >> (or use
                                                >>
                                                >> note that smtpd_sender_login_maps returns one or more logins, while
                                                >> virtual_mailbox_maps returns the path to the mailbox.
                                                >
                                                > Since I'm using Cyrus LMTP, I don't have the "path to mailbox" variable, so
                                                > I could return whatever in $virtual_mailbox_maps. What I did was to return
                                                > the email address (which in turn corresponds to the SASL login).
                                                >

                                                I guessed that, but still... see below.

                                                > So now it's perfectly "compatible" to use the same Mysql map for both
                                                > variables. I mean:
                                                >
                                                > hsnew:/etc/postfix# cat /etc/postfix/vuser.mysql
                                                > # Virtual users (Mysql)
                                                > hosts = unix:/var/run/mysqld/mysqld.sock
                                                > user = postfix
                                                > password = xxxxxxxxxx
                                                > dbname = postfix
                                                > query = select user from user where user = '%s'
                                                >
                                                > And in main.cf:
                                                > virtual_mailbox_maps = mysql:/etc/postfix/vuser.mysql
                                                > smtpd_sender_login_maps = mysql:/etc/postfix/vuser.mysql
                                                >
                                                > Ok now? :-)
                                                >

                                                yes it's better! now if a new admin has to replace you, he won't get mad
                                                trying to figure out what's really configured :)
                                              Your message has been successfully submitted and would be delivered to recipients shortly.