Re: Spam DKIM signed by Paypal coming from their Microsoft Tenant?

[Alan Hodgson]

On Mon, 2022-11-14 at 15:14 -0500, Shawn Iverson wrote:
> How do I stop this?  paypal.com is in the default DKIM whitelist!
> 

That message really looks like it came from Paypal and then was
forwarded by Microsoft to your server. Was it really a fake? That's a
lot of headers to fake if so.

If it was really fake and that paypal-supplied DKIM signature doesn't
validate (I didn't check that), then checking DMARC when you receive
mail and rejecting on p=reject failures would block it.

Re: DMARC fails for valid record?

[Alan Hodgson]

On Mon, 2022-05-09 at 14:35 -0400, Alex wrote:
> Hi,
> 
> I'm trying to understand why this email from a bank fails DMARC
> when mxlookup says the DMARC record is just fine.
> 
> https://pastebin.com/0T4Gjn3v
> 
>  *  1.8 DMARC_REJECT DMARC reject policy
>  *  6.0 KAM_DMARC_REJECT DKIM has Failed or SPF has failed on the
> message
>  *      and the domain has a DMARC reject policy
> 
> It also passes SPF and DKIM
> 
>  *  0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
>  * -0.0 SPF_PASS SPF: sender matches SPF record
>  * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
> author's
>  *       domain
>  * -0.1 DKIM_VALID Message has at least one valid DKIM or DK
> signature
>  *  0.1 DKIM_SIGNED Message has a DKIM or DK signature, not
> necessarily
>  *      valid
> 
> I'm using a local DNS resolver, not a public server.
> 

I'm pretty sure it can't pass SPF for the purposes of satisfying
DMARC with a null envelope sender.

Dunno why the DKIM didn't pass. Can you tell if the
d=ess.firstdata.com signature is valid or only the amazonses.com sig
(which wouldn't satisfy DMARC)?

Re: how sendgrid is abusing the ukraine crisis (or they are still to dumb to filter for spam)

[Alan Hodgson]

On Fri, 2022-03-04 at 13:01 +, Marc wrote:
> Is anyone blocking already connections from outbound-
> mail.sendgrid.net? Does that generate a lot of false positives? 
> PS. just posting this so it is on web archives and people searching
> for sendgrid hopefully chose a better service.
> 

Unfortunately, a lot of legitimate senders still use Sendgrid.

Re: Do these domains merit blocking?

[Alan Hodgson]

On Wed, 2021-12-15 at 10:55 -0800, Alan Hodgson wrote:
> 
> I got a couple to an actual human who answered
> ab...@princeton.edu. I can forward them privately.

Let me rephrase that; I complained to ab...@princeton.edu and
actually heard back from a human, to whom I have since sent copies of
the spam messages.

Re: Do these domains merit blocking?

[Alan Hodgson]

On Wed, 2021-12-15 at 13:24 -0500, Charles Sprickman wrote:
> Does anyone have a sample of one of their emails?
> 
> I’m composing a brief nastygram and would like to get my eyes on
> one before finishing up.
> 

I got a couple to an actual human who answered ab...@princeton.edu. I
can forward them privately.

Re: Do these domains merit blocking?

[Alan Hodgson]

On Wed, 2021-12-15 at 11:39 -0500, Bill Cole wrote:
> 
> A customer has expressed mild dismay at the concept that a fine
> research institution should be "punished for doing research." I'm
> less attached to Princeton than my NJ-based customer and (having
> worked in a NIH-funded lab) less idolizing of the Ivory Tower in
> general. I have no difficulty explaining my position, but I am
> rather surprised that I need to in 2021. Am I missing something
> special that makes such research spam somehow not spam?

No.

And that's about the stupidest "study" I've ever heard of. It's not
like they're going to get any responses other than "fsck off" (which
is what I added to my header_filters after getting the second one).
It's hard to imagine anyone being that naive in 2021, but here we
are.

Re: KAM_SENDGRID and SPF_HELO_NONE

[Alan Hodgson]

On Thu, 2021-05-20 at 16:12 -0400, Alex wrote:
> 
> X-Envelope-From:
>     
> 
> 
> Perhaps it's because Return-Path is null?
> Return-Path: <>

Return-Path is supposed to be where your MTA stores the envelope sender. That
it doesn't match is probably a problem.


And yes, SPF falls back to testing the HELO host if the envelope sender is
empty (which should only occur in bounces or auto-responses).

Re: to: header is not in my domain

[Alan Hodgson]

On Tue, 2020-10-20 at 20:38 +0100, Miki wrote:
> Thanks for quick reply, but blacklist what?
> The problem is I do not know this spammy domains.
> I want to give a score when To: field is NOT in anyaddr...@mydomain.com

Not tested, but something like this should work:

header __LOCAL_TO_ME To =~ /\@mydomain/i
header __LOCAL_CC_ME Cc =~ /\@mydomain/i
header __LOCAL_MAILING_LIST1 List-Unsubscribe =~ /[a-z]+/ 
header __LOCAL_MAILING_LIST2 List-ID =~ /[a-z]+/

meta LOCAL_NOT_TO_ME ( ! ( __LOCAL_TO_ME || __LOCAL_CC_ME
 || __LOCAL_MAILING_LIST1 || __LOCAL_MAILING_LIST2 )) 
score LOCAL_NOT_TO_ME ??

You'll want to whitelist authenticated mail from your regular correspondents
though so it doesn't hit normal bcc's.

Re: SpamAssassin DKIM with Virtual Hosting

[Alan Hodgson]

> 

> > Or is there some criteria to determine which domain name
> > should have the DKIM signature?  Is there a penalty score if one or
> > the other is missing?
> 
> It's doesn't make much difference, unless there's a whitelist involved.

If you publish a DMARC record, DMARC requires that the DKIM signing domain be
aligned with the From: header domain in order to pass. SA doesn't currently
check DMARC I don't think but lots of other receivers do.

And even if you don't want to publish DMARC records now it's probably best
practice to sign with the organizational domain of the From: header. A DKIM
signature from an unrelated domain doesn't really say anything except that the
message wasn't altered in transit.

Re: 1.6 FORGED_MUA_MOZILLA Forged mail pretending to be from Mozilla

[Alan Hodgson]

On Wed, 2020-09-23 at 14:46 -0500, Jerry Malcolm wrote:
> On 9/23/2020 2:33 PM, iulian stan wrote:
> > Most of the time the IPs from AWS are already blacklisted and you 
> > cannot do anything.
> 
> I'm curious why such a blanket statement.  Why does AWS have such a bad 
> reputation?  With companies like Netflix and Dropbox using AWS, why are 
> they considered across-the-board spammers?  I'm also curious why 
> SpamAssassin and mail-tester doesn't report that my AWS IP is blacklisted.
> 
> My client is massively invested in AWS with many servers, databases, and 
> services unrelated to mail.  Moving to another platform is not an 
> option.  What is a good 'reputable' 3rd party service that I can use as 
> a proxy to make sure I have 'clean' mail?

If it's normal transactional mail to people who have agreed to receive it,
just send it through a reputable ESP like Postmark. If your sending domain
itself hasn't been spamming that should be enough to get your mail delivered
fine.

Make sure your DKIM and SPF are setup right before sending.

Re: base64 encoded subjects

[Alan Hodgson]

On Fri, 2020-02-07 at 16:29 -0600, Benjamin Toll wrote:
> I'm seeing a lot of spam with base64 encoded subjects:
> 
> Subject:
> =?UTF-8?B?RnVsbCBkZW50YWwgY292ZXJhZ2UgZm9yIGZhbWlsaWVzIGFuZCBzZW5pb3JzLCBjb3ZlcnMgYWxsIHByb2NlZHVyZXM=?=
> 
> Subject: =?UTF-8?B?V2VhciB5b3VyIE11bHRpLVRvb2wgYXJvdW5kIHlvdXIgd3Jpc3Qu?=
> 
> 
> SA is scoring the messages pretty high based off the body, but a lot of
> spams with the base64 is still getting through. I thought it wouldn't be
> too hard to write a rule to catch these, but clearly I don't know what
> I'm doing:
> 
> header   BRT_BASE64_SUBJECT Subject =~ /=\?UTF\-8/
> 
> This doesn't trigger on any of these spams. Am I going about this the
> wrong way or I'm I just that bad at writing regexs? Any suggestions
> would be appreciated.
> 

SA decodes those before rule matching.

Try Subject:raw =~ 

Re: help with simple test?

[Alan Hodgson]

On Wed, 2020-01-15 at 11:02 -0500, AJ Weber wrote:
> I'm hoping this is a relatively simple test...
> I'm seeing emails "From Me, To Me", typically extortion types. I'm not
> even seeing which of the SA tests are getting hit, because I have my
> own email in my Whitelist.
> Is there a way I can check IF From = m...@staticinfo.com AND Return-Path 
> != FROM in a rule?
> I guess no matter what, I would have to remove my own email address
> from the Whitelist?  Or can this be checked and override the
> whitelist-shortcircuit somehow?

I'd suggest a few things.
1) Make sure all your real email is DKIM signed. Then change the
whitelist on your own email to one or more  whitelist_from_dkim entries
with valid signing domains. Proper use of DKIM is awesome for
whitelisting.
2) You can't test multiple headers in one rule but meta rules are your
friend.
header __LOCAL_RETURN_PATH_ME Return-Path =~ /my@address/imheader
__LOCAL_FROM_ME From =~ /my@address/immeta LOCAL_ME_FORGED ( __FROM_ME
&& ! __RETURN_PATH_ME)score LOCAL_ME_FORGED 10describe LOCAL_ME_FORGED
Message has my address in From but not in envelope sender
3) Much better plan, just add DMARC to your domain and high score
anything from your domain that fails DMARC. There is no reason to be
seeing mail forged from your own address in 2020 (assuming you have your
own domain).
4) Remember that most mailing list messages will fail both 2) and 3)
above. Have a plan for mailing lists.

