Re: regexp dealing with display name don't work

[John Hardin]

On Fri, 27 Apr 2018, Joëlle Pfeffer wrote:


To answer John Harding, here are some display names that I want to block :

"@ADMIN"
"@WEB-SUPPORT"
"@SUPPORT ADMIN"
"@webmaster"


Is the @ at the beginning of the name part in all cases? Try this:

  header  FROM_NAME_PREFIX_ATSIGN   From:name =~ /^\@/


--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  ...the good of having the government prohibited from doing harm
  far outweighs the harm of having it obstructed from doing good.
   -- Mike@mike-istan
---
 4 days until May Day - Remember 110 million people murdered by Communism

Re: regexp dealing with display name don't work

[John Hardin]

On Fri, 27 Apr 2018, Joëlle Pfeffer wrote:


Hi David,

Thank you for your answer.

I don't think I have to escape the @ character.


You do.


It is recognized without being escaped since
when my rule is : From:name =~ /@.b/i


The period is changing the interpretation of the @ sign.


--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  ...the good of having the government prohibited from doing harm
  far outweighs the harm of having it obstructed from doing good.
   -- Mike@mike-istan
---
 4 days until May Day - Remember 110 million people murdered by Communism

Re: regexp dealing with display name don't work

[Bill Cole]

On 27 Apr 2018, at 16:27, Joëlle Pfeffer wrote:


Hi David,

Thank you for your answer.

I don't think I have to escape the @ character.


Yes, you do, if you want to match a character following it that could be 
the first character in an unreserved variable name (letter or 
underscore) or is an existing Perl special variable. The reason '@.' 
works unescaped is that it cannot be a user-defined variable and it 
isn't a Perl special variable, so Perl does not parse it as an array 
variable.



It is recognized without being escaped since
when my rule is : From:name =~ /@.b/i
the display names consisting of @Ab or @Abc hit.

It seems as if the character following the @ is not recognized except 
if it is a full stop.


No. You just happened to test a character after the unescaped @ that 
isn't the first character of the name of any special Perl variable and 
can't be the first character of a user-defined variable name. It would 
also work with digits and most other symbols.


SpamAssassin rules also must escape $ or %, which are the other 
characters Perl uses before variable names to indicate that they are 
variable names.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole

Re: Dropping mail

[Dianne Skoll]

On Fri, 27 Apr 2018 15:18:28 -0500 (CDT)
David B Funk  wrote:

> If you have that many different classes of recipients, just set the
> number of allowed recipients/transaction to one and be done with it.

That will cause mail failures.  It's not *supposed* to, but I know
from experience it will.  Some MTAs limit the number of retries to a
ridiculously low number like 10 or 20 and then give up.

Regards,

Dianne.

regexp dealing with display name don't work

[Joëlle Pfeffer]

To answer John Harding, here are some display names that I want to block : 

"@ADMIN" 
"@WEB-SUPPORT" 
"@SUPPORT ADMIN" 
"@webmaster" 

I think I already tried to escape the @ character but it didn't work better. I 
will try again. 

Cordialement, 

Joëlle Pfeffer, Cheffe de projet DINSI/Infrastructures 
Conseil Départemental de Seine-Saint-Denis 
33 (0)1 43 93 97 58 

Ce message et toutes les pièces jointes sont établis à l'intention exclusive de 
ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, 
merci de le détruire et d'en avertir immédiatement l'expéditeur. Toute 
utilisation de ce message non conforme à sa destination, toute diffusion ou 
toute publication, totale ou partielle, est interdite sauf autorisation 
expresse.
L'internet ne permettant pas d'assurer l'intégrité de ce message, le Conseil 
Départemental de Seine-Saint-Denis décline toute responsabilité au titre de ce 
message, dans l'hypothèse où il aurait été modifié. D'autre part, le Conseil 
Départemental de Seine-Saint-Denis ne reconnait exclusivement que les 
délégations de signatures écrites par les personnes habilitées et ne peut donc 
être engagé par un message électronique

Re: regexp dealing with display name don't work

[Joëlle Pfeffer]

Hi David, 

Thank you for your answer. 

I don't think I have to escape the @ character. 
It is recognized without being escaped since 
when my rule is : From:name =~ /@.b/i 
the display names consisting of @Ab or @Abc hit. 

It seems as if the character following the @ is not recognized except if it is 
a full stop. 

However I will try to escape the @. I think I tried it among many other things 
and it didn't worked but I will try again. 

Cordialement, 

Joëlle Pfeffer, Cheffe de projet DINSI/Infrastructures 
Conseil Départemental de Seine-Saint-Denis 
33 (0)1 43 93 97 58 

- Mail original -

De: "David B Funk"  
À: "Joëlle Pfeffer"  
Cc: users@spamassassin.apache.org 
Envoyé: Vendredi 27 Avril 2018 22:09:01 
Objet: Re: regexp dealing with display name don't work 

On Fri, 27 Apr 2018, Joëlle Pfeffer wrote: 

