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

Opportunistic TLS vs. plain

Expand Messages
  • Stefan Foerster
    Hello world, our current situation is as follows: 1. Public MX, very low incoming volume, smtpd_tls_security_level = may 2. Senders aren t known beforehand,
    Message 1 of 17 , Jun 21, 2014
    • 0 Attachment
      Hello world,

      our current situation is as follows:

      1. Public MX, very low incoming volume, "smtpd_tls_security_level = may"
      2. Senders aren't known beforehand, i.e. no previous business relationship.
      3. Senders' IT usually doesn't support DANE.
      4. Incoming mail is considered highly(!) valuable to business.

      During a security audit, it was determined that the MX supported what
      the auditors called "weak" ciphers and protocols (SSLv3, TLSv1.0,
      RC4-MD5, anonymous ciphers and so on). The auditors demanded that we
      disable all those - not considering the fact that our Postifx _did_
      assing a higher priority to "more secure" ciphers.

      Not surprisingly, a lot of sending systems failed back to plain text
      after we pushed the change to production.

      Could someone share experience with or point me to some kind of "best
      practices" regarding opportunistic TLS, or explain the reasoning for
      banning "weak" ciphers/protocols on a public MX? (again, not talking
      about a MSA, or a third party that we have ties with, which would allow
      us to nail down protocols/ciphers with TLS policy maps)


      Thanks
      Stefan
    • lists@rhsoft.net
      ... fire the clueless auditor not in the position to demand anything while lacking basics himself and not able to make a difference between HTTP and SMTP -
      Message 2 of 17 , Jun 21, 2014
      • 0 Attachment
        Am 21.06.2014 13:11, schrieb Stefan Foerster:
        > our current situation is as follows:
        >
        > 1. Public MX, very low incoming volume, "smtpd_tls_security_level = may"
        > 2. Senders aren't known beforehand, i.e. no previous business relationship.
        > 3. Senders' IT usually doesn't support DANE.
        > 4. Incoming mail is considered highly(!) valuable to business.
        >
        > During a security audit, it was determined that the MX supported what
        > the auditors called "weak" ciphers and protocols (SSLv3, TLSv1.0,
        > RC4-MD5, anonymous ciphers and so on). The auditors demanded that we
        > disable all those - not considering the fact that our Postifx _did_
        > assing a higher priority to "more secure" ciphers.
        >
        > Not surprisingly, a lot of sending systems failed back to plain text
        > after we pushed the change to production.
        >
        > Could someone share experience with or point me to some kind of "best
        > practices" regarding opportunistic TLS, or explain the reasoning for
        > banning "weak" ciphers/protocols on a public MX? (again, not talking
        > about a MSA, or a third party that we have ties with, which would allow
        > us to nail down protocols/ciphers with TLS policy maps)

        fire the clueless auditor not in the position to demand anything while
        lacking basics himself and not able to make a difference between
        HTTP and SMTP - what such people not understand is that HTTPS
        don't fall back to plaintext - SMTP does
      • Stefan Foerster
        ... While I certainly share your view on this - though I would have worded it less strongly - my question still stands: Does anyone have real world data to
        Message 3 of 17 , Jun 21, 2014
        • 0 Attachment
          * "lists@..." <lists@...>:
          > Am 21.06.2014 13:11, schrieb Stefan Foerster:
          > > Could someone share experience with or point me to some kind of "best
          > > practices" regarding opportunistic TLS, or explain the reasoning for
          > > banning "weak" ciphers/protocols on a public MX? (again, not talking
          > > about a MSA, or a third party that we have ties with, which would allow
          > > us to nail down protocols/ciphers with TLS policy maps)
          >
          > fire the clueless auditor not in the position to demand anything while
          > lacking basics himself and not able to make a difference between
          > HTTP and SMTP - what such people not understand is that HTTPS
          > don't fall back to plaintext - SMTP does

          While I certainly share your view on this - though I would have worded
          it less strongly - my question still stands: Does anyone have real world
          data to share (e.g. "we disabled ciphers X, Y and Z and then N percent
          of clients failed back to plain"), or a pointer to some (semi-)official
          documentation, scientific papers or the like about this?


          Cheers
          Stefan
        • Jose Borges Ferreira
          ... Totally agree. Just like to add also, on a public MX, there is no human intervention to decide if transaction should go or not. One arguable issue is if we
          Message 4 of 17 , Jun 21, 2014
          • 0 Attachment
            On Sat, Jun 21, 2014 at 12:21 PM, lists@... <lists@...> wrote:
            >
            >
            > Am 21.06.2014 13:11, schrieb Stefan Foerster:
            >> our current situation is as follows:
            >>
            >> 1. Public MX, very low incoming volume, "smtpd_tls_security_level = may"
            >> 2. Senders aren't known beforehand, i.e. no previous business relationship.
            >> 3. Senders' IT usually doesn't support DANE.
            >> 4. Incoming mail is considered highly(!) valuable to business.
            >>
            >> During a security audit, it was determined that the MX supported what
            >> the auditors called "weak" ciphers and protocols (SSLv3, TLSv1.0,
            >> RC4-MD5, anonymous ciphers and so on). The auditors demanded that we
            >> disable all those - not considering the fact that our Postifx _did_
            >> assing a higher priority to "more secure" ciphers.
            >>
            >> Not surprisingly, a lot of sending systems failed back to plain text
            >> after we pushed the change to production.
            >>
            >> Could someone share experience with or point me to some kind of "best
            >> practices" regarding opportunistic TLS, or explain the reasoning for
            >> banning "weak" ciphers/protocols on a public MX? (again, not talking
            >> about a MSA, or a third party that we have ties with, which would allow
            >> us to nail down protocols/ciphers with TLS policy maps)
            >
            > fire the clueless auditor not in the position to demand anything while
            > lacking basics himself and not able to make a difference between
            > HTTP and SMTP - what such people not understand is that HTTPS
            > don't fall back to plaintext - SMTP does

            Totally agree. Just like to add also, on a public MX, there is no
            human intervention to decide if transaction should go or not.

            One arguable issue is if we keep supporting weak ciphers, there is no
            incentive to people to upgrade. Right now I prefer weak ciphers to
            plaintext.

            So unless you have a critical data exchanged with some domains then
            you should go for end to end encryption or setup your postfix
            instances to only send and received with strong/strict ciphers.

            José Borges Ferreira
          • Jose Borges Ferreira
            On Sat, Jun 21, 2014 at 12:45 PM, Stefan Foerster ... Can check both Google and Facebook findings. http://www.google.com/transparencyreport/saferemail/
            Message 5 of 17 , Jun 21, 2014
            • 0 Attachment
              On Sat, Jun 21, 2014 at 12:45 PM, Stefan Foerster
              <cite+postfix-users@...> wrote:
              > While I certainly share your view on this - though I would have worded
              > it less strongly - my question still stands: Does anyone have real world
              > data to share (e.g. "we disabled ciphers X, Y and Z and then N percent
              > of clients failed back to plain"), or a pointer to some (semi-)official
              > documentation, scientific papers or the like about this?

              Can check both Google and Facebook findings.

              http://www.google.com/transparencyreport/saferemail/

              https://www.facebook.com/notes/protect-the-graph/the-current-state-of-smtp-starttls-deployment/1453015901605223
              (facebook account required)

              José Borges Ferreira
            • Martin Vegter
              ... while not directly related to your question, I have an experience which touches this topic. Not long ago, I have decided I will require TLS on my private
              Message 6 of 17 , Jun 21, 2014
              • 0 Attachment
                > On 06/21/2014 01:11 PM, Stefan Foerster wrote:
                >
                > our current situation is as follows:
                >
                > 1. Public MX, very low incoming volume, "smtpd_tls_security_level = may"
                > 2. Senders aren't known beforehand, i.e. no previous business relationship.
                > 3. Senders' IT usually doesn't support DANE.
                > 4. Incoming mail is considered highly(!) valuable to business.
                >

                while not directly related to your question, I have an experience which
                touches this topic. Not long ago, I have decided I will require TLS on
                my private postfix server, so I have set:

                smtpd_tls_security_level = encrypt

                I expected that 99% of all servers supports TLS anyway (and I was
                willing to risk the 1%). How surprised was I when my server refused
                emails from Paypal, because Paypal does not (want to?) use TLS. I had to
                revert back to "may".

                Martin
              • Viktor Dukhovni
                ... A my previous employer a clueless checklist zombie auditor tried to pull the same trick. Though it took much spine, the postmaster who succeeded me
                Message 7 of 17 , Jun 21, 2014
                • 0 Attachment
                  On Sat, Jun 21, 2014 at 01:11:04PM +0200, Stefan Foerster wrote:

                  > During a security audit, it was determined that the MX supported what
                  > the auditors called "weak" ciphers and protocols (SSLv3, TLSv1.0,
                  > RC4-MD5, anonymous ciphers and so on). The auditors demanded that we
                  > disable all those - not considering the fact that our Postifx _did_
                  > assing a higher priority to "more secure" ciphers.
                  >
                  > Not surprisingly, a lot of sending systems failed back to plain text
                  > after we pushed the change to production.

                  A my previous employer a clueless checklist zombie auditor tried
                  to pull the same trick. Though it took much spine, the postmaster
                  who succeeded me managed to convince management that the auditor
                  was wrong, and no settings were changed.

                  --
                  Viktor.
                • grantksupport@...
                  ... I ve been trying to follow this, and related threads, as well as reading @ Postfix http://www.postfix.org/TLS_README.html#server_cipher
                  Message 8 of 17 , Jun 21, 2014
                  • 0 Attachment
                    On Sat, Jun 21, 2014, at 10:07 AM, Viktor Dukhovni wrote:
                    > > During a security audit, it was determined that the MX supported what
                    > > the auditors called "weak" ciphers and protocols (SSLv3, TLSv1.0,
                    > > RC4-MD5, anonymous ciphers and so on). The auditors demanded that we
                    > > disable all those - not considering the fact that our Postifx _did_
                    > > assing a higher priority to "more secure" ciphers.
                    > >
                    > > Not surprisingly, a lot of sending systems failed back to plain text
                    > > after we pushed the change to production.
                    >
                    > A my previous employer a clueless checklist zombie auditor tried
                    > to pull the same trick. Though it took much spine, the postmaster
                    > who succeeded me managed to convince management that the auditor
                    > was wrong, and no settings were changed.

                    I've been trying to follow this, and related threads, as well as reading
                    @ Postfix

                    http://www.postfix.org/TLS_README.html#server_cipher
                    http://www.postfix.org/FORWARD_SECRECY_README.html

                    and poking around at

                    http://sendgrid.com/blog/sendgrid-and-the-future-of-email-security/
                    http://checktls.com/

                    I think I see the variety of options, and understand some of the
                    pitfalls, as discussed, but TBH am a bit lost as to what the 'best
                    practices' *recommendation* for the cipher list to use is? specifically
                    for a PFS-capable Postfix server, with as-robust-as-possible fallback to
                    secured traffic, even if weak-cipher encrypted.

                    If there's a "given these discussions, do this" doc or thread that
                    someone can kindly point to, or simply state here in-thread, I'd
                    appreciate it. Just looking for some 'distillation' ...

                    Thanks,

                    Grant
                  • Viktor Dukhovni
                    ... The *default* Postfix TLS cipherlist settings are chosen with care. Best pracice is to leave them as-is. See also:
                    Message 9 of 17 , Jun 21, 2014
                    • 0 Attachment
                      On Sat, Jun 21, 2014 at 10:26:41AM -0700, grantksupport@... wrote:

                      > I think I see the variety of options, and understand some of the
                      > pitfalls, as discussed, but TBH am a bit lost as to what the 'best
                      > practices' *recommendation* for the cipher list to use is? specifically
                      > for a PFS-capable Postfix server, with as-robust-as-possible fallback to
                      > secured traffic, even if weak-cipher encrypted.

                      The *default* Postfix TLS cipherlist settings are chosen with care.
                      Best pracice is to leave them as-is.

                      See also:

                      http://www.postfix.org/FORWARD_SECRECY_README.html

                      --
                      Viktor.
                    • grantksupport@...
                      hi ... Right. That s one of the specific documents I d already referenced as having read in my OP. It s thorough, and to me, confusing. Which is exactly why
                      Message 10 of 17 , Jun 21, 2014
                      • 0 Attachment
                        hi

                        On Sat, Jun 21, 2014, at 10:36 AM, Viktor Dukhovni wrote:
                        > The *default* Postfix TLS cipherlist settings are chosen with care.
                        > Best pracice is to leave them as-is.
                        >
                        > See also:
                        >
                        > http://www.postfix.org/FORWARD_SECRECY_README.html

                        Right. That's one of the specific documents I'd already referenced as
                        having read in my OP. It's thorough, and to me, confusing. Which is
                        exactly why I'm here asking.

                        What, exactly, are the defaults -- as such, recommended -- that you
                        reference? There are tons of variable rerferenced -- which one's
                        documentation lists that list?

                        > Best pracice is to leave them as-is.

                        Yet, that same page states:

                        "It is likely safe to set "smtp_tls_ciphers = medium" if you wish to
                        disable the obsolete "export" and "low" grade ciphers even with
                        opportunistic TLS."

                        Is that a recommendation?

                        In the context of this discussion, what happend if "smtp_tls_ciphers =
                        medium" is set, and another server sends TO my server attempting one of
                        those disabled 'obsolete "export" and "low" grade ciphers' ? Does the
                        encryption fall back to plain/unencrypted?

                        Grant
                      • Viktor Dukhovni
                        ... The Postfix default settings are chosen with care, and changing them without making things worse rather than better requires significant expertise. It is
                        Message 11 of 17 , Jun 21, 2014
                        • 0 Attachment
                          On Sat, Jun 21, 2014 at 10:49:17AM -0700, grantksupport@... wrote:

                          > > See also:
                          > >
                          > > http://www.postfix.org/FORWARD_SECRECY_README.html
                          >
                          > Right. That's one of the specific documents I'd already referenced as
                          > having read in my OP. It's thorough, and to me, confusing. Which is
                          > exactly why I'm here asking.

                          The Postfix default settings are chosen with care, and changing them without
                          making things worse rather than better requires significant expertise.

                          It is best to not make any changes in the cipher settings, except
                          in specific policy-table work-arounds for problems with specific
                          domains.

                          > What, exactly, are the defaults -- as such, recommended -- that you
                          > reference? There are tons of variable rerferenced -- which one's
                          > documentation lists that list?

                          The best advice I can give you is to move on to other things to improve.
                          These aren't the droids you're looking for.

                          > "It is likely safe to set "smtp_tls_ciphers = medium" if you wish to
                          > disable the obsolete "export" and "low" grade ciphers even with
                          > opportunistic TLS."
                          >
                          > Is that a recommendation?

                          No. Just a bone to throw to people who feel compelled to change
                          something.

                          > In the context of this discussion, what happend if "smtp_tls_ciphers =
                          > medium" is set, and another server sends TO my server attempting one of
                          > those disabled 'obsolete "export" and "low" grade ciphers' ? Does the
                          > encryption fall back to plain/unencrypted?

                          Well, the setting in question is an output setting, and you're
                          talking about input. So the question makes no sense. However,
                          were you then to connect to a server that supports only weak
                          ciphersuites, your server would fall back to cleartext delivery.

                          I repeat, these aren't the droids you're looking for.

                          --
                          Viktor.
                        • grantksupport@...
                          ... ok, no longer looking for those droids. returning to why I started looking for them in the 1st place, trying to understand/control the strength of
                          Message 12 of 17 , Jun 21, 2014
                          • 0 Attachment
                            On Sat, Jun 21, 2014, at 11:41 AM, Viktor Dukhovni wrote:
                            > I repeat, these aren't the droids you're looking for.

                            ok, no longer looking for those droids.

                            returning to why I started looking for them in the 1st place, trying to
                            understand/control the strength of encryption to/from my server, making
                            sure the strongest possible is used as often as possible. that, iiuc,
                            is one of the principles behind the 'careful selection' you reference.

                            looking at headers of mail sent FROM my my postfix server TO my gmail
                            account

                            Received: from mx.grantkXXXXX.com (mx.grantkXXXXX.com.
                            [##.##.##.##])
                            by mx.google.com with ESMTPS id
                            dj7si15098768pad.191.2014.06.21.13.01.23
                            for <grantkYYYYY@...>
                            (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256
                            bits=128/128);
                            Sat, 21 Jun 2014 12:11:24 -0700 (PDT)

                            with default postfix config it's using a strong, elliptical cipher --
                            which IIUC is good.

                            but for mail sent FROM my gmail account TO my postfix server

                            Received: from mail-wg0-f66.google.com (mail-wg0-f66.google.com
                            [74.125.82.66])
                            (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128
                            bits))
                            (No client certificate requested)
                            by mx.grantkXXXXX.com (Postfix) with ESMTPS id
                            F15CC101F1A
                            for <postmaster@...>; Sat, 21 Jun 2014
                            12:12:44 -0700 (PDT)

                            it's using an "RC4" cipher, which, IIUC is not-so-good.

                            Can, &/or should, I attempt to control that inbound cipher to something
                            stronger? Or is this as good as I can expect?
                          • Viktor Dukhovni
                            ... Looks fine. ... Google is preferring RC4. SMTP server preemption of client-side cipher preference is unwise. RC4 will have to do until Google improves
                            Message 13 of 17 , Jun 21, 2014
                            • 0 Attachment
                              On Sat, Jun 21, 2014 at 01:13:35PM -0700, grantksupport@... wrote:

                              > looking at headers of mail sent FROM my my postfix server TO my gmail
                              > account
                              >
                              > Received: from mx.grantkXXXXX.com (mx.grantkXXXXX.com.
                              > [##.##.##.##])
                              > by mx.google.com with ESMTPS id
                              > dj7si15098768pad.191.2014.06.21.13.01.23
                              > for <grantkYYYYY@...>
                              > (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256
                              > bits=128/128);
                              > Sat, 21 Jun 2014 12:11:24 -0700 (PDT)

                              Looks fine.

                              > but for mail sent FROM my gmail account TO my postfix server
                              >
                              > Received: from mail-wg0-f66.google.com (mail-wg0-f66.google.com
                              > [74.125.82.66])
                              > (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128
                              > bits))
                              > (No client certificate requested)
                              > by mx.grantkXXXXX.com (Postfix) with ESMTPS id
                              > F15CC101F1A
                              > for <postmaster@...>; Sat, 21 Jun 2014
                              > 12:12:44 -0700 (PDT)
                              >
                              > it's using an "RC4" cipher, which, IIUC is not-so-good.

                              Google is preferring RC4. SMTP server preemption of client-side
                              cipher preference is unwise. RC4 will have to do until Google
                              improves their settings. The Postfix SMTP server prefers AES to
                              RC4, but honours the client preference (to avoid interop problems).

                              Your server is fine. Google is using RC4 outbound, and it is their
                              responsibility to improve that, not yours.

                              --
                              Viktor.
                            • Wietse Venema
                              ... The server announces a list of supported ciphers. From that list the client chooses the cipher that it prefers most. Instead of tinkering with
                              Message 14 of 17 , Jun 21, 2014
                              • 0 Attachment
                                grantksupport@...:
                                >
                                >
                                > On Sat, Jun 21, 2014, at 11:41 AM, Viktor Dukhovni wrote:
                                > > I repeat, these aren't the droids you're looking for.
                                >
                                > ok, no longer looking for those droids.
                                >
                                > returning to why I started looking for them in the 1st place, trying to
                                > understand/control the strength of encryption to/from my server, making
                                > sure the strongest possible is used as often as possible. that, iiuc,

                                The server announces a list of supported ciphers. From that list
                                the client chooses the cipher that it prefers most. Instead of
                                tinkering with carefully-chosen Postfix defaults, I suggest that
                                you go look for some other toy to play with.

                                Wietse
                              • grantksupport@...
                                Viktor, ... Thanks, for the pointers. That s cleared up & understood now. ... go look for some other toy to play with. Really? You bitch and moan about
                                Message 15 of 17 , Jun 21, 2014
                                • 0 Attachment
                                  Viktor,

                                  > Your server is fine. Google is using RC4 outbound, and it is their
                                  > responsibility to improve that, not yours.

                                  Thanks, for the pointers. That's cleared up & understood now.

                                  On Sat, Jun 21, 2014, at 01:35 PM, Wietse Venema wrote:
                                  > Instead of tinkering with carefully-chosen Postfix defaults, I suggest that
                                  > you go look for some other toy to play with.

                                  "go look for some other toy to play with."

                                  Really?

                                  You bitch and moan about people NOT reading, and NOT trying to learn,
                                  constantly telling us to RTFM ... and wrap it all up in your widely
                                  renowed and storied arrogance & rudeness.

                                  Then when we DO rtf, and DO ask, and DO try to learn, you do it all some
                                  more.

                                  I see your reputation is well-earned and well-deserved. Famous &
                                  accomplished or not, a rude jackass is still a rude jackass.
                                • Wietse Venema
                                  ... Please, pick a more interesting subject for your inquiries. Wietse
                                  Message 16 of 17 , Jun 21, 2014
                                  • 0 Attachment
                                    grantksupport@...:
                                    > Viktor,
                                    >
                                    > > Your server is fine. Google is using RC4 outbound, and it is their
                                    > > responsibility to improve that, not yours.
                                    >
                                    > Thanks, for the pointers. That's cleared up & understood now.
                                    >
                                    > On Sat, Jun 21, 2014, at 01:35 PM, Wietse Venema wrote:
                                    > > Instead of tinkering with carefully-chosen Postfix defaults, I suggest that
                                    > > you go look for some other toy to play with.
                                    >
                                    > "go look for some other toy to play with."
                                    >
                                    > Really?
                                    >
                                    > You bitch and moan about people NOT reading, and NOT trying to learn,
                                    > constantly telling us to RTFM ... and wrap it all up in your widely
                                    > renowed and storied arrogance & rudeness.

                                    Please, pick a more interesting subject for your inquiries.

                                    Wietse
                                  • Marius Gologan
                                    Grant, Postfix speak for its authors. I m grateful for it, like many others in IT tech and business fields. Since I m not so experienced in TLS, maybe my
                                    Message 17 of 17 , Jun 21, 2014
                                    • 0 Attachment
                                      Grant,

                                      Postfix speak for its authors. I'm grateful for it, like many others in IT
                                      tech and business fields.

                                      Since I'm not so experienced in TLS, maybe my answer is more close to your
                                      level:

                                      1) Have in mind that SMTP client servers are not web browsers, thus, they
                                      don't act the same.
                                      2) Removing weak cyphers from pubic MX servers will cause SMTP client
                                      servers to fall on plain.
                                      3.1) having medium cyphers (as minimum) for MSA might be good if the client
                                      can "speak" medium, high encryption - in this case, credentials must be
                                      protected - medium, high encryption may be desirable.
                                      3.2) having medium cyphers (as minimum) when your server acts as SMTP client
                                      or MSA is desirable, but with few occasional exceptions, when emails will
                                      not be delivered to some destinations or will fall back on plain (let's say
                                      mx.n.gmx.tld)

                                      Before starting a project, I will read what features I have on the table,
                                      start building a draft, fail, get frustrated for some time without much
                                      sleep, "enjoy" complaints, reach the limits and if I would need desperate
                                      help without options, I'll seek answers here.

                                      On the other hand, I'm a Windows guy too, I never thought calling Mr. Gates
                                      for support, even if I paid him.

                                      Marius.

                                      -----Original Message-----
                                      From: owner-postfix-users@...
                                      [mailto:owner-postfix-users@...] On Behalf Of
                                      grantksupport@...
                                      Sent: Sunday, June 22, 2014 12:03 AM
                                      To: postfix-users@...
                                      Subject: Re: Opportunistic TLS vs. plain

                                      Viktor,

                                      > Your server is fine. Google is using RC4 outbound, and it is their
                                      > responsibility to improve that, not yours.

                                      Thanks, for the pointers. That's cleared up & understood now.

                                      On Sat, Jun 21, 2014, at 01:35 PM, Wietse Venema wrote:
                                      > Instead of tinkering with carefully-chosen Postfix defaults, I suggest
                                      that
                                      > you go look for some other toy to play with.

                                      "go look for some other toy to play with."

                                      Really?

                                      You bitch and moan about people NOT reading, and NOT trying to learn,
                                      constantly telling us to RTFM ... and wrap it all up in your widely
                                      renowed and storied arrogance & rudeness.

                                      Then when we DO rtf, and DO ask, and DO try to learn, you do it all some
                                      more.

                                      I see your reputation is well-earned and well-deserved. Famous &
                                      accomplished or not, a rude jackass is still a rude jackass.
                                    Your message has been successfully submitted and would be delivered to recipients shortly.