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

Dealing with unreliable milters - revisited

Expand Messages
  • Mark Martinec
    If you remember a topic I started at the beginning of September (2007), just to refresh memories: ... [...] ... Well, I came across another case of a similar
    Message 1 of 4 , Nov 30, 2007
    • 0 Attachment
      If you remember a topic I started at the beginning of September (2007),
      just to refresh memories:

      myself:
      > Read the following as a suggestion or a feature request.
      > Every now and then some new kind of bugs in milters pop up,
      > causing them to misbehave or just crash. Luckily the setting:
      > milter_default_action = accept
      > deals with milter process crashes, and lets mail flow on
      > without them, which is what I want.
      > Unfortunately, only partly failing milters can still block
      > mail by resulting in temporary failures.
      [...]
      > It would be nice if there were some way to let Postfix
      > deal with such problems the same way as with crashed milters.
      > Either letting milter_default_action=accept ignore temporary
      > failures, or by introducing some stronger setting.

      Wietse:
      > Do you want to ignore SMFIR_TEMPFAIL results?

      myself:
      > Yes, that would be my desire, having a possibility to configure
      > Postfix to just ignore SMFIR_TEMPFAIL and behave as if a
      > milter were unavailable.

      Viktor:
      > Is it correct for the milter to tempfail in this case? Should it not
      > in the worst case just fail to verify the signature?

      myself:
      > Wishful thinking...

      Wietse:
      > Perhaps the following text in dkim-filter.conf(5) helps:
      > On-InternalError (string)
      > On-BadSignature (string)

      myself:
      > Yes, this helps with this particular milter, adding a command line
      > option '-C int=a' allows mail to pass. Thanks!

      Jose-Marcio:
      > The MTA shouldn't implement workarounds to handle unreliable
      > milter answers (other than low level or protocol errors).

      myself:
      > Perhaps. Problems in milters undoubtedly need to be fixed eventually,
      > but allowing to tell MTA to ignore such errors could make life
      > easier to a mailing system administrator when he has to deal with
      > less-then-perfect external software. But I can live with it,
      > one way or another.

      Well, I came across another case of a similar kind, with the same
      milter (dkim in verifying mode, NOT configured to reject a message
      or tempfail on errors (-C dns=a,int=a) but let's stick to the MTA-side
      of the story here).

      This time it decided to reject a message. Admittedly the message is
      a degenerate, with lots of addresses in a long header, but Postfix
      by itself can deal with it and deliver it just fine. This is what
      happens:

      dkim-filter[8423]: too much header data; rejecting
      postfix/cleanup[26509]: E938439DCBB: milter-reject:
      END-OF-MESSAGE from xxx[dd.dd.dd.dd]:
      5.7.1 Command rejected; from=<xxx@...>
      to=<xxx@...> proto=ESMTP helo=<xxx.ijs.si>

      I would like to request a Postfix configuration setting
      which could override any attempts of some milter
      to reject or tempfail a message. It is unrealistic to
      expect milters to match the reliability standards of Posfix.

      Btw, the next version of amavisd-new is coming with its
      own direct support for DKIM signing and verification
      (using a Mail::DKIM module, thanks to Jason Long).
      It was fun to play with milters, they've accomplished
      their job, now it's time to get rid of them :)

      Mark
    • Victor Duchovni
      ... My sentiments exactly, I have no plans to use milters. Full disclosure: for quite some now I have planned to not use milters. I have not deployed DKIM yet,
      Message 2 of 4 , Nov 30, 2007
      • 0 Attachment
        On Fri, Nov 30, 2007 at 06:58:23PM +0100, Mark Martinec wrote:

        > Btw, the next version of amavisd-new is coming with its
        > own direct support for DKIM signing and verification
        > (using a Mail::DKIM module, thanks to Jason Long).
        > It was fun to play with milters, they've accomplished
        > their job, now it's time to get rid of them :)

        My sentiments exactly, I have no plans to use milters. Full disclosure:
        for quite some now I have planned to not use milters.

        I have not deployed DKIM yet, but will be doing so in the next few months,
        using a plugin for an in-house SMTP proxy that plays a role similar to
        amavis (modular content filter and MIME normalizer).

        --
        Viktor.

        Disclaimer: off-list followups get on-list replies or get ignored.
        Please do not ignore the "Reply-To" header.

        To unsubscribe from the postfix-users list, visit
        http://www.postfix.org/lists.html or click the link below:
        <mailto:majordomo@...?body=unsubscribe%20postfix-users>

        If my response solves your problem, the best way to thank me is to not
        send an "it worked, thanks" follow-up. If you must respond, please put
        "It worked, thanks" in the "Subject" so I can delete these quickly.
      • Wietse Venema
        ... I also asked this question about ignoring tempfail replies. What if the Milter has already modified the message? The result will be inconsistent (from the
        Message 3 of 4 , Nov 30, 2007
        • 0 Attachment
          Mark Martinec:
          > I would like to request a Postfix configuration setting
          > which could override any attempts of some milter
          > to reject or tempfail a message. It is unrealistic to
          > expect milters to match the reliability standards of Posfix.

          I also asked this question about ignoring tempfail replies. What
          if the Milter has already modified the message? The result will be
          inconsistent (from the user point of view; Postfix would not create
          a corrupted queue file).

          BTW it should be possible to configure Postfix so that it limits
          headers to within Milter-acceptable limits. Most of the necessary
          support for that is already there.

          > Btw, the next version of amavisd-new is coming with its
          > own direct support for DKIM signing and verification
          > (using a Mail::DKIM module, thanks to Jason Long).
          > It was fun to play with milters, they've accomplished
          > their job, now it's time to get rid of them :)

          I prefer a single-hop server.

          Wietse
        • Mark Martinec
          ... If an administrator explicitly requests an override (despite some documented caveats), he should be willing to accept the risk that a milter might first
          Message 4 of 4 , Dec 2, 2007
          • 0 Attachment
            Wietse wrote:
            > Mark Martinec:
            > > I would like to request a Postfix configuration setting
            > > which could override any attempts of some milter
            > > to reject or tempfail a message.
            >
            > I also asked this question about ignoring tempfail replies. What
            > if the Milter has already modified the message? The result will be
            > inconsistent (from the user point of view; Postfix would not create
            > a corrupted queue file).

            If an administrator explicitly requests an override (despite
            some documented caveats), he should be willing to accept the
            risk that a milter might first request some changes to a mail,
            then changed its mind and rejected or tempfailed it.
            I think a warning in a log would suffice. For me, it would be
            acceptable one way or another (with or without milter edits
            to a message being applied).

            > BTW it should be possible to configure Postfix so that it limits
            > headers to within Milter-acceptable limits. Most of the necessary
            > support for that is already there.

            In this particular case the header size is limited to 32 kB,
            although I don't think it is worth the effort to anticipate
            anything that might go wrong in a milter and have a workaround
            available. Today is a header size, yesterday was a header field
            length, tomorrow will be something else.

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