You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by piecka <te...@gmail.com> on 2019/03/20 13:04:35 UTC
Re: No longer just embedded =9D characters in blackmail emails.
Hello
We've encountered a high false positive rate with MIXED_ES rule for emails
written in Czech language. Czech naturally uses all of the e,ě and é.
The situation is similar for Slovak language, which includes e and é.
It seems the same with Greek
(https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7691).
Email messages written in one of the above mentioned (probably even other)
languages have a much higher false positive rate than I would consider
acceptable.
Additionally, the default score for the rule is 3.999 which is quite high.
I don't think the rule is suitable for the default ruleset in the current
form.
--
Sent from: http://spamassassin.1065346.n5.nabble.com/SpamAssassin-Users-f3.html
Re: No longer just embedded =9D characters in blackmail emails.
Posted by Marcin Mirosław <ma...@mejor.pl>.
W dniu 20.03.2019 o 15:27, Dominic Raferd pisze:
> On Wed, 20 Mar 2019 at 13:14, piecka <te...@gmail.com> wrote:
>>
>> Hello
>>
>> We've encountered a high false positive rate with MIXED_ES rule for emails
>> written in Czech language. Czech naturally uses all of the e,ě and é.
>>
>> The situation is similar for Slovak language, which includes e and é.
>>
>> It seems the same with Greek
>> (https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7691).
>>
>> Email messages written in one of the above mentioned (probably even other)
>> languages have a much higher false positive rate than I would consider
>> acceptable.
>>
>> Additionally, the default score for the rule is 3.999 which is quite high.
>>
>> I don't think the rule is suitable for the default ruleset in the current
>> form.
>
> I have seen similar problems and agree. I reduced its score with this
> line in /etc/spamassassin/local.cf:
> score MIXED_ES 0.499
>
MIXED_ES has hits in ham in masscheck
https://ruleqa.spamassassin.org/20190317-r1855682-n/MIXED_ES/detail
part of ham mails in corpus which trigger MIXED_ES is in polish language.
Re: No longer just embedded =9D characters in blackmail emails.
Posted by Dominic Raferd <do...@timedicer.co.uk>.
On Wed, 20 Mar 2019 at 13:14, piecka <te...@gmail.com> wrote:
>
> Hello
>
> We've encountered a high false positive rate with MIXED_ES rule for emails
> written in Czech language. Czech naturally uses all of the e,ě and é.
>
> The situation is similar for Slovak language, which includes e and é.
>
> It seems the same with Greek
> (https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7691).
>
> Email messages written in one of the above mentioned (probably even other)
> languages have a much higher false positive rate than I would consider
> acceptable.
>
> Additionally, the default score for the rule is 3.999 which is quite high.
>
> I don't think the rule is suitable for the default ruleset in the current
> form.
I have seen similar problems and agree. I reduced its score with this
line in /etc/spamassassin/local.cf:
score MIXED_ES 0.499
Re: No longer just embedded =9D characters in blackmail emails.
Posted by Grant Taylor <gt...@tnetconsulting.net>.
On 3/20/19 7:04 AM, piecka wrote:
> We've encountered a high false positive rate with MIXED_ES rule for emails
> written in Czech language … Slovak … Greek …
Do the MIME headers have any indication of the language?
Can you use create a __test rule that is then used in a meta rule with
MIXED_ES?
--
Grant. . . .
unix || die
Re: No longer just embedded =9D characters in blackmail emails.
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 20 Mar 2019, at 18:26, Benny Pedersen wrote:
> Bill Cole skrev den 2019-03-20 20:19:
>
>> lang pl score MIXED_ES 0.01
>> lang cz score MIXED_ES 0.01
>> lang sk score MIXED_ES 0.01
>> lang hr score MIXED_ES 0.01
>> lang el score MIXED_ES 0.01
>>
>> Those should get into the default rules channel within a few days.
>
> is lang supporing rule scores at all ?
>
> imho lang only support description
Opinions are things about which it is good to be humble...
Documented and demonstrable functionality is something else. It is
neither humble nor proud, it just IS:
# grep -r LOCALE_IS_EN /etc/mail/spamassassin/
/etc/mail/spamassassin/90_lang.cf:lang en describe LOCALE_IS_EN What
it says
/etc/mail/spamassassin/90_lang.cf:lang en meta LOCALE_IS_EN 1
/etc/mail/spamassassin/90_lang.cf:lang en score LOCALE_IS_EN 0.001
# spamassassin -D all < ~/testmail.good 2>&1 |grep LOCALE_IS_EN
Mar 20 19:02:11.266 [59189] dbg: check:
tests=AWL,BAYES_40,LOCALE_IS_EN,NO_RECEIVED,NO_RELAYS,SCC_DEBUG,SCC_DEBUG_RAW_LINE,SCC_DEBUG_UP,SCC_DEBUG_WL,T_SCC_BODY_TEXT_LINE
* 0.0 LOCALE_IS_EN What it says
X-Spam-Status: No, score=-1.0 required=5.0
tests=AWL,BAYES_40,LOCALE_IS_EN,
> what score is then for none listed lang ?, default to 1.0 ?
MIXED_ES is scored by Rule QA. See the message you replied to for its
current score (as of r1855811.)
'perldoc Mail::SpamAssassin::Conf' is your friend, although I guess it
might seem friendlier were it in Danish...
Re: No longer just embedded =9D characters in blackmail emails.
Posted by Benny Pedersen <me...@junc.eu>.
Bill Cole skrev den 2019-03-20 20:19:
> lang pl score MIXED_ES 0.01
> lang cz score MIXED_ES 0.01
> lang sk score MIXED_ES 0.01
> lang hr score MIXED_ES 0.01
> lang el score MIXED_ES 0.01
>
> Those should get into the default rules channel within a few days.
is lang supporing rule scores at all ?
imho lang only support description
what score is then for none listed lang ?, default to 1.0 ?
Re: No longer just embedded =9D characters in blackmail emails.
Posted by Fedor Piecka <te...@gmail.com>.
Hello Bill
I can show a few messages triggering the rule in our case but only for you
to see the use of accented characters in Czech language. I'm unable to
grant you a permission to upload them to masscheck corpus or to any other
public/semipublic database. The messages contain no classified information,
but they include names and email addresses of our users and our business
partners. It would be difficult to anonymize them and still keep their
value.
To be honest, the rule fires at low frequency even in our system which
deals with Slovak and Czech languages all the time. Most people in here
write emails with ASCII characters only and don't use accents etc. However,
some do (e.g. I do - UTF-8 works in most email clients, so why not). I
found the rule while searching through logs for messages which had scored
too close to the spam threshold and are therefore close to being
misclassified.
I can see 9 messages received in the last 10 days firing the rule and all
of them are Atlassian Jira notifications from our Czech business partner.
Although after doing sa-update, they score pretty low as MIXED_ES has now a
score of 0.5.
Shall I provide you the respective messages?
št 21. 3. 2019 o 16:34 Bill Cole <sa...@billmail.scconsult.com>
napísal(a):
> On 21 Mar 2019, at 10:52, John Wilcock wrote:
>
> > Le 21/03/2019 à 14:52, John Wilcock a écrit :
> >> Le 20/03/2019 à 20:19, Bill Cole a écrit :
> >>> I've added these lines to the block that defines MIXED_ES which may
> >>> help some sites:
> >>>
> >>> lang pl score MIXED_ES 0.01
> >>> lang cz score MIXED_ES 0.01
> >>> lang sk score MIXED_ES 0.01
> >>> lang hr score MIXED_ES 0.01
> >>> lang el score MIXED_ES 0.01
> >>>
> >>> Those should get into the default rules channel within a few days.
> >>
> >> All very well, except [...]
> > Also, there are *lots* of other languages that legitimately use E-like
> > characters that should be added to the list (e.g. there's a Cyrillic
> > "е", so you can add ru, bg, uk, be, bs, sr, kk, ky, mn, tg and
> > others, for a start; ). You'll be fighting a losing battle there...
>
> Actually not a battle I'm fighting...
>
> I have seen direct reports of this rule (which is substantially more
> narrow than just 'has mixed e-like characters') matching ham in the
> above listed languages. I know that on the order of 0.001% of ham in the
> masscheck data submitted to SA Rule QA match the rule and that the bulk
> of that is from a single small corpus (from a Polish source) in which
> ~0.5% of ham matches. It appears that occasionally that match rate
> results in a classification false positive, which is a real but small
> and constraijned problem.
>
> I have never seen an actual ham message matching the rule, much less had
> access to a mail stream including a steady stream of such messages. I
> have only ever seen vague reports of classification FPs, all of which
> cite the score as 3.999, which has not been accurate for most of the
> lifetime of the rule. As such, I have no real weapons in this battle and
> a foe who is invisible but noisy, to overstretch your analogy.
>
> Individual sites are always free to kill or redefine rules from the
> default set or peg their scores to limit FPs.
>
> --
> Bill Cole
> bill@scconsult.com or billcole@apache.org
> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
> Available For Hire: https://linkedin.com/in/billcole
>
Re: No longer just embedded =9D characters in blackmail emails.
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 21 Mar 2019, at 10:52, John Wilcock wrote:
> Le 21/03/2019 à 14:52, John Wilcock a écrit :
>> Le 20/03/2019 à 20:19, Bill Cole a écrit :
>>> I've added these lines to the block that defines MIXED_ES which may
>>> help some sites:
>>>
>>> lang pl score MIXED_ES 0.01
>>> lang cz score MIXED_ES 0.01
>>> lang sk score MIXED_ES 0.01
>>> lang hr score MIXED_ES 0.01
>>> lang el score MIXED_ES 0.01
>>>
>>> Those should get into the default rules channel within a few days.
>>
>> All very well, except [...]
> Also, there are *lots* of other languages that legitimately use E-like
> characters that should be added to the list (e.g. there's a Cyrillic
> "е", so you can add ru, bg, uk, be, bs, sr, kk, ky, mn, tg and
> others, for a start; ). You'll be fighting a losing battle there...
Actually not a battle I'm fighting...
I have seen direct reports of this rule (which is substantially more
narrow than just 'has mixed e-like characters') matching ham in the
above listed languages. I know that on the order of 0.001% of ham in the
masscheck data submitted to SA Rule QA match the rule and that the bulk
of that is from a single small corpus (from a Polish source) in which
~0.5% of ham matches. It appears that occasionally that match rate
results in a classification false positive, which is a real but small
and constraijned problem.
I have never seen an actual ham message matching the rule, much less had
access to a mail stream including a steady stream of such messages. I
have only ever seen vague reports of classification FPs, all of which
cite the score as 3.999, which has not been accurate for most of the
lifetime of the rule. As such, I have no real weapons in this battle and
a foe who is invisible but noisy, to overstretch your analogy.
Individual sites are always free to kill or redefine rules from the
default set or peg their scores to limit FPs.
--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole
Re: No longer just embedded =9D characters in blackmail emails.
Posted by Savvas Karagiannidis <ka...@dataways.gr>.
On 21/3/2019 18:23, John Hardin wrote:
> On Thu, 21 Mar 2019, Savvas Karagiannidis wrote:
>
>> What should be considered is the message's language. All messages
>> that were false positives had the following mime encoding (messages
>> were actually in greek):
>>
>> Content-Type: text/[plain|html]; charset="windows-1253" or
>> Content-Type: text/[plain|html]; charset="iso-8859-7"
>>
>> while all messages that were actual spam and were properly detected had:
>>
>> Content-Type: text/[plain|html]; charset="utf-8"
>
> It should be fairly easy to add an exclusion based on that
> information. However, that information may well be leveraged by
> spammers who are using that obfuscation...
>
I think the same applies to the rule itself altogether and any other
rule. As long as the rule is out there, any spammer can incorporate a
means to avoid it. I guess the selection of "e" as a character is also
pretty random and avoiding that and applying the same technique to other
characters (I've already seen it happening) not detected by this rule
should be no problem for spammers...
--
Savvas Karagiannidis
Re: No longer just embedded =9D characters in blackmail emails.
Posted by "@lbutlr" <kr...@kreme.com>.
On 21 Mar 2019, at 14:27, John Hardin <jh...@impsec.org> wrote:
> On Thu, 21 Mar 2019, Martin Gregorie wrote:
>> On Thu, 2019-03-21 at 12:20 -0700, John Hardin wrote:
>>>
>>> ...wrong thread? :)
>> Unfortunately so. For some reason my mail reader's editor (I use
>> Evolution) locked up on my first attempt to reply and when I got it to
>> respond it again it sent the stupid message containing one blank line.
>>
>> Then I screwed up by making a second reply attempt to the wrong
>> message. Must do better :-/
> ...and it's not even Monday.
It's always Monday somewhere.
--
O is for OLIVE run through with an awl
P is for PRUE trampled flat in a brawl
Re: No longer just embedded =9D characters in blackmail emails.
Posted by John Hardin <jh...@impsec.org>.
On Thu, 21 Mar 2019, Martin Gregorie wrote:
> On Thu, 2019-03-21 at 12:20 -0700, John Hardin wrote:
>>
>> ...wrong thread? :)
>>
> Unfortunately so. For some reason my mail reader's editor (I use
> Evolution) locked up on my first attempt to reply and when I got it to
> respond it again it sent the stupid message containing one blank line.
>
> Then I screwed up by making a second reply attempt to the wrong
> message. Must do better :-/
...and it's not even Monday.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
How do you argue with people to whom math is an opinion? -- Unknown
-----------------------------------------------------------------------
721 days since the first commercial re-flight of an orbital booster (SpaceX)
Re: No longer just embedded =9D characters in blackmail emails.
Posted by Martin Gregorie <ma...@gregorie.org>.
On Thu, 2019-03-21 at 12:20 -0700, John Hardin wrote:
>
> ...wrong thread? :)
>
Unfortunately so. For some reason my mail reader's editor (I use
Evolution) locked up on my first attempt to reply and when I got it to
respond it again it sent the stupid message containing one blank line.
Then I screwed up by making a second reply attempt to the wrong
message. Must do better :-/
Martin
Re: No longer just embedded =9D characters in blackmail emails.
Posted by John Hardin <jh...@impsec.org>.
On Thu, 21 Mar 2019, Martin Gregorie wrote:
> On Thu, 2019-03-21 at 09:23 -0700, John Hardin wrote:
>> On Thu, 21 Mar 2019, Savvas Karagiannidis wrote:
>>
>>> What should be considered is the message's language. All messages
>>> that were
>>> false positives had the following mime encoding (messages were
>>> actually in
>>> greek):
>>>
>>> Content-Type: text/[plain|html]; charset="windows-1253" or
>>> Content-Type: text/[plain|html]; charset="iso-8859-7"
>>>
>>> while all messages that were actual spam and were properly detected
>>> had:
>>>
>>> Content-Type: text/[plain|html]; charset="utf-8"
>>
>> It should be fairly easy to add an exclusion based on that
>> information.
>> However, that information may well be leveraged by spammers who are
>> using that obfuscation...
>
> FWIW roughly 10% of my spam corpus uses <font> tags to set white text.
...wrong thread? :)
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
...the Constitution and the Bill of Rights exists to protect
the individual, not the mob. -- Matt Pickering
-----------------------------------------------------------------------
721 days since the first commercial re-flight of an orbital booster (SpaceX)
Re: No longer just embedded =9D characters in blackmail emails.
Posted by Martin Gregorie <ma...@gregorie.org>.
On Thu, 2019-03-21 at 09:23 -0700, John Hardin wrote:
> On Thu, 21 Mar 2019, Savvas Karagiannidis wrote:
>
> > What should be considered is the message's language. All messages
> > that were
> > false positives had the following mime encoding (messages were
> > actually in
> > greek):
> >
> > Content-Type: text/[plain|html]; charset="windows-1253" or
> > Content-Type: text/[plain|html]; charset="iso-8859-7"
> >
> > while all messages that were actual spam and were properly detected
> > had:
> >
> > Content-Type: text/[plain|html]; charset="utf-8"
>
> It should be fairly easy to add an exclusion based on that
> information.
> However, that information may well be leveraged by spammers who are
> using that obfuscation...
>
FWIW roughly 10% of my spam corpus uses <font> tags to set white text.
The ratio of using "white" to "#ffffff" to 1/3 - 2/3. I should say that
some of these messages are quite old - I keep them as test data when
I'm writing new rules: they are NOT used for Bayes training.
My mail archive contains 192540 messages in theory it contains no spam
apart, that is, from a small amount of spam eeled its way in. 145
messages in it contain 'color="white"' and 2293 contain
'color="#ffffff"' The combination makes up 1.27% of the archived
messages.
My take is that so it would appear that it may deserve a small score,
but it is probably best used as a subrule.
Martin
Re: No longer just embedded =9D characters in blackmail emails.
Posted by John Hardin <jh...@impsec.org>.
On Thu, 21 Mar 2019, Savvas Karagiannidis wrote:
> What should be considered is the message's language. All messages that were
> false positives had the following mime encoding (messages were actually in
> greek):
>
> Content-Type: text/[plain|html]; charset="windows-1253" or
> Content-Type: text/[plain|html]; charset="iso-8859-7"
>
> while all messages that were actual spam and were properly detected had:
>
> Content-Type: text/[plain|html]; charset="utf-8"
It should be fairly easy to add an exclusion based on that information.
However, that information may well be leveraged by spammers who are using
that obfuscation...
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
USMC Rules of Gunfighting #2: Anything worth shooting
is worth shooting twice. Ammo is cheap. Your life is expensive.
-----------------------------------------------------------------------
721 days since the first commercial re-flight of an orbital booster (SpaceX)
Re: No longer just embedded =9D characters in blackmail emails.
Posted by Savvas Karagiannidis <ka...@dataways.gr>.
Hi all,
I'd like to thank you Bill for looking into this. I was a bit
disappointed by the way the issue was handled at first on bugzilla.
I must agree that the server's locale could be information to be
considered but I don't think it solves the issue. I agree that this test
is effective on catching the type of spam it was intended for. I found a
number of spam messages caught by this while investigating the issue.
What should be considered is the message's language. All messages that
were false positives had the following mime encoding (messages were
actually in greek):
Content-Type: text/[plain|html]; charset="windows-1253" or
Content-Type: text/[plain|html]; charset="iso-8859-7"
while all messages that were actual spam and were properly detected had:
Content-Type: text/[plain|html]; charset="utf-8"
I'm afraid I cannot provide any sample of the false positives at the moment.
Hope the above helps. Spamassassin is a great project and we are trying
to help improve it
--
Savvas Karagiannidis
On 21/3/2019 16:52, John Wilcock wrote:
> Le 21/03/2019 à 14:52, John Wilcock a écrit :
>> Le 20/03/2019 à 20:19, Bill Cole a écrit :
>>> I've added these lines to the block that defines MIXED_ES which may
>>> help some sites:
>>>
>>> lang pl score MIXED_ES 0.01
>>> lang cz score MIXED_ES 0.01
>>> lang sk score MIXED_ES 0.01
>>> lang hr score MIXED_ES 0.01
>>> lang el score MIXED_ES 0.01
>>>
>>> Those should get into the default rules channel within a few days.
>>
>> All very well, except [...]
> Also, there are *lots* of other languages that legitimately use E-like
> characters that should be added to the list (e.g. there's a Cyrillic
> "е", so you can add ru, bg, uk, be, bs, sr, kk, ky, mn, tg and others,
> for a start; ). You'll be fighting a losing battle there...
>
Re: No longer just embedded =9D characters in blackmail emails.
Posted by John Wilcock <jo...@tradoc.fr>.
Le 21/03/2019 à 14:52, John Wilcock a écrit :
> Le 20/03/2019 à 20:19, Bill Cole a écrit :
>> I've added these lines to the block that defines MIXED_ES which may
>> help some sites:
>>
>> lang pl score MIXED_ES 0.01
>> lang cz score MIXED_ES 0.01
>> lang sk score MIXED_ES 0.01
>> lang hr score MIXED_ES 0.01
>> lang el score MIXED_ES 0.01
>>
>> Those should get into the default rules channel within a few days.
>
> All very well, except [...]
Also, there are *lots* of other languages that legitimately use E-like
characters that should be added to the list (e.g. there's a Cyrillic
"е", so you can add ru, bg, uk, be, bs, sr, kk, ky, mn, tg and others,
for a start; ). You'll be fighting a losing battle there...
--
John
Re: No longer just embedded =9D characters in blackmail emails.
Posted by John Wilcock <jo...@tradoc.fr>.
Le 20/03/2019 à 20:19, Bill Cole a écrit :
> I've added these lines to the block that defines MIXED_ES which may help
> some sites:
>
> lang pl score MIXED_ES 0.01
> lang cz score MIXED_ES 0.01
> lang sk score MIXED_ES 0.01
> lang hr score MIXED_ES 0.01
> lang el score MIXED_ES 0.01
>
> Those should get into the default rules channel within a few days.
All very well, except that this makes the score depend on the locale of
the user running SA, which (depending on the glue used) will typically
NOT match the language(s) understood by the email recipient, let alone
the language(s) liable to be used by senders. Why should a perfectly
legitimate message written in Polish be penalised because the server
locale is set to English?
[That was a rhetorical question, of course – I realise that any rule
hitting on "foreign" characters used for obfuscation is inherently risky
for messages written in languages which actually use those characters]
A slightly better solution might be to modify the scores based on the
value of ok_locales. That would at least allow administrators some
control over which languages are most acceptable for their users.
However, AFAICT, that could only be done today using an eval test.
--
John
Re: No longer just embedded =9D characters in blackmail emails.
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 20 Mar 2019, at 9:04, piecka wrote:
> Hello
>
> We've encountered a high false positive rate with MIXED_ES rule for
> emails
> written in Czech language. Czech naturally uses all of the e,ě and
> é.
>
> The situation is similar for Slovak language, which includes e and é.
>
> It seems the same with Greek
> (https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7691).
>
> Email messages written in one of the above mentioned (probably even
> other)
> languages have a much higher false positive rate than I would consider
> acceptable.
I apologize for this: I am the instigator of MIXED_ES, which has done a
good job of catching the extortion spam it was designed from and has an
additional benefit of targeting a generic tactic rather than the moving
target of phrasing. I would very much like to minimize how often it
matches on ham.
Unfortunately, I don't have any examples of FPs, only reports of them.
This makes targeted mitigation very difficult. The Rule QA system has
masscheck reports of a steady but small number of hits on ham, almost
all from a single smallish corpus and no more than one message in any
recent masscheck actually scoring as spam overall.
I've added these lines to the block that defines MIXED_ES which may help
some sites:
lang pl score MIXED_ES 0.01
lang cz score MIXED_ES 0.01
lang sk score MIXED_ES 0.01
lang hr score MIXED_ES 0.01
lang el score MIXED_ES 0.01
Those should get into the default rules channel within a few days.
> Additionally, the default score for the rule is 3.999 which is quite
> high.
The current score quartet (as determined by the Rule QA system) is
'2.791 2.699 2.791 2.699' and the last time any of those scores was
3.999 was 3 March. If your system is scoring it at 3.999, you should be
running sa-update more often.
Also, I think it should be understood that nearly all SA rules with a
positive score will match some 'ham' messages. These are "false
positives" for the individual rule, but usually they are NOT false
positives for SpamAssassin as a whole.