Re: [mailop] Super dumb gmail request ...

2024-09-01 Thread Matthew Richardson via mailop
Viktor Dukhovni wrote: >The flaw for me is that TOTP involves using phone apps I don't know >the provenance of, that back up the data in a format I don't know >to my "Google Drive", which is the most protected place I'd choose. > >If the app I'm using stops being available, I don't currently a >ha

Re: [mailop] Super dumb gmail request ...

2024-08-31 Thread Matthew Richardson via mailop
Viktor Dukhovni wrote:- >I care to keep my account indefinitely, and current second factors don't >in my view clearly possess demonstrate the requisite longevity. I also wish to keep accounts/credentials indefinately, and think I have concluded that this can be adequately achieved using TOTP as w

Re: [mailop] Proofpoint breaking delivery for Google Workspace

2024-08-04 Thread Matthew Richardson via mailop
Tobias Fiebig via mailop wrote:- >This setup is sadly rather common. Similar to the alternate >combination: Proofpoint + Office 365/Exchange Online. > >As to the _why_,... I wish I knew. A similar setup, using Mimecast more often than Proofpoint, is fairly common over here in Jersey (in the Chan

Re: [mailop] Reason for being listed at Spamhaus CSS and XBL unclear

2024-04-19 Thread Matthew Richardson via mailop
Sebastian Arcus via mailop wrote:- >> Michael's suggestion of checking for compromise of CPE (routers etc) is >> also well worth pursuing. > >I have though about that as well. The only possibility that I can come >up with is the Fritzbox VDSL modem/router sitting in front of the Linux >gateway/f

Re: [mailop] Reason for being listed at Spamhaus CSS and XBL unclear

2024-04-18 Thread Matthew Richardson via mailop
Sebastian Arcus via mailop wrote:- >In that case I think I am back to square one. If an infected device >connecting to 587/465 to various servers on the internet, from our >network, to try and guess passwords/break into accounts wouldn't have >used the FQDN of our public IP as HELO - then that

Re: [mailop] mimecast "antispoofing"

2024-03-06 Thread Matthew Richardson via mailop
The "anti-spoofing" policies within Mimecast are configured on a customer by customer basis. These policies are a fairly blunt tool, and are set by default on new Mimecast accounts. They can apply to the "From:" header, the sender envelope address or both. The member should be able to take it up

Re: [mailop] Bounce Address Tag Validation (BATV) versus Spam Filtering

2022-10-18 Thread Matthew Richardson via mailop
es VERP to help with bounce processing is going to >have a mismatched return-path/envelope sender. >IMHO, hasn't really been a good spam sign for a good long time. > >Cheers, >Al > >On Thu, Oct 13, 2022 at 9:22 AM Matthew Richardson via mailop > wrote: >> >&g

[mailop] Bounce Address Tag Validation (BATV) versus Spam Filtering

2022-10-13 Thread Matthew Richardson via mailop
I have an issue with email from one domain being repeatedly mis-classified as spam by assorted receivers, including Messagelabs. Looking at their outgoing email, I notice that it uses BATV, the Internet Draft https://datatracker.ietf.org/doc/html/draft-levine-smtp-batv having been written by folks

Re: [mailop] Best practice for mailing list servers

2022-06-14 Thread Matthew Richardson via mailop
Ken O'Driscoll wrote:- >* Use different DKIM keypairs for each list Out of interest, why? Are there any known issues with using the same keypair across multiple lists, or indeed across multiple sending domains? -- Best wishes, Matthew ___ mailop maili

Re: [mailop] Email System Testing Methodologies?

2022-06-13 Thread Matthew Richardson via mailop
Slavko:- >D?a 13. júna 2022 11:19:08 UTC používate? Matthew Richardson via mailop > napísal: > >>One item to be aware of is that the outgoing servers (which return the >>messages) do DANE validation, and thus will not deliver to any servers with >>failed DANE. > >

Re: [mailop] Email System Testing Methodologies?

2022-06-13 Thread Matthew Richardson via mailop
Jesse Hathaway:- >I am working on some architectural changes to our email systems at the >Wikimedia Foundation[1] and I am a bit befuddled as to the best way to >test changes to the current system. As you all are all aware email is a >distrubted system which encompases a wide variety of protocols.

Re: [mailop] Exchange 365 outbound connector being used as a relay

2022-01-29 Thread Matthew Richardson via mailop
Alexander Huynh via mailop wrote:- >On 2022-01-29 09:15:02 +0000, Matthew Richardson via mailop wrote: >> You may wish to have some authentication between O365 and Exim. The MS >> document linked discusses how to do this with certificates. > >The certificate setup listed

Re: [mailop] Exchange 365 outbound connector being used as a relay

2022-01-29 Thread Matthew Richardson via mailop
Alexander Huynh via mailop wrote:- >Meaning that domains `outlook.com` and `mail.alokind.com` have managed to use >Exchange >365 infrastructure to try and route email through my connector. As a thought (probably wrong) could this be caused by your O365 users forwarding INCOMING email to them FR

Re: [mailop] Spamcop

2021-02-01 Thread Matthew Richardson via mailop
On Sun, 31 Jan 2021 09:01:39 -0800, Don Owens via mailop wrote:- >We have the domain back now, but we have to wait for propagation delays. If >you query the name servers they Arne mentioned, that should give you the right >IPs. > >Sorry for the trouble, folks. Now I have to go see who needs flo

Re: [mailop] DNS issues for CloudFilter?

2021-01-12 Thread Matthew Richardson via mailop
lop >To: "Matthew Richardson via mailop" >Cc: >Date: Tue, 12 Jan 2021 08:24:36 -0500 >Subject: Re: [mailop] DNS issues for CloudFilter? >On 12 Jan 2021, at 3:02, Matthew Richardson via mailop wrote: > >> That NS is provided by AWS Route53. My experience is t

Re: [mailop] DNS issues for CloudFilter?

2021-01-12 Thread Matthew Richardson via mailop
That NS is provided by AWS Route53. My experience is that they have some sort of internal propriatory propagation of updates which does not use the serial number. Looking at another zone, I also think that they leave the serial number at 1 all the time. Best wishes, Matthew -- >From: Bill C