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

Re: Outsourced anti-spam and Issues with VRFY

Expand Messages
  • Wietse Venema
    ... This should be safe. Apparently they are optimizing for Sendmail-like MTAs that have a large process startup cost when they make one connection per (vrfy)
    Message 1 of 22 , Aug 5, 2013
    • 0 Attachment
      Noel Jones:
      > On 8/5/2013 10:30 AM, Charles Marcus wrote:
      > > On 2013-08-05 10:53 AM, Noel Jones <njones@...> wrote:
      > >> I don't suppose an open idle connection from an somewhat authorized
      > >> client will bother anything, so just go with it.
      > >
      > > Ok - and by 'go with it', you mean just adjust the settings per your
      > > last email and be done with it, right?
      >
      > That's right.

      This should be safe.

      Apparently they are optimizing for Sendmail-like MTAs that have a
      large process startup cost when they make one connection per (vrfy)
      request. Postfix does not have that problem.

      > Just don't ask them for postfix advice ;)

      Indeed.

      Wietse
    • Stan Hoeppner
      ... ... I m sure you ve already covered this Charles but just in case you haven t I ll mention it anyway. No matter what you do here with this outsourced
      Message 2 of 22 , Aug 5, 2013
      • 0 Attachment
        On 8/5/2013 9:09 AM, Charles Marcus wrote:
        > On 2013-08-05 9:21 AM, Noel Jones <njones@...> wrote:
        >> Set those three limits to 100 or higher. Those controls are
        >> intended to prevent random clients from wasting your time. Since
        >> you don't allow connections from random clients, it's safe to
        >> increase them.
        >>
        >> # main.cf
        >> smtpd_hard_error_limit = 100
        >> smtpd_soft_error_limit = 100
        >> smtpd_junk_command_limit = 100
        >
        > Thanks Noel... I'll do this, unless I can get them to change their VRFY
        > service to properly close these connections - or stop using a MAIL FROM
        > that is in my domain name for their SMTP RCPT TO option so we could use
        > that option.
        ...

        I'm sure you've already covered this Charles but just in case you
        haven't I'll mention it anyway.

        No matter what you do here with this outsourced service, I'd suggest you
        document all Postfix config changes you're making, or save a copy of
        your main/master.cf files as they were before embarking down this path,
        should you later decide to ditch this service. You don't want these
        custom setting biting you in the backside if/when you switch back to
        direct-to-MX, or possibly to another outsourced service.

        --
        Stan
      • Charles Marcus
        ... Thanks Stan, good idea, but I m ahead of you. I have a special section in main.cf for all of my custom settings (at the very bottom of the file), and I
        Message 3 of 22 , Aug 6, 2013
        • 0 Attachment
          On 2013-08-05 11:33 PM, Stan Hoeppner <stan@...> wrote:
          > I'm sure you've already covered this Charles but just in case you
          > haven't I'll mention it anyway.
          >
          > No matter what you do here with this outsourced service, I'd suggest you
          > document all Postfix config changes you're making, or save a copy of
          > your main/master.cf files as they were before embarking down this path,
          > should you later decide to ditch this service. You don't want these
          > custom setting biting you in the backside if/when you switch back to
          > direct-to-MX, or possibly to another outsourced service.

          Thanks Stan, good idea, but I'm ahead of you.

          I have a 'special' section in main.cf for all of my custom settings (at
          the very bottom of the file), and I have these particular changes under
          my 'work around stupid Edgewave behavior (not closing VRFY probes)'
          section... ;)

          --

          Best regards,

          Charles
        • Charles Marcus
          ... Ok, I made these changes, but wanted to confirm something... I m still seeing lots of these in the logs (but I m fairly sure this was ... What I was
          Message 4 of 22 , Aug 6, 2013
          • 0 Attachment
            On 2013-08-05 9:21 AM, Noel Jones <njones@...> wrote:
            > Set those three limits to 100 or higher. Those controls are
            > intended to prevent random clients from wasting your time. Since
            > you don't allow connections from random clients, it's safe to
            > increase them.
            >
            > # main.cf
            > smtpd_hard_error_limit = 100
            > smtpd_soft_error_limit = 100
            > smtpd_junk_command_limit = 100

            Ok, I made these changes, but wanted to confirm something...

            I'm still seeing lots of these in the logs (but I'm fairly sure this was
            to be expected?):

            > 2013-08-06T06:31:55-04:00 myhost postfix-25/smtpd[12390]: lost connection after VRFY from smtp644.redcondor.net[208.80.206.44]

            What I was expecting was that the 'too many errors' issue would be
            resolved by these changes, but alas, I had one about an hour after
            making the change (and to be sure I did fully restart postfix):

            > 2013-08-06T07:33:25-04:00 myhost postfix-25/smtpd[12873]: too many errors after VRFY from smtp644.redcondor.net[208.80.206.44]

            So... does this mean that I need to adjust the values higher? Or dos
            this mean that this problem is caused by something else?

            Thanks,

            --

            Best regards,

            Charles
          • Wietse Venema
            ... Did the provier actually promise that they were going to send no more than 100 VRFY requests per session? All I recall was an incorrect claim that (soft
            Message 5 of 22 , Aug 6, 2013
            • 0 Attachment
              Charles Marcus:
              > What I was expecting was that the 'too many errors' issue would be
              > resolved by these changes, but alas, I had one about an hour after
              > making the change (and to be sure I did fully restart postfix):
              >
              > > 2013-08-06T07:33:25-04:00 myhost postfix-25/smtpd[12873]: too many errors after VRFY from smtp644.redcondor.net[208.80.206.44]
              >
              > So... does this mean that I need to adjust the values higher? Or dos
              > this mean that this problem is caused by something else?

              Did the provier actually promise that they were going to send no
              more than 100 VRFY requests per session?

              All I recall was an incorrect claim that (soft error limit > hard
              error limit) would cause Postfix to accept unlimited numbers of
              VRFY requests. That is not how Postfix works.

              They must limit the number of VRFY requests per SMTP session and
              they must give you that limit.

              Wietse
            • Charles Marcus
              On 2013-08-06 10:29 AM, wietse@porcupine.org (Wietse Venema) ... Ok, well, that was pretty obvious... Thanks, I ll follow that up with them. -- Best regards,
              Message 6 of 22 , Aug 6, 2013
              • 0 Attachment
                On 2013-08-06 10:29 AM, wietse@... (Wietse Venema)
                <wietse@... (Wietse Venema)> wrote:
                > Did the provier actually promise that they were going to send no
                > more than 100 VRFY requests per session?
                >
                > All I recall was an incorrect claim that (soft error limit > hard
                > error limit) would cause Postfix to accept unlimited numbers of
                > VRFY requests. That is not how Postfix works.
                >
                > They must limit the number of VRFY requests per SMTP session and
                > they must give you that limit.

                Ok, well, that was pretty obvious...

                Thanks, I'll follow that up with them.

                --

                Best regards,

                Charles
              Your message has been successfully submitted and would be delivered to recipients shortly.