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

Re: Avoiding (trivial) spoofed "mail from"

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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 21 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 22 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 23 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.