Re: Custom rule to please the Mayor

[Alan Hodgson]

On Thu, 2019-11-21 at 13:24 -0500, Dave Goodrich wrote:
> Good day,
> I know I will incur some wrath for this but I have the Mayor breathing
> down my neck. We stop nearly all spam now, but some does get through.
> Mostly it has been mail from gmail and outlook servers that pass DKIM
> and SPF.
> This morning a large number of messages appearing to come from the
> Mayor were delivered. The email is technically legitimate and was
> scored appropriately. Unfortunately, the From address was in the
> following format 'the Mayor's display name '
> . So, everyone who saw the message opened it because it looked like it
> came from the Mayor. then they called the Mayor's office.
> - The message was benign.- The users know to hover over display names
> to check the address, but this was the Mayor. They did not.- All mail
> delivered locally comes through our server. No one is allowed to use
> their City email address on none City devices. Had the address been
> correct, it would have been stopped.
> Even if only for this one account, I need a rule to check that the
> Mayor's display name matches the Mayor's email account and I am at a
> loss how to manage that with SA rule structure.
> Any thoughts on that or has anyone done something similar?

Make sure your real mail streams are authenticated with DKIM and you're
setup to use the whitelist_from_dkim rule; which I believe requires the
header added by opendkim on received mail.

whitelist_from_dkim *@yourdomain your_signing_domain

