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

Re: Avoiding (trivial) spoofed "mail from"

Expand Messages
  • 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 1 of 25 , Dec 1, 2008
    • 0 Attachment
      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 2 of 25 , Dec 1, 2008
      • 0 Attachment
        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 3 of 25 , Dec 1, 2008
        • 0 Attachment
          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 4 of 25 , Dec 1, 2008
          • 0 Attachment
            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 5 of 25 , Dec 2, 2008
            • 0 Attachment
              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 6 of 25 , Dec 2, 2008
              • 0 Attachment
                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 7 of 25 , Dec 2, 2008
                • 0 Attachment
                  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 8 of 25 , Dec 2, 2008
                  • 0 Attachment
                    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 9 of 25 , Dec 2, 2008
                    • 0 Attachment
                      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 10 of 25 , Dec 2, 2008
                      • 0 Attachment
                        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 11 of 25 , Dec 2, 2008
                        • 0 Attachment
                          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 12 of 25 , Dec 3, 2008
                          • 0 Attachment
                            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 13 of 25 , Dec 3, 2008
                            • 0 Attachment
                              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 14 of 25 , Dec 3, 2008
                              • 0 Attachment
                                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 15 of 25 , Dec 3, 2008
                                • 0 Attachment
                                  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 16 of 25 , Dec 3, 2008
                                  • 0 Attachment
                                    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 17 of 25 , Dec 3, 2008
                                    • 0 Attachment
                                      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 18 of 25 , Dec 4, 2008
                                      • 0 Attachment
                                        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 19 of 25 , Dec 4, 2008
                                        • 0 Attachment
                                          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 20 of 25 , Dec 4, 2008
                                          • 0 Attachment
                                            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 21 of 25 , Dec 4, 2008
                                            • 0 Attachment
                                              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.