On 2022-11-08 23:55, Brandon Long wrote:
On Tue, Nov 8, 2022 at 3:45 PM MRob via mailop
wrote:
On 2022-11-08 22:51, Brandon Long via mailop wrote:
> Validating From headers is the whole thing behind DMARC. Yes, an MSP
> should validate the From header for mail it originates, but there are
>
That is an office 365 free trial account. There is some massive abuse of these
going on over a period of time. However there is also a ton of legitimate
traffic.
--srs
From: mailop on behalf of MRob via mailop
Sent: Wednesday, November 9, 2022 5:17:09 AM
To: m
On Tue, Nov 8, 2022 at 3:45 PM MRob via mailop wrote:
> On 2022-11-08 22:51, Brandon Long via mailop wrote:
> > Validating From headers is the whole thing behind DMARC. Yes, an MSP
> > should validate the From header for mail it originates, but there are
> > often
> > cases such as various kinds
Is envelope sender user@.onmicrosoft.com normal in non-spam
mail? Is it how all microsoft mail comes through? Or is it usually spam
from badly configured domain? Should part *always* match
sender domain in FROM header?
On the other hand, if mail come from microsoft server *not* through
"onmi
On 2022-11-08 22:51, Brandon Long via mailop wrote:
Validating From headers is the whole thing behind DMARC. Yes, an MSP
should validate the From header for mail it originates, but there are
often
cases such as various kinds of relaying, where doing so is not
possible.
One can use DMARC or ot
Isn't *.onmicrosoft.com actually valid? Though typically not used, I'm
fairly certain it's interchangeable for the user's domain on an Office
365 subscription. I was trying to find something to validate my memory
and I think this backs it:
https://learn.microsoft.com/en-us/microsoft-365/admin/s
Hello,
Why isnt it standard to put the envelope sender into the RECEIVED
header?
Does any MTA do it?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Another one I've seen is an extra newline which ends the headers, ie:
Subject: foo
To: b...@example.net
From: campa...@example.org
I don't recall how annoying our parser is, whether something like this
would also cause early end of headers:
Subject: foo
To: bar@
example.net
From: campa...@examp
Validating From headers is the whole thing behind DMARC. Yes, an MSP
should validate the From header for mail it originates, but there are often
cases such as various kinds of relaying, where doing so is not possible.
One can use DMARC or other heuristics to try and figure that out when
forwarding
Hello,
Microsoft doesn't limit FROM header spoof? I saw message like:
Envelope from: example.user207@.onmicrosoft.com
To:
From: support@
For example if TO=rob...@example.com then FROM=supp...@robert.com
Is too complicated for microsoft check the FROM header belong to the
senders account?
Is
I've seen this before, when the header above the From header is broken:
Authentication-Results: server;
dkim=blah reason="blah";
From: "Valid"
To: mailop
The parser thinks that the From: header is part of the previous header, thus
ignoring it and ending with a missing header
We've seen the below failure for two different clients (each in one
specific campaign) which resulted in lots of these failures at Gmail for
those respective campaigns. Our Support/Ops team continue to insist that
we sent these campaigns with the same exact from address/header/domain set
up as all
On Tue, 08 Nov 2022 11:46:20 -0500, Bill Cole via mailop
wrote:
>Meanwhile, my boss tried working another route and has opened 2 tickets:
>SRX1544040988ID asking for just the one IP and SRX1544076120ID for the whole
>/24. Got the dreaded "Not qualified for mitigation" boilerplate response to
>
My main employer (CipherSpace) runs a mail system with a few dozen SMB customer
domains and a long low-volume history of good behavior. ~2 weeks ago we had an
end-user password cracked an a very sneaky spammer managed to get through a
couple thousand spams over the space of about a day, at a slo
14 matches
Mail list logo
