Bugs like these aren't serious, probably even not worth postponing a
release, all that matters is that basic functionality works, we should make
no guarantees for stuff like using strange tags in AskDNS rules.  It's not
end of the world if we have to release 3.4.4 anyway.  I wonder if
distributions even adopt 3.4.3..

On Thu, Nov 28, 2019 at 06:24:55AM -0500, Kevin A. McGrail wrote:
> The extreme lack of testing has had me worried as I have consistently found
> bugs in the release.  I think we failed a bit in the test driven development
> and the ability to release fast and often is hurt by it. I really wanted to
> close out 3.4 and move on to 4.0!
> 
> With the current rc, I now have all the new functionality on a production
> system and working but I have a grand total of about 3 emails from ALL the RCs
> from testing.  I am very nervous!
> 
> On Thu, Nov 28, 2019, 06:19 Henrik K <[1]h...@hege.li> wrote:
> 
> 
>     Sure why not..  should try actually releasing after that, before we make a
>     world record in rc-count.  :-D
> 
>     On Thu, Nov 28, 2019 at 06:11:51AM -0500, Kevin A. McGrail wrote:
>     > Fair enough.  Ok to move forward with another rc do.you think?
>     >
>     > On Thu, Nov 28, 2019, 05:40 Henrik K <[1][2]h...@hege.li> wrote:
>     >
>     >
>     >     It's not that the issue itself needs a test.  AskDNS and/or tag
>     handling
>     >     currently have no tests at all.  In addition there's some open bugs
>     looking
>     >     at the ways to use AskDNS and it's shortcomings (empty tags, meta
>     tests
>     >     breaking on askdns etc).  TLDR: It actually requires a lot of work,
>     don't
>     >     have time or stamina right now.
>     >
>     >     On Thu, Nov 28, 2019 at 05:33:03AM -0500, Kevin A. McGrail wrote:
>     >     > I never would have found that.á Nice job.
>     >     >
>     >     > Any chance you can create a regression test for the issue ?
>     >     >
>     >     > On Thu, Nov 28, 2019, 05:09 Henrik K <[1][2][3]h...@hege.li> 
> wrote:
>     >     >
>     >     >
>     >     >     Fixed:
>     >     >     [2][3][4]http://svn.apache.org/viewvc?view=revision&revision=
>     1870552
>     >     >
>     >     >     On Thu, Nov 28, 2019 at 11:29:19AM +0200, Henrik K wrote:
>     >     >     >
>     >     >     > Trunk has already many revamps and fixes for these codes,
>     works
>     >     there.á
>     >     >     It
>     >     >     > seems 3.4 askdns has trouble using those, investigating
>     minimal
>     >     fix..
>     >     >     >
>     >     >     >
>     >     >     > On Thu, Nov 28, 2019 at 10:20:39AM +0100, Tobi <[3][4]
>     >     [5]jahli...@gmx.ch>
>     >     >     wrote:
>     >     >     > > Henrik
>     >     >     > >
>     >     >     > > But my current testing clearly shows that without the
>     explicit
>     >     set_tag
>     >     >     > > _LASTEXTERNALRDNS_ and _LASTEXTERNALHELO_ won't be set.
>     >     >     > > I'm testing this using spamassassin in debug mode to scan 
> a
>     >     >     testmessage.
>     >     >     > > As soon as I re-add the set_tag to PerMsgStatus.pm the 
> tags
>     are
>     >     set and
>     >     >     > > tests based on that tags are run. Removing the lines from
>     pm and
>     >     debug
>     >     >     > > shows that the tests are **not** run anymore.
>     >     >     > >
>     >     >     > > So I somewhat doubt that the set_tag "code is redundant 
> and
>     >     should be
>     >     >     > > removed" :-)
>     >     >     > >
>     >     >     > > Using: SA 3.4.2 on centos7 / perl 5.16.3
>     >     >     > >
>     >     >     > >
>     >     >     > > Cheers
>     >     >     > >
>     >     >     > > tobi
>     >     >     > >
>     >     >     > > Am 28.11.19 um 08:36 schrieb Henrik K:
>     >     >     > > >
>     >     >     > > > There is nothing missing.á All the LASTEXT* tags are
>     already
>     >     >     dynamically
>     >     >     > > > returning functions.á If anything, that if ($lasthop)
>     set_tag
>     >     code is
>     >     >     > > > completely redundant and should be removed.
>     >     >     > > >
>     >     >     > > >
>     >     >     > > > BEGIN {
>     >     >     > > >á á áLASTEXTERNALIP => sub {
>     >     >     > > >á á á ámy $pms = shift;
>     >     >     > > >á á á ámy $lasthop = $pms->{relays_external}->[0];
>     >     >     > > >á á á á$lasthop ? $lasthop->{ip} : '';
>     >     >     > > >á á á},
>     >     >     > > >
>     >     >     > > >á á áLASTEXTERNALRDNS => sub {
>     >     >     > > >á á á ámy $pms = shift;
>     >     >     > > >á á á ámy $lasthop = $pms->{relays_external}->[0];
>     >     >     > > >á á á á$lasthop ? $lasthop->{rdns} : '';
>     >     >     > > >á á á},
>     >     >     > > >
>     >     >     > > >á á áLASTEXTERNALHELO => sub {
>     >     >     > > >á á á ámy $pms = shift;
>     >     >     > > >á á á ámy $lasthop = $pms->{relays_external}->[0];
>     >     >     > > >á á á á$lasthop ? $lasthop->{helo} : '';
>     >     >     > > >á á á},
>     >     >     > > >
>     >     >     > > >
>     >     >     > > > On Wed, Nov 27, 2019 at 10:18:20AM -0500, Kevin A.
>     McGrail
>     >     wrote:
>     >     >     > > >> After a 10 minute or so study of the issue and 
> comparing
>     3.4
>     >     and
>     >     >     trunk,
>     >     >     > > >> it definitely looks like the code is missing.á I am not
>     100%
>     >     sure
>     >     >     your
>     >     >     > > >> fix works but it's better than it currently exists :-)
>     >     >     > > >>
>     >     >     > > >> Have you been using that change in production?
>     >     >     > > >>
>     >     >     > > >> Regards,
>     >     >     > > >>
>     >     >     > > >> KAM
>     >     >     > > >>
>     >     >     > > >> On 11/27/2019 6:59 AM, Tobi <[4][5][6]jahli...@gmx.ch>
>     wrote:
>     >     >     > > >>> Hi,
>     >     >     > > >>>
>     >     >     > > >>> is there any specific reason why the two tags 
> mentioned
>     in
>     >     subject
>     >     >     are
>     >     >     > > >>> not set in SA? It took me a while to find out why an
>     askdns
>     >     test
>     >     >     was not
>     >     >     > > >>> running. The test relies on _LASTEXTERNALRDNS_ but
>     after
>     >     running
>     >     >     with
>     >     >     > > >>> --debug I found that those tags are not set by SA.
>     Although
>     >     >     > > >>> _LASTEXTERNALIP_ is set. Also the man page states that
>     the
>     >     two tags
>     >     >     > > >>> should exist.
>     >     >     > > >>>
>     >     >     > > >>> In PerMsgStatus.pm I saw that everything is prepared
>     for the
>     >     two
>     >     >     tags
>     >     >     > > >>> but they finally not set (around line 1721). So I
>     changed to
>     >     >     > > >>>
>     >     >     > > >>>> if ($lasthop) {
>     >     >     > > >>>>á á $self->set_tag('LASTEXTERNALIP',á $lasthop->{ip});
>     >     >     > > >>>>á á $self->set_tag('LASTEXTERNALRDNS', $lasthop->
>     {rdns});
>     >     >     > > >>>>á á $self->set_tag('LASTEXTERNALHELO', $lasthop->
>     {helo});
>     >     >     > > >>>>á }
>     >     >     > > >>>
>     >     >     > > >>> and --debug shows that the tags are now set and the
>     askdns
>     >     test is
>     >     >     run.
>     >     >     > > >>>
>     >     >     > > >>> So I wonder if the code has just been forgotten or if
>     there
>     >     are
>     >     >     deeper
>     >     >     > > >>> reasons to not set the tags?
>     >     >     > > >>> If no deeper reasons exist it would be nice to have
>     those two
>     >     tags
>     >     >     set
>     >     >     > > >>> as default in PerMsgStatus.pm
>     >     >     > > >>>
>     >     >     > > >>>
>     >     >     > > >>> Cheers
>     >     >     > > >>>
>     >     >     > > >>> --
>     >     >     > > >>>
>     >     >     > > >>> tobi
>     >     >     > > >>
>     >     >     > > >> --
>     >     >     > > >> Kevin A. McGrail
>     >     >     > > >> kmcgr...@apache.org
>     >     >     > > >>
>     >     >     > > >> Member, Apache Software Foundation
>     >     >     > > >> Chair Emeritus Apache SpamAssassin Project
>     >     >     > > >> [5][6][7]https://www.linkedin.com/in/kmcgrail -
>     703.798.0171
>     >     >     > > >
>     >     >
>     >     >
>     >     > References:
>     >     >
>     >     > [1] mailto:[7][8]h...@hege.li
>     >     > [2] [8][9]http://svn.apache.org/viewvc?view=revision&revision=
>     1870552
>     >     > [3] mailto:[9][10]jahli...@gmx.ch
>     >     > [4] mailto:[10][11]jahli...@gmx.ch
>     >     > [5] [11][12]https://www.linkedin.com/in/kmcgrail
>     >
>     >
>     > References:
>     >
>     > [1] mailto:[13]h...@hege.li
>     > [2] mailto:[14]h...@hege.li
>     > [3] [15]http://svn.apache.org/viewvc?view=revision&revision=1870552
>     > [4] mailto:[16]jahli...@gmx.ch
>     > [5] mailto:[17]jahli...@gmx.ch
>     > [6] [18]https://www.linkedin.com/in/kmcgrail
>     > [7] mailto:[19]h...@hege.li
>     > [8] [20]http://svn.apache.org/viewvc?view=revision&revision=1870552
>     > [9] mailto:[21]jahli...@gmx.ch
>     > [10] mailto:[22]jahli...@gmx.ch
>     > [11] [23]https://www.linkedin.com/in/kmcgrail
> 
> 
> References:
> 
> [1] mailto:h...@hege.li
> [2] mailto:h...@hege.li
> [3] mailto:h...@hege.li
> [4] http://svn.apache.org/viewvc?view=revision&revision=1870552
> [5] mailto:jahli...@gmx.ch
> [6] mailto:jahli...@gmx.ch
> [7] https://www.linkedin.com/in/kmcgrail
> [8] mailto:h...@hege.li
> [9] http://svn.apache.org/viewvc?view=revision&revision=1870552
> [10] mailto:jahli...@gmx.ch
> [11] mailto:jahli...@gmx.ch
> [12] https://www.linkedin.com/in/kmcgrail
> [13] mailto:h...@hege.li
> [14] mailto:h...@hege.li
> [15] http://svn.apache.org/viewvc?view=revision&revision=1870552
> [16] mailto:jahli...@gmx.ch
> [17] mailto:jahli...@gmx.ch
> [18] https://www.linkedin.com/in/kmcgrail
> [19] mailto:h...@hege.li
> [20] http://svn.apache.org/viewvc?view=revision&revision=1870552
> [21] mailto:jahli...@gmx.ch
> [22] mailto:jahli...@gmx.ch
> [23] https://www.linkedin.com/in/kmcgrail

Reply via email to