Re: Spoofed From: names
On Sat, 11 Apr 2020 15:16:35 -0400 Rick Cooper wrote: > On April 11, 2020 3:08:15 PM EDT, RW > 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 (mb...@legitemail.com) > >> mb...@legitemail.com > >> Mr Bill > >> > >> 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.
Re: Spoofed From: names
On April 11, 2020 3:08:15 PM EDT, RW 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 (mb...@legitemail.com) >> mb...@legitemail.com >> Mr Bill >> >> 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.
Re: Spoofed From: names
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 (mb...@legitemail.com) > mb...@legitemail.com > Mr Bill > > 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.
Re: Spoofed From: names
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 (mb...@legitemail.com)" > > > > > > and more seriously deceptive formats like: > > > >From: "mb...@legitemail.com" > >From: "Mr Bill " > > 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 (mb...@legitemail.com) mb...@legitemail.com Mr Bill 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?
RE: Spoofed From: names
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 (mb...@legitemail.com)" >> >> >> and more seriously deceptive formats like: >> >>From: "mb...@legitemail.com" >>From: "Mr Bill " > > 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 "m...@mine.com " vs "Fname Lname (va...@mine.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
Re: Spoofed From: names
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 (mb...@legitemail.com)" and more seriously deceptive formats like: From: "mb...@legitemail.com" From: "Mr Bill " 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 smime.p7s Description: S/MIME Cryptographic Signature
Re: Spoofed From: names
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 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 (mb...@legitemail.com)" >and more seriously deceptive formats like:> From: ">mb...@legitemail.com" > > From: "Mr Bill " >
Re: Spoofed From: names
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 (mb...@legitemail.com)" and more seriously deceptive formats like: From: "mb...@legitemail.com" From: "Mr Bill "
Re: Spoofed From: names
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
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
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
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
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
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
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: Spoofed From: names
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
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