Re: What is BODY: IMH_ED_SPAM rule?

[Toolworker]

Bill Cole wrote
> "Toolworker" was replying to a message from 2014.
> 
> !!!

I wasn't looking for help - I was providing it.

It was a problem in 2014 and it's a problem today - although only for
InMotion Hosting customers. And now there's an answer to the question.

And I suggest that anyone bothered enough by this rule to google it should
go into their cPanel and reduce its weight.

My apologies if this is the wrong place for the answer, but this was where
the question was, and this is the only hit on the web for IMH_ED_SPAM. 





--
Sent from: http://spamassassin.1065346.n5.nabble.com/SpamAssassin-Users-f3.html

Re: Spoofed From: names

[Kevin A. McGrail]

On 4/9/2020 10:16 AM, micah anderson wrote:
> What is the current state of the art for dealing with tricking people in
> the From with the "Name" part? For example:
Hi Micah, I believe the FromNameSpoof plugin is the current state of the
art.

-- 
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: Spoofed From: names

[Grant Taylor]

On 4/9/20 10:12 AM, Lindsay Haisley wrote:

I don't know. I'm no SA expert, but I've worked with DMARC
mitigation code and would assume that a RFC-2822 compliant
understanding of the From address would be the first step.


More caffeine and a little more Googling, I think that SpamAssassin 
already has sufficient knowledge of RFC 2822 (obsoleted by 5322) with 
the From:name and From:addr


My understanding is that From:name is the human friendly name and that 
From:addr is the email address.


So, I think that SpamAssassin already knows enough RFC 2822 (5322) to 
deal with this.



Mailman's DMARC mitigation code uses something very similar to "name
at domain via"  which retains all the information
from the original From address while providing a functional From
address using a domain name which passes SPF, a sufficient condition
for passing DMARC.

Agreed.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Spoofed From: names

[Grant Taylor]

On 4/9/20 9:19 AM, Grant Taylor wrote:
Would you be willing to rephrase your paragraph hilighting which 
addresses you are comparing when?


Thank you for the off-list reply Rick.

I know understand that you are referring to the simple cases where the 
human friendly name is abused to look like the actual email address the 
sender wants recipients to see.


I thought you were trying to do something more complex like take the 
name portion of the human friendly name and match it against the company 
directory (possibly with reordering & case folding & etc.) to look up 
candidate email addresses for the name, then comparing those candidate 
names with the email address in the From: header and taking some form of 
action if there wasn't a match.


Now it seems like you are treating the fake address portion of the human 
friendly name as -- in Sendmail parlance -- a "protected recipient".  If 
the fake address is on the list, then the email address had better match 
the fake address.


I wonder if this might be simplified a little bit.  If the domain part 
of fake address is one of the local domains  --  "Class w" in Sendmail 
parlance -- then the email address must match the fake address.  It 
seems like there would be less to lookup working on just the domain part 
instead of full email addresses.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Spoofed From: names

[Lindsay Haisley]

On Thu, 2020-04-09 at 10:02 -0600, Grant Taylor wrote:
> Please elaborate 
> on what else SpamAssassin needs to know about and do.

I don't know. I'm no SA expert, but I've worked with DMARC mitigation
code and would assume that a RFC-2822 compliant understanding of the
>From address would be the first step.

> I also quite frequently see "name via ".  But sadly that doesn't 
> give the email address information.

Mailman's DMARC mitigation code uses something very similar to "name at
domain via"  which retains all the information from
the original From address while providing a functional From address
using a domain name which passes SPF, a sufficient condition for
passing DMARC.

-- 
Lindsay Haisley   | "The world is full of monsters with friendly
FMP Computer Services |   faces and angels with scars."
512-259-1190  | 
http://www.fmp.com|  - Heather Brewer

Re: Spoofed From: names

[Grant Taylor]

On 4/9/20 9:33 AM, Lindsay Haisley wrote:
This is actually a common, legitimate technique for dealing with 
DMARC mitigation issues on mailing lists and mail redirections.


Yes, re-writing the From: address is a common technique.  How it's 
re-written is important.  (See below.)


I don't know if SA has the ability to fully parse an email address 
based on RFC-2822 criteria, but this would be what's necessary.


It's my understanding that SpamAssassin already knows the difference in 
the email address and the human friendly name parts.  Please elaborate 
on what else SpamAssassin needs to know about and do.


The Mailman code substitutes the word "at" in the comment field for 
the ampersand to avoid this sort of problem, but other implementation 
may not.
I have seen many others suggest NOT using a format recognizable as an 
actual email address, @., inside of the human 
friendly name, specifically to avoid collisions like this.  I've been 
suggesting the same.  I personally like "name -  at 
." .  It gives the information for someone 
to be able to reconstruct the email address if they want to.


