Mailing List Archive

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 (mbill@legitEmail.com)" <system@sent-via.netsuite.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 rcooper@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
rcooper@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:micah@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: "support@example.com"<info@air-compressor.ml>

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_FROM From 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

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
> rcooper@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 rcooper@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 (jdoe@example.net)" <doe-john@freemail.example.com>
\___________________________/ \_____________________________/
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

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 (mbill@legitEmail.com)" <system@sent-via.netsuite.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

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, <user>@<domain>.<tld>, inside of the human
friendly name, specifically to avoid collisions like this. I've been
suggesting the same. I personally like "name - <user> at
<domain>.<tld>" <email address>. 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 <list>". 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

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 <list>". But sadly that doesn't
> give the email address information.

Mailman's DMARC mitigation code uses something very similar to "name at
domain via" <list@listdomain> 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

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

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" <list@listdomain> 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

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
KMcGrail@Apache.org

Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171

On Thu, 9 Apr 2020 16:17:51 -0400
Kevin A. McGrail wrote:

> 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.
>

I see that the plugin rules don't distinguish between the irresponsible
format of:

From: "Mr Bill (mbill@legitEmail.com)" <system@sent-via.netsuite.com>

and more seriously deceptive formats like:

From: "mbill@legitEmail.com" <foo@example.com>
From: "Mr Bill <mbill@legitEmail.com>" <foo@example.com>

To my remember, (as Grant, i need  my caffeine truck as well)  there are some MS Outlook CVEs related to the wayMS Outlook shows the "From:"  information, to the extent of showing just some "piece" of it...
So this kinf of "From:"  may have significant impact on unpatched computers...
-----------Pedreter.
On Saturday, April 11, 2020, 05:50:05 PM GMT+2, RW <rwmaillists@googlemail.com> wrote:
>On Thu, 9 Apr 2020 16:17:51 -0400
>Kevin A. McGrail wrote:
>> 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.
>
>
>I see that the plugin rules don't distinguish between the irresponsible
>format of:
>
 > From: "Mr Bill (mbill@legitEmail.com)" <system@sent-via.netsuite.com<
>
>and more seriously deceptive formats like:>  From: ">mbill@legitEmail.com" <foo@example.com>
 > From: "Mr Bill <mbill@legitEmail.com>" <foo@example.com>>

On 4/11/20 9:49 AM, RW wrote:
> I see that the plugin rules don't distinguish between the irresponsible
> format of:
>
> From: "Mr Bill (mbill@legitEmail.com)" <system@sent-via.netsuite.com>
>
> and more seriously deceptive formats like:
>
> From: "mbill@legitEmail.com" <foo@example.com>
> From: "Mr Bill <mbill@legitEmail.com>" <foo@example.com>

I feel like all three examples that you have provided include an actual
usable email address in the human friendly name of the From: header. In
my opinion, anything else in the double quotes is largely window
dressing. As such, I think that it doesn't matter if the email address
is in (...) or <...> or bare. The Mr Bill prefix also doesn't matter.

Given the above opinion, I would consider all three of these human
friendly names to be effectively identical.

So, what would you like the plugin to do differently? How do you think
the three examples should be handled?



--
Grant. . . .
unix || die

Grant Taylor wrote:
> On 4/11/20 9:49 AM, RW wrote:
>> I see that the plugin rules don't distinguish between the
>> irresponsible format of:
>>
>> From: "Mr Bill (mbill@legitEmail.com)"
>> <system@sent-via.netsuite.com>
>>
>> and more seriously deceptive formats like:
>>
>> From: "mbill@legitEmail.com" <foo@example.com>
>> From: "Mr Bill <mbill@legitEmail.com>" <foo@example.com>
>
> I feel like all three examples that you have provided include an
> actual usable email address in the human friendly name of the From:
> header. In my opinion, anything else in the double quotes is largely
> window dressing. As such, I think that it doesn't matter if the
> email address is in (...) or <...> or bare. The Mr Bill prefix also
> doesn't matter.
>
> Given the above opinion, I would consider all three of these human
> friendly names to be effectively identical.
>
> So, what would you like the plugin to do differently? How do you
> think the three examples should be handled?

I think RW makes a valid point. I just rewrote my plugin to hit one of two
rules depending on if the address is formatted as "me@mine.com
<bad@guy.com>" vs "Fname Lname (valid@mine.com) <listjunk@them.com> (give or
take the parenthesis).

Because the second one is more commonalty used for valid purposes (hence
needing the ability to whitelist and address or domain). The first example I
have never seen used in a legit fashion myself. So if it hits
The first rule that is a high hit, well above threshold and the second rule
is bypassed (no double dip),
Hit the second rule and it's a moderate bump.

