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

Re: Avoiding (trivial) spoofed "mail from"

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

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

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

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

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

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

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

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


      --
      Noel Jones
    • Roman Medina-Heigl Hernandez
      ... So there is no other way to do this without having to duplicate the same/similar hash file (/etc/postfix/vdomain and /etc/postfix/mydomains). I thought
      Message 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 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. 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 19 of 25 , Dec 3, 2008
                                        • 0 Attachment
                                          LuKreme wrote:
                                          > On 2-Dec-2008, at 20:21, DJ Lucas wrote:
                                          >> I can find absolutely no reason to inadvertently mislead, or worse,
                                          >> intentionally deceive the recipient by forging the envelope sender's
                                          >> address. In fact, the only reason I can see, is
                                          >> to intentionally deceive the recipient. Is there any other reason?
                                          >
                                          > Sure there is.

                                          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 20 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 21 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 22 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 23 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 24 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.