I also quite frequently see "name via ".  But sadly that doesn't 
give the email address information.


But avoid the recognizable RegExable email address in the human friendly 
name.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Spoofed From: names

[Lindsay Haisley]

On Thu, 2020-04-09 at 10:47 -0400, Rick Cooper wrote:
>  I wrote my own plugin  for that but I don't score very high anymore because
> of things likes this:
> (obviously Mr Bill is not real but the netsuite address is)
> 
> From: "Mr Bill (mb...@legitemail.com)" 
> 
> I find more and more companies, I believe intuit is doing something like
> that, that do this.

This is actually a common, legitimate technique for dealing with DMARC
mitigation issues on mailing lists and mail redirections. I don't know
if SA has the ability to fully parse an email address based on RFC-2822 
criteria, but this would be what's necessary.

GNU Mailman uses a From address rewrite of this sort when the sending
poster to a list has an email address for which the domain DMARC policy
is "reject". I've re-written the Mailman code (Python) for use with
email redirection via the Courier MTA. The Mailman code substitutes the
word "at" in the comment field for the ampersand to avoid this sort of
problem, but other implementation may not.

-- 
Lindsay Haisley   | "The world is full of monsters with friendly
FMP Computer Services |   faces and angels with scars."
512-259-1190  | 
http://www.fmp.com|  - Heather Brewer

Re: Spoofed From: names

[Grant Taylor]

On 4/9/20 8:47 AM, Rick Cooper wrote:

For detecting possible fraud addresses involving our own people I
wrote a backend look up for exim that looks at any name like "Rick
Cooper" and compares that to a DB with all email addresses for all
employees in all locations and then , if the actual
rcoo...@domain.com doesn't match any of those listed for that name,
it rewrites the subject and appends a noticeable disclaimer to the
subject line stating the email is not from rcoo...@domain.com and any
other addresses that person may have. It also adds a X-Header that SA
can score on at the same time.


Maybe it's the fact that I'm only a couple of drinks into my caffeine, 
but I'm having trouble unpacking that paragraph.  Would you please 
clarify, possibly with an example failure.  I think I'm mainly getting 
caught up on which part of the email you're comparing when.


   From:  "John Doe (j...@example.net)" 
  \___/ \_/
   human friendly name   email address
   \__/ \/
 name  fake address

These are the terms that I usually use to describe these parts.  --  I 
wonder if there are any better terms that I should use.


Would you be willing to rephrase your paragraph hilighting which 
addresses you are comparing when?


Thank you.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Problem with SpamAssassin rules wiki. What is the new link ?

[Bill Cole]

On 9 Apr 2020, at 5:12, Antoine Chiris wrote:


Dear SpamAssassin users/team,

I have a little problem with *SpamAssassin*. I don't find the 
documentation

for the rules.


The definitive documentation of the rules that are distributed as part 
of the project is the rules files themselves. Most rules have (and all 
*should* have) a 'describe' line


For example, for the rule MIME_HTML_MOSTLY I have a link to this wiki 
:
https://wiki.apache.org/spamassassin/Rules/MIME_HTML_MOSTLY But 
apparently
the documentation is no longer available and I don't find the new 
link.


That's true.

The wiki was mostly migrated to the ASF Confluence instance recently and 
is now at https://cwiki.apache.org/confluence/display/SPAMASSASSIN/. The 
old rules descriptions (which had not been maintained since v3.3) were 
not migrated, as they were largely outdated where they were not 
redundant.


I don't have a definitive reference for the decision to stop maintaining 
rule descriptions on the wiki, so there may be a more correct 
explanation out there in the heads of the people who were on the PMC at 
the time. However, my view is that this was the right decision because 
of how the default rules are managed. Rules can shift in and out of the 
update channel based on the automated QA process, and there is a 
continuous trickle of new rules, rule changes, and rule deletions coming 
from the development team that get integrated (or not) via RuleQA. There 
was never a functional process for maintaining the wiki pages for rules 
properly in conjunction with that continuous change process, and the 
descriptions were mostly not much more illuminating than the 'describe' 
lines in the rules files.




If you look in the archives of the apache wiki (
web.archive.org/web/20170913151929/https://wiki.apache.org/…
),
there's a good explanation for that message.

Do you know if this wiki is still available? Is there a new link for 
this

wiki ?