Then you can add a custom rule to add a large score to From =~ /mayor's
name/ and variants , possibly meta'd with FREEMAIL_FROM if you're only
concerned about gmail spoofs.

It'll only be so useful but at least you can catch the straight-up
imposter who isn't using charset encoding or spelling tricks to masq the
name.

Re: Spamassassin using remote rules definition source?

[Alan Hodgson]

On Mon, 2018-12-10 at 04:57 -0700, ozgurerdogan wrote:
> I simply need to write custom rules to block certain mails, domain names. Do
> I have to learn programming language for this? Is not it easy like create a
> conf file and let Sa update rules from that source remotely via http?
> 
> 

cron + wget + reload.

Although if you're running multiple servers it's well worth setting up
puppet or something similar eventually.

Re: SpamSender with 2 @-signs in the address

[Alan Hodgson]

On Wed, 2018-12-05 at 00:17 +, David Jones wrote:
> 
I think he meant that DKIM related to DMARC means the DKIM signature has 
> to align/match the From: header domain to pass which is DKIM_VALID_AU in SA.
> 
> In the case of SPF, DMARC will pass if the envelope-from domain check 
> hits SPF_PASS in SA.
> 

Not quite; DMARC also requires the envelope sender domain to be aligned
with the From: header domain to pass on an SPF_PASS.

