Re: LASTEXTERNALRDNS and LASTEXTERNALHELO not set in PerMsgStatus.pm ?
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 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
> https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: Can someone explain how to read Bayes stats?
On 27 Nov 2019, at 06:52, Anders Gustafsson wrote: > 0.000 0 3184 0 non-token data: nspam > 0.000 0 17298 0 non-token data: nham Plenty of spam and ham learned > 0.000 0 1553643652 0 non-token data: oldest atime Oldest data is from March > 0.000 0 1574862537 0 non-token data: newest atime Newest date from today > I had SA running before, but hd to take a break because of upgrades. I have > not had the chance yet to collect over 200 SPAM/HAM messages for training. You have, but chances are most of it is old. Still, that doesn’t mean useless. You should see bales scores in incoming mail. -- "Are you pondering what I'm pondering?" "I think so, Brain, but Zero Mostel times anything will still give you Zero Mostel.”
Re: LASTEXTERNALRDNS and LASTEXTERNALHELO not set in PerMsgStatus.pm ?
On Wed, 27 Nov 2019 12:59:47 +0100 Tobi 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. What version are you running? I just tried adding _LASTEXTERNALRDNS_ in a header on 3.4.2 and it worked.
Re: LASTEXTERNALRDNS and LASTEXTERNALHELO not set in PerMsgStatus.pm ?
On Wed, 27 Nov 2019 17:00:26 +0100 Tobi wrote: > > Issue could occur if trusted/internal networks is not set properly and > the message contains a non-smtp received header with a public IP. Like > for example could occur if the message is sent via lmtp. Then the > received header does not contain ptr info therefore _LASTEXTERNALRDNS_ > cannot be set or only set with empty string. That could potentially > lead to fancy dns queries if using the tag in an askdns rule AskDNS is supposed to skip empty or undefined strings.
Re: shortcircuit on alread x-spam-flag: yes
Hi Benny yeah your links definitely show massive abuse of mta header/body checks :-) But nonetheless mta header checks are way more performant and efficient than such checks in a filter software. As long as the header you check is used for a kill-shot its best place still is the mta header checks and not in any other filter software ;-) Cheers tobi Am 27.11.19 um 18:30 schrieb Benny Pedersen: > On 2019-11-27 17:56, Philipp Ewald wrote: > >> we only want to trust "X-Spam-Flag: YES" or why should someone >> (spammer, other mailserver with outgoing spamfilter) set this Flag to >> Yes? > > trustness > > https://www.techiepark.com/tutorials/blocking-spam-using-postfix-header_checks-and-spamassassin/ > bad example on what not to do :) > > http://www.techiepark.com/resources/postfix-header-checks/ really want > to make postfix a spam filter ? > > bettr is to use fuglu.org as a before queue content filter with then can > reject spam :=) > > i have still not seen mimedefang working > > >
Re: shortcircuit on alread x-spam-flag: yes
On 2019-11-27 17:56, Philipp Ewald wrote: we only want to trust "X-Spam-Flag: YES" or why should someone (spammer, other mailserver with outgoing spamfilter) set this Flag to Yes? trustness https://www.techiepark.com/tutorials/blocking-spam-using-postfix-header_checks-and-spamassassin/ bad example on what not to do :) http://www.techiepark.com/resources/postfix-header-checks/ really want to make postfix a spam filter ? bettr is to use fuglu.org as a before queue content filter with then can reject spam :=) i have still not seen mimedefang working
Re: shortcircuit on alread x-spam-flag: yes
Hi Philipp > or why should someone (spammer, other mailserver with outgoing > spamfilter) set this Flag to Yes? I would not think about the spammers here too much but more about a misconfigured SA on sending side? Or the admin added a fancy rbl list which suddenly stops working and returns a hit for every query for an ip or domain. Have been there, have seen that :-) Thats brings us back to the FP question Just my 5 cents: if someone trusts the spam assessment of a remote system, then one should have the guts to reject straight-out on mta :-) Or else ignore the spam assessment from remote. Cheers tobi Am 27.11.19 um 17:56 schrieb Philipp Ewald: > Hi Tobi, > > we only want to trust "X-Spam-Flag: YES" or why should someone (spammer, > other mailserver with outgoing spamfilter) set this Flag to Yes? > > but like RW wrote: >> If you want to >> match on such a header you need to rewrite it before SA sees it. > > i thought shortcircuit will test before any other tests but header was > remove before shortcircuit :( > I have a lot to learn... > > Thanks for help maybe i try this again... later :-) > > Am 27.11.19 um 17:15 schrieb Tobi : >> Philipp, >> >> Think you should ask yourself the following question: do I trust the >> spam result from a remote server? If yes then why using a spamassassin >> rule and not straight-out reject such mails on mta (header check)? And >> if you do not trust the remote server then why using its spam decission >> at all? >> >> Cheers >> >> tobi >> >> Am 26.11.19 um 14:06 schrieb Philipp Ewald: >>> Hi guys, >>> >>> i want to bypas scanning mail if mail has already X-Spam-Flag: YES set. >>> I found "clear_headers" in >>> "/usr/share/spamassassin/10_default_prefs.cf". >>> >>> how can i override this setting? (include next update) >>> >>> Kind regards >>> Philipp >>> >>> >>> >
Re: shortcircuit on alread x-spam-flag: yes
On 2019-11-27 17:15, Tobi wrote: Philipp, Think you should ask yourself the following question: do I trust the spam result from a remote server? If yes then why using a spamassassin rule and not straight-out reject such mails on mta (header check)? And if you do not trust the remote server then why using its spam decission at all? all spamassassin headers begins with X-Spam-, you will have to change them BEFORE running localy retest :=) reason for this is that spamassassin REMOVE all headers with begins with X-Spam- before it adds new localy tested headers :=) end results is you always get X-Spam- heades is from local tests, but if you like you can rewrite upfront X-Spam- headers so local tests can use them for local retest
Re: shortcircuit on alread x-spam-flag: yes
Hi Tobi, we only want to trust "X-Spam-Flag: YES" or why should someone (spammer, other mailserver with outgoing spamfilter) set this Flag to Yes? but like RW wrote: If you want to match on such a header you need to rewrite it before SA sees it. i thought shortcircuit will test before any other tests but header was remove before shortcircuit :( I have a lot to learn... Thanks for help maybe i try this again... later :-) Am 27.11.19 um 17:15 schrieb Tobi : Philipp, Think you should ask yourself the following question: do I trust the spam result from a remote server? If yes then why using a spamassassin rule and not straight-out reject such mails on mta (header check)? And if you do not trust the remote server then why using its spam decission at all? Cheers tobi Am 26.11.19 um 14:06 schrieb Philipp Ewald: Hi guys, i want to bypas scanning mail if mail has already X-Spam-Flag: YES set. I found "clear_headers" in "/usr/share/spamassassin/10_default_prefs.cf". how can i override this setting? (include next update) Kind regards Philipp -- Philipp Ewald Administrator DigiOnline GmbH, Probsteigasse 15 - 19, 50670 Köln Telefon: +49 221 6500-532, Fax: +49 221 6500-690, E-Mail: philipp.ew...@digionline.de AG Köln HRB 27711, St.-Nr. 5215 5811 0640 Geschäftsführer: Werner Grafenhain Informationen zum Datenschutz: www.digionline.de/ds
Re: shortcircuit on alread x-spam-flag: yes
Philipp, Think you should ask yourself the following question: do I trust the spam result from a remote server? If yes then why using a spamassassin rule and not straight-out reject such mails on mta (header check)? And if you do not trust the remote server then why using its spam decission at all? Cheers tobi Am 26.11.19 um 14:06 schrieb Philipp Ewald: > Hi guys, > > i want to bypas scanning mail if mail has already X-Spam-Flag: YES set. > I found "clear_headers" in "/usr/share/spamassassin/10_default_prefs.cf". > > how can i override this setting? (include next update) > > Kind regards > Philipp > > >
Re: LASTEXTERNALRDNS and LASTEXTERNALHELO not set in PerMsgStatus.pm ?
Hi Kevin
sorry for sending offlist the first time :-)
> Have you been using that change in production?
Yes I changed it in my prod perl file today. Works so far for the last
couple of hours.
Issue could occur if trusted/internal networks is not set properly and
the message contains a non-smtp received header with a public IP. Like
for example could occur if the message is sent via lmtp. Then the
received header does not contain ptr info therefore _LASTEXTERNALRDNS_
cannot be set or only set with empty string. That could potentially lead
to fancy dns queries if using the tag in an askdns rule
From my point of view it would be very nice to have these two tags set
by default
Cheers
tobi
Am 27.11.19 um 16:18 schrieb Kevin A. McGrail:
> 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 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
>
Re: LASTEXTERNALRDNS and LASTEXTERNALHELO not set in PerMsgStatus.pm ?
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 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
https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: Can someone explain how to read Bayes stats?
On 27.11.19 15:52, Anders Gustafsson wrote: pamir:~ # sa-learn --dump magic 0.000 0 3 0 non-token data: bayes db version 0.000 0 3184 0 non-token data: nspam 0.000 0 17298 0 non-token data: nham 0.000 0 164549 0 non-token data: ntokens 0.000 0 1553643652 0 non-token data: oldest atime 0.000 0 1574862537 0 non-token data: newest atime 0.000 0 1574856320 0 non-token data: last journal sync atime 0.000 0 1574848041 0 non-token data: last expiry atime 0.000 0 0 0 non-token data: last expire atime delta 0.000 0 0 0 non-token data: last expire reduction count I had SA running before, but hd to take a break because of upgrades. I have not had the chance yet to collect over 200 SPAM/HAM messages for training. according to the info above, there was 3184 spams and 17298 hams learned, both over limit. bayes should hit, unless bayes has been turned off, or different account was used for scanning. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Honk if you love peace and quiet.
Can someone explain how to read Bayes stats?
Ie: pamir:~ # sa-learn --dump magic 0.000 0 3 0 non-token data: bayes db version 0.000 0 3184 0 non-token data: nspam 0.000 0 17298 0 non-token data: nham 0.000 0 164549 0 non-token data: ntokens 0.000 0 1553643652 0 non-token data: oldest atime 0.000 0 1574862537 0 non-token data: newest atime 0.000 0 1574856320 0 non-token data: last journal sync atime 0.000 0 1574848041 0 non-token data: last expiry atime 0.000 0 0 0 non-token data: last expire atime delta 0.000 0 0 0 non-token data: last expire reduction count I had SA running before, but hd to take a break because of upgrades. I have not had the chance yet to collect over 200 SPAM/HAM messages for training. -- Anders Gustafsson Engineer, CNI, CNE6, ASE Pedago, The Aaland Islands (N60 E20) www.pedago.fi phone +358 18 12060 mobile +358 40506 7099
Re: shortcircuit on alread x-spam-flag: yes
On 26 Nov 2019, at 08:11, Philipp Ewald wrote: we have "old customer" (with historical terms) there have forwarding rules for any mail and we are not allowed to set SPAM Filter rule or to change the forwarding rules. On 26.11.19 13:22, @lbutlr wrote: Forwarding spam is a good way to be blacklisted as a spam source. This is why I have disabled all forwarding rules. If users want their mail to arrive at another account, they have to pull the mail themselves. (Obviously, most people automate this.) Gmail users have to use POP3 to get the mail, and I only allow POP3 access for specific users and only from google servers (I would gladly allow some other server that can only pull from POP, but no one has asked). there is forwarding and forwarding. There are cases where your front-end mailserver scans the mail for spam and viruses, and forwards it into a backend. Sometimes customers on those backends only want to tag. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I feel like I'm diagonally parked in a parallel universe.
LASTEXTERNALRDNS and LASTEXTERNALHELO not set in PerMsgStatus.pm ?
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