As I noted above, the SA wiki is now at 
https://cwiki.apache.org/confluence/display/SPAMASSASSIN/ but it no 
longer contains any collection of pages that purports to be 
documentation of the individual rules.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

RE: Spoofed From: names

[Rick Cooper]

 I wrote my own plugin  for that but I don't score very high anymore because
of things likes this:
(obviously Mr Bill is not real but the netsuite address is)

From: "Mr Bill (mb...@legitemail.com)" 

I find more and more companies, I believe intuit is doing something like
that, that do this.
I could of course add a whitelist of sorts but I prefer to bump the score a
bit, enough to tag as low scoring spam. 

For detecting possible fraud addresses involving our own people I wrote a
backend look up for exim that looks at any name like "Rick Cooper" and
compares that to a DB with all email addresses for all employees in all
locations and then , if the actual rcoo...@domain.com doesn't match any of
those listed for that name, it rewrites the subject and appends a noticeable
disclaimer to the subject line stating the email is not from
rcoo...@domain.com and any other addresses that person may have. It also
adds a X-Header that SA can score on at the same time.


Rick

-Original Message-
From: micah anderson [mailto:mi...@riseup.net] 
Sent: Thursday, April 09, 2020 10:17 AM
To: users@spamassassin.apache.org
Subject: Spoofed From: names


Hi,

What is the current state of the art for dealing with tricking people in
the From with the "Name" part? For example:

From: "supp...@example.com"

The "Real Name" part is used to put a fake email address of the actual
domain (example.com would be my domain, or gmail.com or something other
than air-compressor.ml).

This has come up before[0], but at the time generic solutions seemed
problematic due to various false positives, or missing features in
spamassassin itself. I'm wondering what the current state is now.

I can do a relatively easy meta-rule for my domain, something like this,
but I'm not sure how well this would work, or if there are better
methods now:

header __LOCAL_FROM_QUOTE_ISUS  From =~ /\".*\@example\.com\"/
header __LOCAL_FROM_CONTAIN_NOTUS   From !~ /<.*\@example\.com/>/
meta TRICKY_FROM((( __LOCAL_FROM_QUOTA_ISUS ) + (
__LOCAL_FROM_CONTAIN_NOTUS )) > 1)
describe TRICKY_FROMFrom has example.com in quotes, but
not in path
score TRICKY_FROM   5



0. https://www.mail-archive.com/users@spamassassin.apache.org/msg100800.html
-- 
micah

Spoofed From: names

[micah anderson]

Hi,

What is the current state of the art for dealing with tricking people in
the From with the "Name" part? For example:

From: "supp...@example.com"

The "Real Name" part is used to put a fake email address of the actual
domain (example.com would be my domain, or gmail.com or something other
than air-compressor.ml).

This has come up before[0], but at the time generic solutions seemed
problematic due to various false positives, or missing features in
spamassassin itself. I'm wondering what the current state is now.

I can do a relatively easy meta-rule for my domain, something like this,
but I'm not sure how well this would work, or if there are better
methods now:

header __LOCAL_FROM_QUOTE_ISUS  From =~ /\".*\@example\.com\"/
header __LOCAL_FROM_CONTAIN_NOTUS   From !~ /<.*\@example\.com/>/
meta TRICKY_FROM((( __LOCAL_FROM_QUOTA_ISUS ) + ( 
__LOCAL_FROM_CONTAIN_NOTUS )) > 1)
describe TRICKY_FROMFrom has example.com in quotes, but not 
in path
score TRICKY_FROM   5



0. https://www.mail-archive.com/users@spamassassin.apache.org/msg100800.html
-- 
micah

Problem with SpamAssassin rules wiki. What is the new link ?

[Antoine Chiris]

Dear SpamAssassin users/team,

I have a little problem with *SpamAssassin*. I don't find the documentation
for the rules.

For example, for the rule MIME_HTML_MOSTLY I have a link to this wiki :
https://wiki.apache.org/spamassassin/Rules/MIME_HTML_MOSTLY But apparently
the documentation is no longer available and I don't find the new link.

If you look in the archives of the apache wiki (
web.archive.org/web/20170913151929/https://wiki.apache.org/…
),
there's a good explanation for that message.

Do you know if this wiki is still available? Is there a new link for this
wiki ?

Thanks in advance.


-- 
ANTOINE CHIRIS
INGENIEUR PRODUCTION JUNIOR | PRODUCTION ENGINEER | PROBANCE [image:
Twitter]  | [image: Facebook]
 | [image: Linkedin]

antoine.chi...@probance.com
WWW.PROBANCE.COM 
FRANCE | JAPAN | SPAIN