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

Re: Avoiding (trivial) spoofed "mail from"

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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.