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

Avoiding (trivial) spoofed "mail from"

Expand Messages
  • Roman Medina-Heigl Hernandez
    Hello, Spammers often send (forged) mail where mail from address is the same as rcpt to address. An extension of that could be using a mail from address
    Message 1 of 25 , Dec 1, 2008
    • 0 Attachment
      Hello,

      Spammers often send (forged) mail where "mail from" address is the same as
      "rcpt to" address. An extension of that could be using a "mail from"
      address where src domain is one of our valid virtual domains. I can only
      think of 3 cases:
      1) Src IP is 127.0.0.1 -> Mail should pass (eg: sent by webmail, installed
      on the same MTA host).
      2) Authenticated sender -> Legit users authenticated by SASL -> Should pass
      3) All the rest -> Should be rejected (SPAM) (assuming a simple single-MTA
      config, where MX -receiving mail server- is the same as MTA -outbound
      sending mail server-)

      Which is the best/preferred Postfix config to filter out that kind of spam?

      I have all my valid domains in:
      virtual_mailbox_domains = hash:/etc/postfix/vdomain

      The current format of /etc/postfix/vdomain is:
      domain1 whatever
      domain2 whatever

      So perhaps I could do somthing like:
      smtpd_sender_restrictions =
      smtpd_recipient_restrictions =
      permit_mynetworks,
      reject_unauth_destination,
      XXXXX,
      permit

      where XXXX could be some kind of "check_sender_access" clausule, rejecting
      domains listed in $virtual_mailbox_domains. How could I implement this? Is
      there any other preferred solution?

      Another idea could be setting a SPF record for my domains and then some
      kind of SPF checks (how could I do that?). I know it is a must but I'd
      prefer to leave the SPF setup for the next stage (I'd like to deeply review
      all pros/cons, ~all vs ?all, etc).

      Cheers,
      -Roman
    • Noel Jones
      ... Yes, you can use a map for this; XXXX above = check_sender_access hash:/etc/postfix/mydomains # mydomains example.com REJECT inside sender not allowed
      Message 2 of 25 , Dec 1, 2008
      • 0 Attachment
        Roman Medina-Heigl Hernandez wrote:
        > Hello,
        >
        > Spammers often send (forged) mail where "mail from" address is the same as
        > "rcpt to" address. An extension of that could be using a "mail from"
        > address where src domain is one of our valid virtual domains. I can only
        > think of 3 cases:
        > 1) Src IP is 127.0.0.1 -> Mail should pass (eg: sent by webmail, installed
        > on the same MTA host).
        > 2) Authenticated sender -> Legit users authenticated by SASL -> Should pass
        > 3) All the rest -> Should be rejected (SPAM) (assuming a simple single-MTA
        > config, where MX -receiving mail server- is the same as MTA -outbound
        > sending mail server-)
        >
        > Which is the best/preferred Postfix config to filter out that kind of spam?
        >
        > I have all my valid domains in:
        > virtual_mailbox_domains = hash:/etc/postfix/vdomain
        >
        > The current format of /etc/postfix/vdomain is:
        > domain1 whatever
        > domain2 whatever
        >
        > So perhaps I could do somthing like:
        > smtpd_sender_restrictions =
        > smtpd_recipient_restrictions =
        > permit_mynetworks,
        > reject_unauth_destination,
        > XXXXX,
        > permit
        >
        > where XXXX could be some kind of "check_sender_access" clausule, rejecting
        > domains listed in $virtual_mailbox_domains. How could I implement this? Is
        > there any other preferred solution?

        Yes, you can use a map for this;
        XXXX above =
        check_sender_access hash:/etc/postfix/mydomains

        # mydomains
        example.com REJECT inside sender not allowed
        example.net REJECT inside sender not allowed
        ...

        Note this will reject some legit mail. Spamassassin is
        probably a better choice for filtering this type mail.

        >
        > Another idea could be setting a SPF record for my domains and then some
        > kind of SPF checks (how could I do that?). I know it is a must but I'd
        > prefer to leave the SPF setup for the next stage (I'd like to deeply review
        > all pros/cons, ~all vs ?all, etc).

        Yes, SPF will help this, but if you reject mail that fails SPF
        checks you will have the same false positives as the above
        solution.
        Adding SPF to your domain is simply publishing a couple extra
        DNS records, very simple to add.
        http://www.openspf.org/

        Checking SPF records in postfix requires a policy service.
        There are several for postfix listed under
        http://www.openspf.org/Implementations#mta-extensions

        Also, if you have a recent version of postfix you can use any
        milter that supports SPF. Many of them have additional features.


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

          So there is no other way to do this without having to "duplicate" the
          same/similar hash file (/etc/postfix/vdomain and /etc/postfix/mydomains). I
          thought perhaps it could exist some directive of the form:
          reject_mydestination_domain_sender or something similar to avoid
          duplicating domain databases ;-)).

          > Note this will reject some legit mail. Spamassassin is probably a

          Could you elaborate on that legit mail cases? Examples? It's very important
          for me and I couldn't figure any legit cases (apart from the ones I already
          mentioned).

          > better choice for filtering this type mail.

          If I use spamassasing for this, I have to supply my vdomains to
          spamassassin. Currently, I implemented a quick have in Amavis, so all
          domains are treated as local:
          @local_domains_acl = qw( . );
          My Amavis/spamassasing setup is not filtering at all; it is only used for
          marking/scoring (adding headers to) mails (filtering is performed via
          Sieve, based on X-Spam-*/X-Amavis-* Headers).

          > http://www.openspf.org/

          As I said, SPF is plannified for next stage, and I'll have a look to
          different resources (thanks for your notes!!).

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

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


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

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

            --
            Noel Jones
          • Roman Medina-Heigl Hernandez
            ... Or I could use two different mysql queries, over the same table containing the vdomains... ... Yes, you re right (I trust you! :-)). I did a quick search
            Message 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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 21 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 22 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 23 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 24 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 25 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.