Re: SpamSender with 2 @-signs in the address

[Alan Hodgson]

On Mon, 2018-12-03 at 13:17 -0600, sha...@shanew.net wrote:
> Yeah, I see all these same things.  Better to test against From:addr
> rather than the full From:  Perhaps something like:
> 
> From:addr =~ /\@[^\s]+\@/
> 
> Of course, there might still be legit cases of that kind of usage.
> 

The problem though for phishes is that some user agents (ie. Outlook)
only display the quoted user-friendly part of the address, not the rest
of the From: header. So phishers specifically put a fake
@domainbeingphished.com in quotes so your users will see that.

I don't think I've ever seen multiple @'s in any single address part,
not since the mid-90s anyway. It would definitely be safe to block on
that for any single address.

Re: SpamSender with 2 @-signs in the address

[Alan Hodgson]

On Mon, 2018-12-03 at 11:15 -0700, Grant Taylor wrote:
> 
I don't think the multiple @ signs have worked in a very long time.  So 
> I see no reason not to add score based on multiple @ signs.  Or if there 
> is a legitimate use for it, it should be extremely rare and the false 
> positive rate should be acceptable.
> 


I've been watching these for a while, and unfortunately there are a lot
of customer-service type systems that send From: addresses with quoted
@domain addresses in them. Many of them do "user@address via"
, but not all.

And then there are the messages with 2 different From: addresses within
<>'s in them. I see those from Gmail sometimes.

And I see quite a few messages where the actual sender address is given
in quotes and then followed by the same address in <>'s.

So you will definitely get false positives just looking at @'s.

I've excluded the ones with " via" in them and add a bunch of extra
points if they come from phishy countries or have .doc or .pdf
attachments, and that hits fewer fps. And I'm only scoring if the
domain parts don't match.

Re: spoofing mail

[Alan Hodgson]

On Tue, 2018-11-27 at 11:22 -0600, Rick Gutierrez wrote:
> El mar., 27 nov. 2018 a las 11:14, Alan Hodgson
> () escribió:
> 
> > Wow, that's hard to read.
> > 
> > It was close to being tagged because of the Pakistan relay. Just
> > add a few points for Word docs and you should be good. Word docs
> > from spammy countries should really get a lot of points.
> 
> Hi Alan , I think it's a valid point, except for one thing, what
> happens if you do not attach a document?
> 

Malware/phishes are usually either in an attachment or the message has
a link. Personally I add a lot of points to either if they come through
questionable countries. Users can dig them out of their Junk if they
happen to be expecting a resume from Algeria.


> Something I want to ask you, where can I increase this score or in
> what rules?
> 
> 

You'd probably have to write your own. I'm not even sure where you got
that RELAY_PK rule from but I'd guess a download from Ironport or
something.

Personally I have one set of rules for classifying countries and a few
metas on top of those.

But you probably wouldn't want to use my rules; my servers are small
with homegenous user bases and they don't get real mail from, say,
Russia or Pakistan or the Sudan. You can tag a lot of real mail if
you're not careful writing rules.

Re: spoofing mail

[Alan Hodgson]

On Tue, 2018-11-27 at 10:42 -0600, Rick Gutierrez wrote:
> Hi , I have a situation a little complicated, I have emails from
> spammers that come with the name of one of my users, but the email
> address is not from my domain , they send it from a valid domain,
> which complies with spf, DKIM etc etc, some idea that could help me to
> adjust my spamassassin and stop this kind of post, someone has had
> experience in this type of evasion?
> 
> my user is lvelasquez
> 

Wow, that's hard to read.

It was close to being tagged because of the Pakistan relay. Just add a
few points for Word docs and you should be good. Word docs from spammy
countries should really get a lot of points.

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

[Alan Hodgson]

On Thu, 2018-04-26 at 13:41 -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 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").

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

