Re: [mailop] [EXTERNAL] Re: is warming IPs still necessary?
IP reputation and domain reputation are both vital when moving a server/service. Even for low visibility mailer domains. Checking the neighbourhood is an important element of that planning. Laura I thought your blog post on DKIM very good. I've had several examples of crap concatenation and similar to your points with secondary DNS using different software giving unpredictable resolution. The first time I came across it several years ago it took a while to get to the bottom of it. It's a bit of a minefield. Are people using any opensource tools to help small providers / volunteers for micro NFPs to automate / discover / manage / keep an eye on such configurations? Christian Laura Atkins via mailop writes: > On 26 Mar 2024, at 17:48, Brotman, Alex via mailop wrote: > > I'm not on the sending side, but I will note there are several ESPs running > out of EC2. Some seem to use their > own IP ranges, some do not. > > Yeah, and they had problems in the past where some major ISPs were blocking > all space from EC2 and their mail > was having a horrible time getting through. I think they worked with the ISPs > to establish a way to special case > that IP space. > > I think if you're coming from an IP range you don't have direct control over > (i.e., cloud space), you must take > extra precaution to warm the IPs ( and domains, and click-track URLs, and > and and ..). Understand you're > going to have garbage neighbors (if you don't bring your own ranges), and > understand the implications of > that. > > Exactly. > > laura -- Christian de Larrinaga ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] openssl on Ubuntu 20.04 - implications for email
As far as I know OpenSRS DNS refuses DKIM keys longer than 1024 to this day despite my and I expect many others asking and asking and asking ... If they've changed this do educate me. As they haven't Christian Brandon Long via mailop writes: > On Thu, Jan 7, 2021 at 5:57 AM Dan Malm via mailop > wrote: > >> On 2021-01-06 20:10, Tim Bray via mailop wrote: >> > My thoughts are `time for mail operators to pull their fingers out and >> > upgrade`. Because we are really saying `upgrade to something less than >> > 8 years old` >> >> I fully agree. The state of TLS in the mail world is quite sad and it >> would be great if we could all agree on actually keeping our systems up >> to date... The problem is that it's not a system that I or you control >> that need updating, it's someone else's. And our business model is not >> "internet compliance police" it's providing a service that (among other >> things...) delivers emails that our customers want to send, and as long >> as the big giants in the industry are not the ones initiating this type >> of change, the reaction from customers whose mail we can't deliver will >> usually be one of "I don't care about security", "I'm just sending a >> picture of my cat so security doesn't matter for this particular mail" >> or "but (gmail|hotmail|yahoo) could send mails to this address perfectly >> fine so why can't you?" >> >> The day gmail stops delivering to servers with legacy SSL I'll be happy >> to do the same. >> > > By the definition of SSL3 is legacy, that's been true for years. > > I don't know enough about the different cyphers to know if we > still allow stuff that this change prohibits, though. > > We do still allow administrators to create 1024 bit DKIM keys because > when we tried to change it, a large number of admins and the web-based DNS > admin consoles they used couldn't handle the larger keys. That was years > ago, > though, so I don't know what the current status of those consoles is. > > We should have updated our services to handle keys and rotations better > like O365 does, but > that still hasn't happened yet. > > Brandon > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Christian de Larrinaga https://firsthand.net ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] openssl on Ubuntu 20.04 - implications for email
life is too short sometimes for gaming poor system utilities and then waiting for an update that breaks your game arbitrarily Al Iverson via mailop writes: > On Fri, Jan 8, 2021 at 2:22 AM Brandon Long via mailop > wrote: >> >> We do still allow administrators to create 1024 bit DKIM keys because >> when we tried to change it, a large number of admins and the web-based DNS >> admin consoles they used couldn't handle the larger keys. That was years >> ago, >> though, so I don't know what the current status of those consoles is. > > We still get a non-zero amount of pushback when we hand client a DNS > zone containing their 2048-bit DKIM key, with the same old reason, > they can't make it work because it's too big to paste into a single > DNS TXT record and they can't figure out how to work around it (or > their tool won't do it for them). I've taken to including links to > FAQs that tell people how to break up a long DKIM TXT record. Tools do > still need to get better at just handling this automatically and > easily. -- Christian de Larrinaga https://firsthand.net ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] New server email being treated as spam by Google
Hi Paul, I've migrated a couple of mail servers over to hosts on mythic beasts in the last few months. Both have been working fine with gmail address delivery. I have been using the Sympl software scripts and Mailman on v4 an v6. I've used existing domains that have been registered and used for email over several years and used these as hostnames as well, rather than the default mythic beasts vs hostnames. One other thing is to make sure you setup the reverse DNS - that is available as an option using the mythic beasts hosting panel. best Christian Paul Waring via mailop writes: > In the last week or so, I migrated my xk7.net email from one self-hosted > server to another. Both servers were setup in a similar way and adhered > to all the email best practice guidelines I could find (DKIM, SPF and > DMARC all pass, the server isn't on any public blocklists, and there are > no mailing lists on the server which might result in emails getting > marked as spam). > > Since the migration, any email sent to any domain hosted by Google > (gmail.com, G Suite customers etc.) has gone straight into the > recipient's spam folder. This happens regardless of whether I initiate > the conversation or am replying to an existing email, whether I'm in the > recipient's address book or not, and how many emails we've exchanged in > the past. > > Email to all the other major providers (Yahoo, Microsoft etc.) is > delivered to the recipient's inbox, and I've also tested against > sysadmin friends who have super-strict RFC conformity servers without > any problems. > > Before I change any more settings, I was wondering if there was a time > period during which Google treats a new server that it hasn't seen > before as a spam source? If this is something that will go away after a > few more days then there's not much point in me tweaking further. > > Thanks > > Paul -- Christian de Larrinaga https://firsthand.net ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] BIMI pilot @ Google
I am aware of DKIM and DMARC and SPF. You wil note this email address which I self host uses all three. As do all domains I run for email. My question is is it useful? - given so many lists even one dedicated to email management give "red" unsigned flags - that I get a ton of spam '/ phishing and such all beautifully signed by DKIM even with DMARC etc. which not only get through that filtering but also zen.spamhaus... etc - given most email domains which do use DKIM don't use strict and in most cases for good reasons. It may help and that may be good enough for those tools. But clearly it isn't a "solution". More a sticky plaster applied to do the job of a tourniquet C On 24/07/2020 17:10, Robert L Mathews via mailop wrote: On 7/24/20 2:51 AM, Christian de Larrinaga via mailop wrote: All emails on this list are showing with red DKIM signed boxes That's because this list alters the message From header and body without re-signing it. (If the list re-signed outgoing Mailman messages with a "mailop.org" DKIM signature, it would work.) Is this useful? Sure: It's saying you got a message claiming to be from mailop@mailop.org that isn't signed by mailop.org, which is exactly what it's supposed to do. Whether one decides to trust something less based on that is a different matter. For example, I care about the DKIM verifier result for messages claiming to be from my bank, but I don't worry about it for list messages. That said, if every MUA showed DKIM results, I suspect there would be a lot more DKIM signing just based on the naive complaints it would generate. Few people cared about making sure their non-financial website used SSL until every browser started claiming it was "not secure". ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] BIMI pilot @ Google
On 23/07/2020 20:06, Andrew C Aitchison via mailop wrote: Are there that many IMAP based mail clients which feature contact avatars? Apparently there is a Thunderbird addon 'dkim verify' which uses the favicon of the signing domain: https://stackoverflow.com/questions/59465208/thunderbird-icon-in-from https://addons.thunderbird.net/en-GB/thunderbird/addon/dkim-verifier/versions/ https://github.com/lieser/dkim_verifier/wiki/Options#use-dmarc-to-heuristically-determine-if-an-e-mail-should-be-signed It is DMARC aware and supports Thunderbird v68 but not yet the latest v78. I installed it on Monday when I pushed focal fossa onto my laptop but stuck with an updated v68. It shows a coloured box on the menu bar. Green for compliant and Red when not .. blue when it can't check the DNS. All emails on this list are showing with red DKIM signed boxes Is this useful? I'd much prefer to see Thunderlink or equivalent which Mozilla trashed. That is very useful - even essential. So I may have to fall back on gnus... urgh! C ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