Rick

On Sat, 11 Apr 2020 11:46:04 -0600
Grant Taylor wrote:

> On 4/11/20 9:49 AM, RW wrote:
> > I see that the plugin rules don't distinguish between the
> > irresponsible format of:
> >
> > From: "Mr Bill (mbill@legitEmail.com)"
> > <system@sent-via.netsuite.com>
> >
> > and more seriously deceptive formats like:
> >
> > From: "mbill@legitEmail.com" <foo@example.com>
> > From: "Mr Bill <mbill@legitEmail.com>" <foo@example.com>
>
> I feel like all three examples that you have provided include an
> actual usable email address in the human friendly name of the From:
> header. In my opinion, anything else in the double quotes is largely
> window dressing. As such, I think that it doesn't matter if the
> email address is in (...) or <...> or bare. The Mr Bill prefix also
> doesn't matter.
>
> Given the above opinion, I would consider all three of these human
> friendly names to be effectively identical.

The first one was cited as a format used in forwarded ham. The other
two are common in spam.

The point of this spamming technique is that many clients show only the
display name in the message list. Consequently the three headers will
display like this:

Mr Bill (mbill@legitEmail.com)
mbill@legitEmail.com
Mr Bill <mbill@legitEmail.com>

IMO the middle one is the most convincing as it's exactly what would
have been displayed if that address had been used without a display
name. The last one at least looks like a from header. The first looks
the



> So, what would you like the plugin to do differently? How do you
> think the three examples should be handled?

On Sat, 11 Apr 2020 19:58:02 +0100
RW wrote:


>
> The first one was cited as a format used in forwarded ham. The other
> two are common in spam.
>
> The point of this spamming technique is that many clients show only
> the display name in the message list. Consequently the three headers
> will display like this:
>
> Mr Bill (mbill@legitEmail.com)
> mbill@legitEmail.com
> Mr Bill <mbill@legitEmail.com>
>
> IMO the middle one is the most convincing as it's exactly what would
> have been displayed if that address had been used without a display
> name. The last one at least looks like a from header. The first looks
> the

... least convincing.

I don't know happened there, it got sent before I'd finished.

Basically it seems likely that different formats will has different
statistics.

There's no need for any of this to be added to any plugin, it's easiest
to simply meta header regexes with the plugin result.

On April 11, 2020 3:08:15 PM EDT, RW <rwmaillists@googlemail.com> wrote:
>On Sat, 11 Apr 2020 19:58:02 +0100
>RW wrote:
>
>
>>
>> The first one was cited as a format used in forwarded ham. The other
>> two are common in spam.
>>
>> The point of this spamming technique is that many clients show only
>> the display name in the message list. Consequently the three headers
>> will display like this:
>>
>> Mr Bill (mbill@legitEmail.com)
>> mbill@legitEmail.com
>> Mr Bill <mbill@legitEmail.com>
>>
>> IMO the middle one is the most convincing as it's exactly what would
>> have been displayed if that address had been used without a display
>> name. The last one at least looks like a from header. The first looks
>> the
>
>... least convincing.
>

Oddly enough the first is legitimate in a lot of cases. Netsuit, for instance, uses that in the display section all the time.

>I don't know happened there, it got sent before I'd finished.
>
>Basically it seems likely that different formats will has different
>statistics.
>
>There's no need for any of this to be added to any plugin, it's easiest
>to simply meta header regexes with the plugin result.

On Sat, 11 Apr 2020 15:16:35 -0400
Rick Cooper wrote:

> On April 11, 2020 3:08:15 PM EDT, RW <rwmaillists@googlemail.com>
> wrote:
> >On Sat, 11 Apr 2020 19:58:02 +0100
> >RW wrote:
> >
> >
> >>
> >> The first one was cited as a format used in forwarded ham. The
> >> other two are common in spam.
> >>
> >> The point of this spamming technique is that many clients show only
> >> the display name in the message list. Consequently the three
> >> headers will display like this:
> >>
> >> Mr Bill (mbill@legitEmail.com)
> >> mbill@legitEmail.com
> >> Mr Bill <mbill@legitEmail.com>
> >>
> >> IMO the middle one is the most convincing as it's exactly what
> >> would have been displayed if that address had been used without a
> >> display name. The last one at least looks like a from header. The
> >> first looks the
> >
> >... least convincing.
> >
>
> Oddly enough the first is legitimate in a lot of cases. Netsuit, for
> instance, uses that in the display section all the time.

Yes, I know. I meant that it's the least convincing in a spam.