Re: The "goo.gl" shortner is OUT OF CONTROL (+ invaluement's response)

[Alan Hodgson]

On Sun, 2018-03-18 at 17:14 -0500, David Jones wrote:
> 
I have Steve Freegard's DecodeShortURLs.pm installed but didn't get any 
> HAS_SHORT_URL hits on this one:
> 
> https://pastebin.com/t85b0Bns


Is it getting any hits? It definitely hits on that one in a test here.

Note it needs Perl's LWP::UserAgent and DBD::SQLite to get it to work
at all.

Re: Turn OFF SA spam filtering but keep ON header examination

[Alan Hodgson]

On Thu, 2018-01-18 at 18:49 -0500, Chip wrote:
> Very well stated.  Bravo!
> 
> The end point here is to examine the email headers that specifically
> refer to dkim and spf signatures.  Based on fail or pass, or some
> combination in concert with the sender's email address, they get moved
> into fail or pass folders.
> 
> That's it!
> 

If that's literally all you want to do, then have SpamAssassin score
every message at +50 with a generic local rule, and whitelist_from_spf
or whitelist_from_dkim the ones you want to keep. SA knows how to do
SPF and DKIM.

Then dump anything that passes SA into the pass folder, everything else
into fail.

Re: From name containing a spoofed email address

[Alan Hodgson]

On Wed, 2018-01-17 at 13:31 -0600, David Jones wrote:
> Would a plugin need to be created (or an existing one enhanced) to
> be 
> able to detect this type of spoofed From header?
> 
> From: "h...@hulumail.com !" 
> 
> https://pastebin.com/vVhGjC8H
> 
> Does anyone else think this would be a good idea to make a rule that
> at 
> least checks both the From:name and From:addr to see if there is an 
> email address in the From:name and if the domain is different add
> some 
> points?
> 
> We are seeing more and more of this now that SPF, DKIM, and DMARC
> are 
> making it harder to spoof common/major brands that have properly 
> implemented some or all of them.

I've been testing this:

header __LOCAL_CRAZY_MULTI_ATS From =~ /.*\@.*\@.*\@/
header __LOCAL_MULTI_ATS From =~ /.*\@.*\..*["\s].*\@[a-zA-Z0-9\-
]+\.[a-zA-Z0-9\-]+/
header __LOCAL_MULTI_ATS_SAME_DOMAIN From =~ /.*\@([a-zA-Z0-9\.\-
]+\.[a-zA-Z0-9\.\-]+).+\@\1[^a-zA-Z0-9\.\-]/i
meta LOCAL_FORGED_DISPLAY_DOMAIN ( __LOCAL_CRAZY_MULTI_ATS || (
__LOCAL_MULTI_ATS && ! __LOCAL_MULTI_ATS_SAME_DOMAIN ) )
describe LOCAL_FORGED_DISPLAY_DOMAIN From header appears to have a
forged domain in part of the address

... which tries to see if there are two @domain.names in the From and
score if they aren't the same domain.

I doubt it's usable yet, and I don't have the mail volume to look for
all the ways it breaks, but it's a start. I would appreciate tweaks.

Re: Malformed spam email gets through.

[Alan Hodgson]

On Mon, 2018-01-01 at 10:29 -0500, Bill Cole wrote:
> On 1 Jan 2018, at 9:59 (-0500), David Jones wrote:
> 
> > I think some mail systems will keep the same message-ID per email 
> > thread so your system must reject some replies.
> 
> I have not seen such behavior in the past 20 years...
> 
> Intentionally re-using another site's MIDs is so wrong that I'd
> happily 
> make it break hard.
> 
> HOWEVER, the idea of enforcing any standard on MIDs beyond gross
> format 
> (e.g.: <[[:ascii:]]{3,996}>) on a system where the admin isn't the
> sole 
> user is ludicrous.

I've had good success junking anything with one of my domains in the
message-id, where I know the mail isn't actually from someone in that
domain. That's a pretty solid spam signature.

Lack of any message-id is also significant, but sadly there are still
some real senders sending mail with no message-id.

Re: TO_NO_BRKTS_DYNIP

[Alan Hodgson]

On Mon, 2017-12-04 at 15:20 -0500, Joseph Brennan wrote:
> New rule: TO_NO_BRKTS_DYNIP
> 
> Since TO_NO_BRKTS_DYNIP is 2.361 and its component RDNS_DYNAMIC is
> 2.639, one gets an even 5.0 score just for sending from ec2-54-225-
> 189-51.compute-1.amazonaws.com without < > around the To address.
> 
> Should the amazonaws.com hosts not be in RDNS_DYNAMIC? I'm not silly
> enough to say they are free of spam customers, but they are
> definitely servers.
> 
> Joseph Brennan / Columbia U
> 
> 

Mail servers don't generally have generic reverse DNS, if they don't
want to be mistaken for end-user IPs or spambots.

https://aws.amazon.com/blogs/aws/reverse-dns-for-ec2s-elastic-ip-
addresses/

Re: FROM header with two email addresses

[Alan Hodgson]

On Wed, 2017-09-27 at 11:42 -0700, Miles Fidelman wrote:
> This could also be an attempt to get a mailing list to work.
> 
> There's a continuing problem with email list traffic getting bounced by 
> DKIM, and various work-arounds - the gist is that the mail has to come 
> from the list manager, but you still need a way to indicate the original 
> author of the message.  Hacks abound. But basically, DKIM is just broken.
> 

DKIM works fine. It is in fact working as intended when a signature
fails to validate against a message that has been modified in transit.

Mailing lists or other forwarders that modify signed portions of the
message without taking ownership of the From: header are just not
compatible with DKIM or DMARC-reject senders.

Re: Somewhat OT: DMARC and this list

[Alan Hodgson]

On Friday 19 May 2017 20:11:42 David Jones wrote:
> >Urgg, I see that now. I looked at a few of David Jones' posts to this list
> >and saw that they weren't DKIM signed, so I extrapolated that to a general
> >asumption.
> 
> They are DKIM signed so something must be striping the headers.
> 

Well, it's not the list. Others' signatures are coming through fine. 

I had to tell OpenDMARC to whitelist ena.com to get anything from you.

Re: Somewhat OT: DMARC and this list

[Alan Hodgson]

On Friday 19 May 2017 14:47:56 Dianne Skoll wrote:
> On Fri, 19 May 2017 20:43:39 +0200
> 
> Benny Pedersen  wrote:
> > some maillists break DKIM, forkus on that first, not last !
> 
> Thank you for not adding any value to the conversation.  The
> domain in question is not using DKIM.
> 

This is actually one of the few mailing lists that a DMARC p=reject domain can 
send anything to. Assuming they DKIM-sign their mail, of course. 

I would argue that setting a DMARC p=reject policy without working DKIM is 
fundamentally broken idea on the sender's part. They can't send bounces or 
vacation messages or anything else with a null envelope sender, for starters. 
Or send anything to anyone who forwards their mail to Gmail, at least 

I guess you can whitelist them if you care enough.

Re: Today's Google Docs phish

[Alan Hodgson]

On Thursday 04 May 2017 17:07:31 John Hardin wrote:
> I expect a basic accounts.google.com URI rule would be a good idea even if
> a redirector pattern for this was added - is there any legitimate reason
> for a "log in to your google account" URL to be in an email?
> 

Not from anyone who isn't whitelisted ...

Re: Matching To and Received addresses

[Alan Hodgson]

On Tuesday 28 March 2017 13:58:43 Alex wrote:
> I'd like to be able to use the fact that the To address is not the
> same as the address shown in the Received header in a meta of some
> kind.
> 
> How frequent would you think that would appear in ham alone? It's the
> basis for a number of phishing attacks here, so I'd like to see about
> using it in some way.
> 

Checking that the envelope recipient address is in To or Cc works great on my 
mail and also for any public role addresses like sales or support, but 
probably not so much for general users. Any BCC will hit such a rule.  And of 
course you have to exclude real mailing list mail.

I guess the question would be how many legit bcc's do your users get from non-
whitelisted senders?

Re: New whitelisting trick using from and spf

[Alan Hodgson]

On Monday 06 March 2017 11:58:25 David B Funk wrote:
> On Mon, 6 Mar 2017, Alan Hodgson wrote:
> >> It seems it should be easy to setup “If mail claims to be From:
> >> PayPal.com
> >> and is not from PayPal, score +100” but it is not.
> > 
> > This is what DMARC is for.
> > 
> > Run opendmarc as a milter and reject failures. Or score later on DMARC
> > failure, even if just selectively for highly phished domains.
> > 
> > PayPal publishes p=reject, on paypal.com at least, if not their other
> > domains.
> But that won't help you when the scammers set the user visible from as
> "acco...@paypai.com" or some other variant (with the actual address part as
> <acco...@example.com> or something else.
> 
> user-agents (such as OutHouse) by default only show the "comment" part of
> the address and hide the actual <> address part, making it easy for
> scammers to fool the non-tech savvy users.

Well, sure. And they can use any variant of paypal.whatever that they own, 
too, to show in better email clients. 

But you do what you can. Personally I've been flagging anything with paypal or 
pay pal anywhere in the From: that doesn't have a whitelisted PayPal domain's 
DKIM signature on it, but I don't know how well that scales.

Re: New whitelisting trick using from and spf

[Alan Hodgson]

> It seems it should be easy to setup “If mail claims to be From: PayPal.com
> and is not from PayPal, score +100” but it is not.

This is what DMARC is for.

Run opendmarc as a milter and reject failures. Or score later on DMARC 
failure, even if just selectively for highly phished domains. 

PayPal publishes p=reject, on paypal.com at least, if not their other domains.

Re: Keyword Whitelist?

[Alan Hodgson]

On Wednesday 11 January 2017 14:31:15 John Hardin wrote:
> That's more complex than needed. The message subject is automatically
> included in body rules, so you only need __LOCAL_BODY_PRODUCTS.
> 

Cool, I did not know that. txs.

Re: SA bayes file db permission issue

[Alan Hodgson]

On Thursday 09 June 2016 16:26:26 Yu Qian wrote:
> Yes, I am sure the path is correct, also, if the path is not correct, it
> will show 'db not present'.
> 
> I tried to write a small perl script to open the db file, it failed too. so
> I think it maybe the file damaged during the mounting. but I don't know why
> this can happen
> 

The docker container probably has a different DB version than your Mac.

Re: DMARC auto-away rejects

[Alan Hodgson]

On Monday, April 04, 2016 11:09:12 PM A. Schulze wrote:
> really?
> 
> I know DMARC as
> "example.com may dkim sign with example.com. relax alignment will
> match even for RFC5322.From sub.example.com"
> 
> but you claim
> "sub.example.com may dkim sign with sub.example.com a message with
> RFC5322.From example.com and that will be relax aligned"
> -> I don't agree.
> 
> see https://tools.ietf.org/html/rfc7489#appendix-B.1.2
> 
> 
> As "RW" pointed out: The message has a dkim signature mx.aol.com but
> RFC5322.From is the /parent/ domain
> That does not align and dmarc will not pass. It's AOL's fault.
> 
> Andreas

I really believe that's incorrect. Relaxed alignment specifically means you can 
sign with a subdomain's key or use a subdomain for SPF.

Read sections 3.1.2 and 10.4 of that same document, for instance.

Re: DMARC auto-away rejects

[Alan Hodgson]

On Monday, April 04, 2016 09:34:56 PM RW wrote:
> On Mon, 04 Apr 2016 13:18:54 -0700
> 
> Alan Hodgson wrote:
> > On Monday, April 04, 2016 08:59:51 PM RW wrote:
> > > I'm assuming that you are using these rules:
> > > 
> > > https://blog.laussat.de/2014/11/06/using-dmarc-in-spamassassin-native/
> 
> ...
> 
> > That's invalid, though. DMARC allows a subdomain to sign the mail
> > with a relaxed alignment policy. The original message should have
> > passed a DMARC test.
> 
> It's just a collection of rules that make use  of the dmarc dns
> lookup, it doesn't pretend to be a dmarc implementation. See the bottom
> of the page linked.

I see that, and it's a good disclaimer. I would disagree that those tests will 
work as intended in most cases, though. Many ESPs sign with subdomain keys. 
And clearly AOL is, too. Relaxed alignment is the DMARC default.

Re: DMARC auto-away rejects

[Alan Hodgson]

On Monday, April 04, 2016 08:59:51 PM RW wrote:
> I'm assuming that you are using these rules:
> 
> https://blog.laussat.de/2014/11/06/using-dmarc-in-spamassassin-native/
> 
> 
> meta DMARC_FAIL_REJECT !(DKIM_VALID_AU || SPF_PASS) &&
>  __DMARC_POLICY_REJECT
> 
>  __DMARC_POLICY_REJECT comes from a dns look-up which says that the
> policy is to reject. The rule will then fire if neither  DKIM_VALID_AU
> nor SPF_PASS hit.
> 
> SPF can't be  used here because there's no envelope sender, dkim
> passes but it's signed by mx.aol.com not by the domain in the
> header from address, so DKIM_VALID_AU doesn't get hit either.
> 

That's invalid, though. DMARC allows a subdomain to sign the mail with a 
relaxed alignment policy. The original message should have passed a DMARC 
test.

> > So ultimately who's at fault here for causing this to fail? AOL? What
> > should have been done to prevent it?
> 
> AOL, I guess.

Uh, no. The test is bad.

Re: how to fix this issue-spam

[Alan Hodgson]

On Thursday, February 04, 2016 08:05:59 PM Reindl Harald wrote:
> in context of "DKIM and DMARC are the present and near future" how do
> you imaine that to work if you have no clue who is sending on behalf of
> yours?
> 

Well you obviously have something emotionally invested in SPF.

But anyways DMARC explicitly has a full testing mode and a reporting feedback 
cycle - which actually works and is supported by some big mail receivers - so 
you can work through these issues during deployment.

Re: how to fix this issue-spam

[Alan Hodgson]

On Thursday, February 04, 2016 06:06:14 PM Reindl Harald wrote:
> before Google ist telling somebody something they should better learn
> the difference between "~" and "-" in a SPF record to make gmail.com at
> least on envelope-level spoofing protected
> 
> i high percentage of spam here would not only have been flagged but
> outright rejected if they would do their own homework
> 
> ;; ANSWER SECTION:
> gmail.com.  300 IN  TXT "v=spf1
> redirect=_spf.google.com"
> 
> ;; ANSWER SECTION:
> _spf.google.com.300 IN  TXT "v=spf1
> include:_netblocks.google.com include:_netblocks2.google.com
> include:_netblocks3.google.com ~all"

SPF strict outright breaks mail forwarding, unless the forwarder rewrites the 
envelope sender.

DKIM + DMARC is a much better compromise. It allows properly-signed mail 
forwarded intact to still pass DMARC checks.

The only significant forwarders that break DMARC are mailing lists, because 
they tend to change headers (especially subject lines) and add content to the 
message body, both of which break the DKIM signatures. Ironically, they also 
rewrite the envelope sender, so they didn't notice how broken SPF by itself 
was.

Mailing lists will need to learn to either not modify the message being 
forwarded, or else both rewrite the From: header and preferably remove any 
now-broken DKIM signatures. Or just refuse mail from DMARC-reject senders, 
which will eventually marginalize their use.

Neither mechanism is perfect, but I think everyone can agree that email needs 
to adapt to remain useful in a world full of criminals. And even more 
importantly, it does seem that DMARC-reject is gaining traction among big mail 
receivers.

Re: how to fix this issue-spam

[Alan Hodgson]

On Thursday, February 04, 2016 04:36:14 PM Reindl Harald wrote:
> 
> wait i tell you something (for you) new: DMARC and mailing-lists is a
> awful topic - what do you think would have happened with you mail to the
> list if your domain would enforce DMARC and my MX reject mails violating
> the policy?

Actually, it appears this list is one of the rare ones that would be fine with 
DMARC reject, since it doesn't break existing DKIM signatures.

Re: how to fix this issue-spam

[Alan Hodgson]

On Thursday, February 04, 2016 07:41:44 PM Reindl Harald wrote:
> which people don't know this?
> admins?
> don't maintain services then!
> 
> users?
> 
> just use the SMTP server your mailprovider tells you and no other one
> and for smtp-admins: just don't accept enevlope senders for which you
> would not accept incoming mail
> 
> that is as easy as something can be
> 

Yeah, it's really really not.

I'm in a 50 person company and we have our internal mail server, 3 different 
ESPs sending mail on our behalf for diffferent applications, Google calendar 
sending on our behalf, and 2 different SAAS customer service platforms sending 
as us. I can't even imagine how many different sources a large company has.

And SPF doesn't do anything about the only part of the message the users care 
about, the message headers.

In any event, SPF is legacy. DKIM and DMARC are the present and near future of 
mail services. DMARC uses SPF only as a fallback for broken or missing DKIM 
signatures.