> I have progressed. 
> 
> If my rule is 
> header REGLE_HF002 From:name =~ /@A/i 
> 
> e-mails containing 
> From: @A  
> or 
> From: "@AB"  
> or 
> From: "@Ab"  
> are not blocked 
> 
> but if my rule is 
> header REGLE_HF002 From:name =~ /@.b/i 
> 
> e-mails containing 
> From: "@Ab"  
> or 
> From: "@ABc" < jopfef...@free.fr > 
> are blocked 
[snip..] 

If you want to match a literal '@' in a SA regex you need to escape it. 
Try: 
header REGLE_HF002 From:name =~ /\@a/i 

(note the trailing 'i' makes the regex be case-insenstive so /\@A/i doesn't 
make 
sense). 


-- 
Dave Funk University of Iowa 
 College of Engineering 
319/335-5751 FAX: 319/384-0549 1256 Seamans Center 
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527 
#include  
Better is not better, 'standard' is better. B{ 


Ce message et toutes les pièces jointes sont établis à l'intention exclusive de 
ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, 
merci de le détruire et d'en avertir immédiatement l'expéditeur. Toute 
utilisation de ce message non conforme à sa destination, toute diffusion ou 
toute publication, totale ou partielle, est interdite sauf autorisation 
expresse.
L'internet ne permettant pas d'assurer l'intégrité de ce message, le Conseil 
Départemental de Seine-Saint-Denis décline toute responsabilité au titre de ce 
message, dans l'hypothèse où il aurait été modifié. D'autre part, le Conseil 
Départemental de Seine-Saint-Denis ne reconnait exclusivement que les 
délégations de signatures écrites par les personnes habilitées et ne peut donc 
être engagé par un message électronique

Re: Dropping mail

[David B Funk]

On Fri, 27 Apr 2018, Dianne Skoll wrote:


On Fri, 27 Apr 2018 14:39:43 -0500 (CDT)
David B Funk  wrote:

[snip]


Define two classes of recipients:
   class A == all users who want everything
   class B == all users who want "standard" filtering


This works if you have a limited number of classes, but in some cases
users can make their own rules and settings so the number of classes
can be the same as the number of RCPTs.

Even in the two-class case, there's still a delay for the subsequent
class(es).


If you have that many different classes of recipients, just set the number of 
allowed recipients/transaction to one and be done with it.


The delay is entirely up to the sending side, they could immediately retry the 
subsequent recipients.


I was just trying to suggest a solution to your conundrum that didn't require 
you to drop messages. I didn't say it was optimal, just avoiding the loss of 
messages.



--
Dave Funk  University of Iowa
College of Engineering
319/335-5751   FAX: 319/384-0549   1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include 
Better is not better, 'standard' is better. B{

Re: regexp dealing with display name don't work

[John Hardin]

On Fri, 27 Apr 2018, David B Funk wrote:

(note the trailing 'i' makes the regex be case-insenstive so /\@A/i doesn't 
make sense).


...it makes precisely as much sense as /\@a/i does... :)

--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  Teach a man to fish, and he'll eat for life.
  Give him someone else's fish, and he'll vote for you.
---
 4 days until May Day - Remember 110 million people murdered by Communism

Re: regexp dealing with display name don't work

[David B Funk]

On Fri, 27 Apr 2018, Joëlle Pfeffer wrote:


I have progressed.

If my rule is
header REGLE_HF002 From:name =~ /@A/i

e-mails containing
From: @A 
or
From: "@AB" 
or
From: "@Ab" 
are not blocked

but if my rule is
header REGLE_HF002 From:name =~ /@.b/i

e-mails containing
From: "@Ab" 
or
From: "@ABc" < jopfef...@free.fr >
are blocked

[snip..]

If you want to match a literal '@' in a SA regex you need to escape it.
Try:
  header REGLE_HF002 From:name =~ /\@a/i

(note the trailing 'i' makes the regex be case-insenstive so /\@A/i doesn't make 
sense).



--
Dave Funk  University of Iowa
College of Engineering
319/335-5751   FAX: 319/384-0549   1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include 
Better is not better, 'standard' is better. B{

Re: regexp dealing with display name don't work

[John Hardin]

On Fri, 27 Apr 2018, Joëlle Pfeffer wrote:


I have progressed.

If my rule is
header REGLE_HF002 From:name =~ /@A/i

e-mails containing
From: @A < jopfef...@free.fr >
or
From: "@AB" < jopfef...@free.fr >
or
From: "@Ab" < jopfef...@free.fr >
are not blocked

but if my rule is
header REGLE_HF002 From:name =~ /@.b/i

e-mails containing
From: "@Ab" < jopfef...@free.fr >
or
From: "@ABc" < jopfef...@free.fr >
are blocked


If you *are* explicitly looking for @-sign in the from name, you need to 
escape the @ sign:


  warn:  (Global symbol "@I" requires explicit package name (did you forget to declare 
"my @I"?) at /home/jhardin/develop/spamassassin/testing/test.cf, rule __FROM_NAME_TEST, 
line 1.)

Try this:

  header REGLE_HF002 From:name =~ /\@A/i

--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  Teach a man to fish, and he'll eat for life.
  Give him someone else's fish, and he'll vote for you.
---
 4 days until May Day - Remember 110 million people murdered by Communism

Re: regexp dealing with display name don't work

[John Hardin]

On Fri, 27 Apr 2018, Joëlle Pfeffer wrote:


I have progressed.

If my rule is
header REGLE_HF002 From:name =~ /@A/i

e-mails containing
From: @A < jopfef...@free.fr >
or
From: "@AB" < jopfef...@free.fr >
or
From: "@Ab" < jopfef...@free.fr >
are not blocked

but if my rule is
header REGLE_HF002 From:name =~ /@.b/i

e-mails containing
From: "@Ab" < jopfef...@free.fr >
or
From: "@ABc" < jopfef...@free.fr >
are blocked


Are you specifically looking for from name that has an @-sign in it?

Please provide a complete example of a real From header that you want to 
match.



--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  You do not examine legislation in the light of the benefits it
  will convey if properly administered, but in the light of the
  wrongs it would do and the harms it would cause if improperly
  administered.  -- Lyndon B. Johnson
---
 4 days until May Day - Remember 110 million people murdered by Communism

Re: Dropping mail

[Dianne Skoll]

On Fri, 27 Apr 2018 14:39:43 -0500 (CDT)
David B Funk  wrote:

[snip]

> Define two classes of recipients:
>class A == all users who want everything
>class B == all users who want "standard" filtering

This works if you have a limited number of classes, but in some cases
users can make their own rules and settings so the number of classes
can be the same as the number of RCPTs.

Even in the two-class case, there's still a delay for the subsequent
class(es).

Regards,

Dianne.

Re: Dropping mail

[David B Funk]

On Fri, 27 Apr 2018, Dianne Skoll wrote:


Hi,

I have reluctantly come to the conclusion that in some cases, it is
necessary to silently drop spam rather than reject it.  This is the
situation:

An email comes in for two recipients in one SMTP trasaction (ie,
a MAIL, two RCPTs and then DATA).

One recipient's rules say to accept.  The other recipient's says to reject.

You can't reject post-DATA because then it looks like both recipients
received the mail.

You can accept and create a failure message for one recipient, but then
you risk generating backscatter.

You can tempfail all but the first RCPT to force the message to be
split up into individual messages per recipient, allowing you to accept
or reject individually.  But this will delay mail and possibly cause it
not to be delivered if there are many recipients and the sending relay
is impatient.

So I reluctantly conclude that in all but the smallest of installations,
dropping the mail for the recipient whose rules say to do so is the
best thing to do.

There have been SMTP extensions proposed to combat this.  I recall an
extension that had you issue RCPTs until one of the RCPTs was
accepted, then DATA, then additional RCPTs with a "also send the
foregoing to this one" keyword so you could have per-recipient data
filtering, but of course spammers could not be obliged to use the
extension. :(


One possible way to deal with this situation (which would require some additional 
complexity on the server and require good behavior on the senders) is:


Define two classes of recipients:
  class A == all users who want everything
  class B == all users who want "standard" filtering

At 'RCPT' phase of the SMTP transaction note if the first valid recipient is 
class "A" or class "B", set a flag to remember it.


For each subsequent valid recipient see if their class is the same as the first 
recipient. If not then return a "452 Too many recipients" reply code for that 
one and all subsequent valid recipients.


Ideally the sender should then move on to the DATA phase, complete the 
processing for the first batch of recipients, and then try again for the 
remainder.


If all goes well, this should split up the different classes of recipients into 
separate SMTP transactions allowing for appropriate processing with out loss.


Your classifications can be expanded upon to meet your site requirements but 
the processing logic should be the same.


--
Dave Funk  University of Iowa
College of Engineering
319/335-5751   FAX: 319/384-0549   1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include 
Better is not better, 'standard' is better. B{

regexp dealing with display name don't work

[Joëlle Pfeffer]

I have progressed. 

If my rule is 
header REGLE_HF002 From:name =~ /@A/i 

e-mails containing 
From: @A < jopfef...@free.fr > 
or 
From: "@AB" < jopfef...@free.fr > 
or 
From: "@Ab" < jopfef...@free.fr > 
are not blocked 

but if my rule is 
header REGLE_HF002 From:name =~ /@.b/i 

e-mails containing 
From: "@Ab" < jopfef...@free.fr > 
or 
From: "@ABc" < jopfef...@free.fr > 
are blocked 

I can only note that the character following the @ is not efficient except when 
it is a full stop but I don't understand why. 


Cordialement, 

Joëlle Pfeffer, Cheffe de projet DINSI/Infrastructures 
Conseil Départemental de Seine-Saint-Denis 
33 (0)1 43 93 97 58 


Ce message et toutes les pièces jointes sont établis à l'intention exclusive de 
ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, 
merci de le détruire et d'en avertir immédiatement l'expéditeur. Toute 
utilisation de ce message non conforme à sa destination, toute diffusion ou 
toute publication, totale ou partielle, est interdite sauf autorisation 
expresse.
L'internet ne permettant pas d'assurer l'intégrité de ce message, le Conseil 
Départemental de Seine-Saint-Denis décline toute responsabilité au titre de ce 
message, dans l'hypothèse où il aurait été modifié. D'autre part, le Conseil 
Départemental de Seine-Saint-Denis ne reconnait exclusivement que les 
délégations de signatures écrites par les personnes habilitées et ne peut donc 
être engagé par un message électronique

Dropping mail

[Dianne Skoll]

Hi,

I have reluctantly come to the conclusion that in some cases, it is
necessary to silently drop spam rather than reject it.  This is the
situation:

An email comes in for two recipients in one SMTP trasaction (ie,
a MAIL, two RCPTs and then DATA).

One recipient's rules say to accept.  The other recipient's says to reject.

You can't reject post-DATA because then it looks like both recipients
received the mail.

You can accept and create a failure message for one recipient, but then
you risk generating backscatter.

You can tempfail all but the first RCPT to force the message to be
split up into individual messages per recipient, allowing you to accept
or reject individually.  But this will delay mail and possibly cause it
not to be delivered if there are many recipients and the sending relay
is impatient.

So I reluctantly conclude that in all but the smallest of installations,
dropping the mail for the recipient whose rules say to do so is the
best thing to do.

There have been SMTP extensions proposed to combat this.  I recall an
extension that had you issue RCPTs until one of the RCPTs was
accepted, then DATA, then additional RCPTs with a "also send the
foregoing to this one" keyword so you could have per-recipient data
filtering, but of course spammers could not be obliged to use the
extension. :(

Regards,

Dianne.

Re: dropping other's email(s) as a "best practice" for hosted email?

[John Hardin]

On Fri, 27 Apr 2018, L A Walsh wrote:

Alan Hodgson wrote:

Rejecting the message during receipt causes the sending server to generate 
a bounce. If it's at all functional.


	That used to happen on poorly implemented mailing lists -- a 
delivery error would be bounced back to the email list as a reply that 
would get sent out to all the subscribers.


*used* to happen. Such mis-coding should have been fixed a long time ago, 
and if there's ML software that still does that it is *not* the receiving 
MTA's problem or fault.


	On a list with 10,000 subscribers or more with maybe ~1000 
messages/day, how many people would be getting back mail-delivery failures 
that they could do nothing about.


These days, none should. The ML software should have mechanisms to capture 
those delivery problem reports and disable that subscriber, and/or 
notify them that list messages are failing (though notifying them isn't 
guaranteed if there are problems delivering to them...).



If a given user wants emails to be dropped at the border


I echo the request that you stop misusing the term "dropped" when you 
mean "rejected".


--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  Teach a man to fish, and he'll eat for life.
  Give him someone else's fish, and he'll vote for you.
---
 4 days until May Day - Remember 110 million people murdered by Communism

Re: dropping other's email(s) as a "best practice" for hosted email?

[Matus UHLAR - fantomas]

Alan Hodgson wrote:
Rejecting the message during receipt causes the sending server to 
generate a bounce. If it's at all functional.


On 27.04.18 09:32, L A Walsh wrote:

If a given user wants emails to be dropped at the
border -- that would be fine.  *I* would not mind configuring
a filter that dropped some incoming emails, but if it is
going to make the incoming mail server too slow to handle
per-user options, it might not be doable.


once more:

STOP calling rejection a dropping.
Rejecting is NOT dropping.
They are two different things.

If you try to hand me an envelope, and I will refuse to take it, It is NOT
the same as if I took it and dropped to trash.
The envelope stays in your hands and you are responsible for it.
If you drop it later, it's your problem, not mine.

You are blaming us for how internet communication works for years.

Your rant is completely useless.

--
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.
2B|!2B, that's a question!

Re: dropping other's email(s) as a "best practice" for hosted email?

[L A Walsh]

Alan Hodgson wrote:



Rejecting the message during receipt causes the sending server to 
generate a bounce. If it's at all functional.



That used to happen on poorly implemented mailing
lists -- a delivery error would be bounced back to the 
email list as a reply that would get sent out to all the 
subscribers.  


Would it even be practical to bounce a deliver
failures back to the original poster of the message to the list?

	On a list with 10,000 subscribers or more with maybe 
~1000 messages/day, how many people would be getting back 
mail-delivery failures that they could do nothing about.


Many or most hosted email services provide a
user-controllable spam filter.  The problem is, if an
email is not accepted, rather than being delivered and filtered
by the "per user-filtering", the user can not tailor 
such filters to their own mail.


It preempts the oft needed ability for the user
to judge what is spam and what is not.

I am not suggesting sending a "bounce back message",
but have the default be to do what the user configures
via their account options.

If a given user wants emails to be dropped at the
border -- that would be fine.  *I* would not mind configuring
a filter that dropped some incoming emails, but if it is
going to make the incoming mail server too slow to handle
per-user options, it might not be doable.

Even without per-user options, many servers
that try to do filtering between reading the message 
and sending a response end up having periods of unacceptable

response time.

	NTL, running filters over incoming email when 
the user has explicitly ask for unfiltered email is
reprehensible.  I do my own email filtering on my 
home server.  I find ISP's doing their own filtering and

modification of incoming user messages based
on their criteria to be a very bad situation.

Also, someone mentioned safe-harbor provisions.
Those were designed for websites where material is
hosted for public view on the host's computers. The
wording in the US act applies to those who *publish
information by others* (like a website).  It doesn't
apply to pass-through services like ISP's and
email services.

Email and ISP service has been more held
in line with services provided by the phone company --
that of common carrier status that is predicated
upon NOT inspecting content as it travels through
a carrier's equipment.

That said, different countries will have
different laws, and the laws are changing as 
email-provider demonstrate their ability to monitor

and filter real-time communications.  Some countries
are moving to have email providers be responsible for
filtering or allowing discussion of illegal acts.
That's not a good direction to be going, IMO.

configuring spamassassin

[Matthew Broadhead]

sorry if this question is a bit vague but i am currently unable to ssh 
into my server to get more info.  i am using centos 7 and i have set up 
spamassassin training by scanning messages which are moved into or out 
of the junk folder.  it seems to work ok because database entries are 
being created in the mysql database.  however it seems to have little or 
no effect on the amount of spam coming through.  is it possible it is 
training but not actually using the training data during the scanning?
also i think it was set up to train separately for each individual user. 
 it seems like having common training where everyone's emails are 
scanned using the same bayes data would be more logical as all the email 
users are in the same business.  is this just a matter of setting a 
flag?

Re: FP with URI_TRY_3LD on get.adobe.com

[John Hardin]

On Fri, 27 Apr 2018, Sebastian Arcus wrote:



On 27/04/18 10:49, Sebastian Arcus wrote:
I am getting some FP's with URI_TRY_3LD hitting the url get.adobe.com in 
the body of emails:


Apr 27 10:45:39.330 [32173] dbg: rules: ran uri rule URI_TRY_3LD ==> 
got hit: "http://get.adobe.com;


Would it be possible to add some exception to this rule - as many 
legitimate emails containing invoice attachments in pdf include the above 
url in the body.


It also appears to not like some DHL url's for some reason:

Apr 27 11:02:05.148 [32339] dbg: rules: ran uri rule URI_TRY_3LD ==> got 
hit: "https://mybill.dhl.com;


my{mumble}.mumble.com is targeted. I'll think about that one; the rule 
isn't scored highly and I could see that helping out to detect DHL 
phishing.


--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  the Internal Revenue Service has an "impressive history ... of
  storing [data] carelessly, leaking data through every possible
  conduit, and hiring employees who appear to only marginally prefer
  a career in tax collection over knocking over liquor stores."
-- Reason's J.D. Tuccille
---
 4 days until May Day - Remember 110 million people murdered by Communism

Re: FP with URI_TRY_3LD on get.adobe.com

[Kevin A. McGrail]

 If this is causing the entire mail to be flagged as SPAM, we need to see
the entire FP not just a hit on one rule.  That rule has a max 0.8 score.

Though it does appear to be hitting on more than intended though.

Anyone know what it is supposed to hit because I think it might be hitting
on a lot more than intended?

Regards,
KAM


--
Kevin A. McGrail
Asst. Treasurer & VP Fundraising, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171

On Fri, Apr 27, 2018 at 6:03 AM, Sebastian Arcus 
wrote:

>
> On 27/04/18 10:49, Sebastian Arcus wrote:
>
>> I am getting some FP's with URI_TRY_3LD hitting the url get.adobe.com in
>> the body of emails:
>>
>> Apr 27 10:45:39.330 [32173] dbg: rules: ran uri rule URI_TRY_3LD ==>
>> got hit: "http://get.adobe.com;
>>
>> Would it be possible to add some exception to this rule - as many
>> legitimate emails containing invoice attachments in pdf include the above
>> url in the body.
>>
>
> It also appears to not like some DHL url's for some reason:
>
> Apr 27 11:02:05.148 [32339] dbg: rules: ran uri rule URI_TRY_3LD ==>
> got hit: "https://mybill.dhl.com;
>

Re: FP with URI_TRY_3LD on get.adobe.com

[John Hardin]

On Fri, 27 Apr 2018, Sebastian Arcus wrote:

I am getting some FP's with URI_TRY_3LD hitting the url get.adobe.com in the 
body of emails:


Apr 27 10:45:39.330 [32173] dbg: rules: ran uri rule URI_TRY_3LD ==> got 
hit: "http://get.adobe.com;


Would it be possible to add some exception to this rule - as many legitimate 
emails containing invoice attachments in pdf include the above url in the 
body.


Fixed.

--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  the Internal Revenue Service has an "impressive history ... of
  storing [data] carelessly, leaking data through every possible
  conduit, and hiring employees who appear to only marginally prefer
  a career in tax collection over knocking over liquor stores."
-- Reason's J.D. Tuccille
---
 4 days until May Day - Remember 110 million people murdered by Communism

Re: dropping other's email(s) as a "best practice" for hosted email? (was: "anyone recognize these headers? ...")

[David B Funk]

On Fri, 27 Apr 2018, Matus UHLAR - fantomas wrote:


On 26.04.18 13:41, L A Walsh wrote:

To my way of thinking, dropping someone else's email,
telling the sender the email is being rejected for having
spam-like characteristics and telling the recipient nothing
seems like it might have legal liability for the for the
user potentially missing vital email.


Refusing to take a mail is not dropping. Noone is required by any means to
accept anything because there may be many reasons a mail can't be accepted.


The place where dropping is a risk is if the next-to-last hop is Dain Bramaged 
and doesn't handle SMTP rejects properly.

But that isn't your server's fault, it's the poor service the sender's using.
(unfortunately the sender may not know of that bad link in their chain).

Also it's entirely possible that the NtLH server may strip off useful 
info from the SMTP reject message and leave the poor sender wondering what went 
wrong. (I'm looking at you MS Exchange).



--
Dave Funk  University of Iowa
College of Engineering
319/335-5751   FAX: 319/384-0549   1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include 
Better is not better, 'standard' is better. B{

Re: Anti Phish Rules

[Noel Butler]

On 27/04/2018 17:53, Matus UHLAR - fantomas wrote:

> On 27.04.18 06:51, Noel Butler wrote: 
> 
>> I suspect Nick is still using and referring to mailscanner (which is/was
>> written in perl), it has/had this ability, I (like a good few of the
>> names around here) used it back in the day as well, until it became
>> clear it was abandonware, and did not like certain newer versions of
>> perl causing exits after each scan, mind you, I did dump it for amavisd
>> back around 2008/9/10, that said I liked that function, and rarely
>> noticed any FP's, my memorys hazy, but IIRC, it disarmed the links,
>> rather than take any scoring action... I might be wrong though, like I
>> said, its been along time.
> 
> I believe that the same arguments (need for hugt whitelist) could apply for
> mailscanner too.

I certainly never needed to whitelist anyone and we processed millions
of messages a day at that ISP 
but as I said, it disarmed it, stopping you from clicking on it, not
marking it as spam or such, which might require more thought 

> I have noticed discussion about this request/issue many times in this
> mailing list, still the same conclusions, so I wanted to point out to
> problems rather than telling the OP "go search list archives".
> 
> Note that I don't like this kind of mismatches too and I would invite having
> such plugin in SA
> 
> I would maybe even avoid initial whitelist to force organizations stop using
> such mismatched URLs (should be safe with not too high scores).

Thats the whole problem, idiotic companies who send links like that
deserve to get blocked/spam-binned,  but everybody runs around creating
whitelists, so why woulld they fix their shit, they have no incentive to
when people whitelist them.

I've never cared who you are, a ma 'n pa op shop, a govt dept, or huge
corporate, like BP, or whoever, you dont get whitelisted by me, and my
users know that, they know not to bitch to us about it, but to the
senders, been my way for a very long time, works for me ;) 

-- 
Kind Regards, 

Noel Butler 

This Email, including any attachments, may contain legally 
privileged
information, therefore remains confidential and subject to copyright
protected under international law. You may not disseminate, discuss, or
reveal, any part, to anyone, without the authors express written
authority to do so. If you are not the intended recipient, please notify
the sender then delete all copies of this message including attachments,
immediately. Confidentiality, copyright, and legal privilege are not
waived or lost by reason of the mistaken delivery of this message. Only
PDF [1] and ODF [2] documents accepted, please do not send proprietary
formatted documents 

 

Links:
--
[1] http://www.adobe.com/
[2] http://en.wikipedia.org/wiki/OpenDocument

Re: Anti Phish Rules

[Noel Butler]

On 27/04/2018 07:27, David Jones wrote:

> MailScanner became very mature and didn't need any major updates for years 
> then Jules turned it over to Jerry Benton who had a commercial product based 
> on it.  It's still being updated and runs fine now on systemd-based OSes and 
> newer versions of Perl.  One of our customers, Shawn Iversion, is helping 
> Jerry maintain MailScanner now as part of his EFA project.  
> https://efa-project.org/
> 
> -
> 
> FROM: Kevin Miller 
> SENT: Thursday, April 26, 2018 4:16 PM
> TO: users@spamassassin.apache.org
> SUBJECT: RE: Anti Phish Rules 
> 
> It's not abandonware - Jules handed it off to some other folks that are 
> actively putting out new versions.  As a matter of fact one came out not too 
> long ago.  MailWatch for MailScanner is also being actively developed still. 
> 
> Latest/greatest is available at www.mailscanner.info [1] for anyone wanting 
> to check it out. 
> 
> ...Kevin 
> 
> -- 
> 
> Kevin Miller 
> 
> Network/email Administrator, CBJ MIS Dept. 
> 
> 155 South Seward Street 
> 
> Juneau, Alaska 99801 
> 
> Phone: (907) 586-0242, Fax: (907) 586-4588 Registered Linux User No: 307357 
> 
> FROM: Noel Butler [mailto:noel.but...@ausics.net] 
> SENT: Thursday, April 26, 2018 12:51 PM
> TO: users@spamassassin.apache.org
> SUBJECT: Re: Anti Phish Rules 
> 
> On 26/04/2018 18:12, Matus UHLAR - fantomas wrote:
> 
>> On 26.04.18 18:00, Nick Edwards wrote: 
>> 
>> We've been using a separate product to do this, but it struck me, maybe
>> spamassassin can do this easier (or without having to call yet another
>> binary to run as can over mails)
>> 
>> Rules that look at URLs in a html message  href and src tags, check the "A"
>> tag to see if there is a URL there, and if they do not match,  consider it
>> a phis so apply said phis score to the message.
>> 
>> Has anyone done this? module even? 
>> 
>> the main problem: may non-spam senders do that, see:
>> 
>> https://wiki.apache.org/spamassassin/AntiPhishFakeUrlRule
>> 
>> and further the discussion in linked bug:
>> 
>> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=4255
> 
> I suspect Nick is still using and referring to mailscanner (which is/was 
> written in perl), it has/had this ability, I (like a good few of the names 
> around here) used it back in the day as well, until it became clear it was 
> abandonware, and did not like certain newer versions of perl causing exits 
> after each scan, mind you, I did dump it for amavisd back around 2008/9/10, 
> that said I liked that function, and rarely noticed any FP's, my memorys 
> hazy, but IIRC, it disarmed the links, rather than take any scoring action... 
> I might be wrong though, like I said, its been along time.
> 
> -- 
> 
> Kind Regards, 
> 
> Noel Butler 
> 
> This Email, including any attachments, may contain legally privileged 
> information, therefore remains confidential and subject to copyright 
> protected under international law. You may not disseminate, discuss, or 
> reveal, any part, to anyone, without the authors express written authority to 
> do so. If you are not the intended recipient, please notify the sender then 
> delete all copies of this message including attachments, immediately. 
> Confidentiality, copyright, and legal privilege are not waived or lost by 
> reason of the mistaken delivery of this message. Only PDF [2] and ODF [3] 
> documents accepted, please do not send proprietary formatted documents

It was very mature until it broke with later perls, each child would
exit after a scan, as I said this was back some 8/9 years ago, so if its
maintained again by 2018 one would hope those bugs are eliminated, but,
it caused a few grief, and Jules was MIA (yeah I recall him having
health issues) which didnt help those affected by the nasty child exit
bugs, amavisd suits us fine, though I do miss the phishing disarming,
i'm sure one can coddle up some decent SA rules  if one wanted to. 

-- 
Kind Regards, 

Noel Butler 

This Email, including any attachments, may contain legally 
privileged
information, therefore remains confidential and subject to copyright
protected under international law. You may not disseminate, discuss, or
reveal, any part, to anyone, without the authors express written
authority to do so. If you are not the intended recipient, please notify
the sender then delete all copies of this message including attachments,
immediately. Confidentiality, copyright, and legal privilege are not
waived or lost by reason of the mistaken delivery of this message. Only
PDF [2] and ODF [3] documents accepted, please do not send proprietary
formatted documents 

 

Links:
--
[1] http://www.mailscanner.info
[2] http://www.adobe.com/
[3] http://en.wikipedia.org/wiki/OpenDocument

Re: dropping other's email(s) as a "best practice" for hosted email? (was: "anyone recognize these headers? ...")

[Dianne Skoll]

On Thu, 26 Apr 2018 13:41:05 -0700
L A Walsh  wrote:

> To my way of thinking, dropping someone else's email,
> telling the sender the email is being rejected for having
> spam-like characteristics and telling the recipient nothing
> seems like it might have legal liability for the for the
> user potentially missing vital email.

It all depends on the contract between the service provider and the
customer.

If the service provider puts something in to the effect that it will
make best-effort attempts to deliver mail but is not responsible for
lost mail, then I doubt there's any legal liability.

For example, Google's Terms of Service say the following (in all-caps)

 Other than as expressly set out in these terms or additional terms,
 neither Google nor its suppliers or distributors make any specific
 promises about the services. For example, we don’t make any
 commitments about the content within the services, the specific
 functions of the services, or their reliability, availability, or
 ability to meet your needs. We provide the services “as is”.

 Some jurisdictions provide for certain warranties, like the implied
 warranty of merchantability, fitness for a particular purpose and
 non-infringement. To the extent permitted by law, we exclude all
 warranties.

They also have a limitation of liability clause that limits their liability
to the amount paid to use the services.

Regards,

Dianne.

Re: dropping other's email(s) as a "best practice" for hosted email? (was: "anyone recognize these headers? ...")

[@lbutlr]

On 2018-04-26 (14:41 MDT), L A Walsh  wrote:
> 
> To my way of thinking, dropping someone else's email, telling the sender the 
> email is being rejected for having spam-like characteristics and telling the 
> recipient nothing seems like it might have legal liability for the for the 
> user potentially missing vital email.

I agree that once the mail has been ACCEPTED the recent has to either receive 
the mail or know why the mail isn't there. For example, most spammy mail is 
delivered to a users Junk box, where they have a week to check it for mistagged 
mail, but after a certain threshold, users know that the email will be 
discarded (scoring over 10 in my case). However, this is very rare because most 
mail that is that spammy is rejected at the SMTP phase.

> It also would seem to violate what used to be a basic expectation of internet 
> email -- that it is either delivered to the recipient's inbox OR you'll 
> receive a non-delivery notification (a "bounce").

Or you will receive a rejection immediately.

Thin about it this way, if you send an email to da...@example.com and there is 
no such account because you intended to send it to d...@example.com you do not 
get an NDN, you get a rejection.

-- 
I want a party where all the women wear new dresses and all the men
drink beer. -- Jason Gaes

Re: FP with URI_TRY_3LD on get.adobe.com

[Sebastian Arcus]

On 27/04/18 10:49, Sebastian Arcus wrote:
I am getting some FP's with URI_TRY_3LD hitting the url get.adobe.com in 
the body of emails:


Apr 27 10:45:39.330 [32173] dbg: rules: ran uri rule URI_TRY_3LD ==> 
got hit: "http://get.adobe.com;


Would it be possible to add some exception to this rule - as many 
legitimate emails containing invoice attachments in pdf include the 
above url in the body.


It also appears to not like some DHL url's for some reason:

Apr 27 11:02:05.148 [32339] dbg: rules: ran uri rule URI_TRY_3LD ==> 
got hit: "https://mybill.dhl.com;

FP with URI_TRY_3LD on get.adobe.com

[Sebastian Arcus]

I am getting some FP's with URI_TRY_3LD hitting the url get.adobe.com in 
the body of emails:


Apr 27 10:45:39.330 [32173] dbg: rules: ran uri rule URI_TRY_3LD ==> 
got hit: "http://get.adobe.com;


Would it be possible to add some exception to this rule - as many 
legitimate emails containing invoice attachments in pdf include the 
above url in the body.

Re: dropping other's email(s) as a "best practice" for hosted email? (was: "anyone recognize these headers? ...")

[Matus UHLAR - fantomas]

On 26.04.18 13:41, L A Walsh wrote:

To my way of thinking, dropping someone else's email,
telling the sender the email is being rejected for having
spam-like characteristics and telling the recipient nothing
seems like it might have legal liability for the for the
user potentially missing vital email.


Refusing to take a mail is not dropping. Noone is required by any means to
accept anything because there may be many reasons a mail can't be accepted.

For example, mail server that it out of disk space cannot accept a mail thus
the only possibility is to refuse accepting it.

Dropping mail is the case where mailserver accepts mail and does not deliver
it, nor send a bounce.

It also would seem to violate what used to be a basic expectation of 
internet email -- that it is either delivered

to the recipient's inbox OR you'll receive a
non-delivery notification (a "bounce").


I have no idea where did you get this expectation - your assumption is
false. Nearly (if not completely) all mailservers tend to refuse accept mail
even from the client, if:
- the mail is over allowed size
- the sending address is invalid, undeliverable or forged
- the mail contains virus, phish, malware or otherwise dangerous content

especially in the case the sending address is invalid or undeliverable, it
is impossible impossible to send bounce to the sending address.

When the address is forged, those bounces would go to a innocent victim.

There are many reasons why mailserver (even your submission server) could
refuse message.


If your submission server accepts a message, it of course SHOULD send a
bounce when the recipient's server refuses it (exemptions named above)

Note that in this case the recipients server refuses to handle a message,
and instead of bouncing, sending the bounce is up to your submission server.


I hope some of those who think it was a good practice to
delete a user's email (because they think it is malware)
might rethink that practice.


I hope you now understand what is the difference between deleting and
refusing a mail and won't blame us for way how mail system works (and always
worked), just because you have misunderstood (or assumed) it.


I didn't realize email was no longer considered unreliable


afaik e-mail was NEVER considered reliable, mostly because of reasons
mentioned above.
--
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.
"The box said 'Requires Windows 95 or better', so I bought a Macintosh".

Re: Anti Phish Rules

[Matus UHLAR - fantomas]

On 26.04.18 18:00, Nick Edwards wrote:

We've been using a separate product to do this, but it struck me, maybe
spamassassin can do this easier (or without having to call yet another
binary to run as can over mails)

Rules that look at URLs in a html message  href and src tags, check the "A"
tag to see if there is a URL there, and if they do not match,  consider it
a phis so apply said phis score to the message.

Has anyone done this? module even?



On 26/04/2018 18:12, Matus UHLAR - fantomas wrote:

the main problem: may non-spam senders do that, see:

https://wiki.apache.org/spamassassin/AntiPhishFakeUrlRule

and further the discussion in linked bug:

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=4255


On 27.04.18 06:51, Noel Butler wrote:

I suspect Nick is still using and referring to mailscanner (which is/was
written in perl), it has/had this ability, I (like a good few of the
names around here) used it back in the day as well, until it became
clear it was abandonware, and did not like certain newer versions of
perl causing exits after each scan, mind you, I did dump it for amavisd
back around 2008/9/10, that said I liked that function, and rarely
noticed any FP's, my memorys hazy, but IIRC, it disarmed the links,
rather than take any scoring action... I might be wrong though, like I
said, its been along time.


I believe that the same arguments (need for hugt whitelist) could apply for
mailscanner too.

I have noticed discussion about this request/issue many times in this
mailing list, still the same conclusions, so I wanted to point out to
problems rather than telling the OP "go search list archives".

Note that I don't like this kind of mismatches too and I would invite having
such plugin in SA

I would maybe even avoid initial whitelist to force organizations stop using
such mismatched URLs (should be safe with not too high scores).

--
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.
REALITY.SYS corrupted. Press any key to reboot Universe.