Re: WARNING: Microsoft has earned removal from SA default welcomelist

[Jared Hall via users]

On 4/12/2024 1:20 PM, Bill Cole wrote:

In my opinion, this is an indication that the default welcomelist entries in 
the official SpamAssassin rules for '*@*.microsoft.com' are inappropriate. Note 
that there is an entry for '*@accountprotection.microsoft.com' which is still 
justified as far as I know. This is entirely unrelated to any domains hosted by 
Microsoft, it is strictly an email address welcomelisting (see SA docs for 
details.)

+1

This may raise some questions and trigger a debate on the formal meaning of the 
SA default welcomelist entries. That debate belongs on the SpamAssassin Users 
List, but may pop up elsewhere. I believe that we have left a gap there in 
having a quite vague definition of what default welcomelist entries represent. 
As far as I know, clear criteria for inclusion have never been promulgated and 
accepted by the PMC or the user community.

+1

Re: OT: Microsoft Breech

[Jared Hall via users]

On 3/18/2024 10:13 PM, Jimmy wrote:


It's possible that certain email accounts utilizing email services 
with easily guessable passwords were compromised, leading to abuse of 
the ".onmicrosoft.com " subdomain for sending 
spam via email.


Well, there's (1) standard BEC, (2) stolen Exchange Administrator 
credentials, and (3) creation of new Microsoft 365 hosts.  While 
.onmicrosoft.com encompasses the entire Microsoft 365 world, including 
GoDaddy 365 resale, it is worse than that.  In Microsoft's case, the 
Azure Administration keys were pilfered as well.  Probably most of us 
here have all seen the residual fallout from all the bogus 365 hosts.


In a couple of cases, Exchange Administration credentials (where you 
setup DKIM/SMTP and the initial .onmicrosoft.com hostname) were 
changed such that they can no longer log in.  They still have the 
Account and Mailbox Administrator permissions so they can still 
add/delete Accounts and Mailboxes.


Microsoft asserts that no billing information was compromised and to be 
fair, I've seen no evidence of compromise.  Zero cred, IMHO.

Typical Microsoft:  System Down, Billing Up



I've observed an increase in the blocking of IPs belonging to 
Microsoft Corporation by the SpamCop blacklist since November 2023, 
with a notable spike in activity during February and March 2024.


Yes, you are correct.  I see there is a spat between Microsoft and 
SpamHaus also.  Poor, poor Microsoft.


Thanks,

-- Jared Hall

OT: Microsoft Breech

[Jared Hall via users]

I've several customers whose accounts were used to send spam as a result 
of Microsoft's infrastructure breech.


Curiously, NOBODY has received any breach notifications from Microsoft, 
despite personal information being compromised.


What has anyone else experienced?

Thanks,

-- Jared Hall

Re: SHTML file extension handling?

[Jared Hall via users]

On 3/12/2024 4:04 PM, Benny Pedersen wrote:

Jared Hall via users skrev den 2024-03-12 20:37:
Is there a use case for emailing .shtml files, or can these just be 
simply discarded?


i have seen .html attachment

only reason i think its tryed was to skip url testing in spamassassin

might be same for shtml

i still have the clamav rule to reject mail with this attacments

it just long time since i have seen it, so might aswell be no go for 
spammers :)




OK,  Thanks.

-- Jared Hall

SHTML file extension handling?

[Jared Hall via users]

Is there a use case for emailing .shtml files, or can these just be 
simply discarded?


Thanks,

-- Jared Hall

mimeheader multiple?

[Jared Hall via users]

SA 3.4.6.

Is there any way to create a rule that hits emails with duplicate
filename attachments?

   MAIN HEADER DECLARATION:

   Content-Type: multipart/mixed; boundary="=-6aIz+S039AYG/4raFdExeg=="

   BODY PART MIME HEADERS:

   --=-6aIz+S039AYG/4raFdExeg==
   Content-Type: application/octet-stream; name=1341251248.pdf
   Content-Disposition: attachment; filename=1341251248.pdf
   Content-Transfer-Encoding: base64

   

   --=-6aIz+S039AYG/4raFdExeg==
   Content-Type: application/octet-stream; name=1341251248.pdf
   Content-Disposition: attachment; filename=1341251248.pdf
   Content-Transfer-Encoding: base64

   

I can hit on the Content-Disposition header regex fine, but tflags/multiple
doesn't seem to work here.  I'm not sure if this is a problem (1) with the
Mimeheader plugin, (2) working as designed, (3) or a fault in my system.

Any suggestions?

Thanks,

-- Jared Hall

Re: Question about forwarding email (not specifically SA, pointers greatly appreciated)

[Jared Hall via users]

On 1/2/2024 5:24 PM, Thomas Cameron via users wrote:


The problem is, when I send email to presid...@myassociation.org, 
gmail rejects the forwarded email because it appears to come from my 
personal domain, not the mythical myassociation.org domain. DKIM, 
DMARC, and SPF all fail, which I totally understand.


How can I make this work? Is there a good way to use something like 
/etc/aliases to forward emails to the domain I manage to another 
recipient? Or is there something better I can do?




You will probably find that forwarding Emails to most systems, including 
MSN/Live/Hotmail/Outlook and Yahoo/AOL works OK (for now).  But if you 
want Vacation/Out-Of-Office/Autoresponders to work to Gmail addresses, 
you MUST run DKIM on your managed domain.  Even valid SPF alone will NOT 
do.


Implementing DKIM w/ DMARC is a good, if not the best, practice. 
Considering present trends, SPF/DKIM/DMARC Auth-neutral will become the 
new "bad".


I apologize this isn't strictly SA related, I am just hoping someone 
can give me advice or provide I link to follow on how to make this work.


package: opendkim + access to your managed domain's DNS records.


$0.02,

-- Jared Hall