Re: [mailop] Samsung and SIZE

On Sat, Jan 13, 2024 at 07:44:22PM +, Slavko via mailop wrote: > Dňa 13. januára 2024 19:14:58 UTC používateľ Sebastian Nielsen via mailop > napísal: > >Then you need to reconfigure server to ignore said parameters. > IMO, in other words, server (SHOULD reject) is RFC compliant, client > is

Re: [mailop] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

Hi Tim On Thu, Jan 11, 2024 at 05:02:01PM -0600, Tim Starr via mailop wrote: > The image has to be specified in the DNS, and it has to be certified w/ a > VMC. The VMC certification process includes checking if it's trademarked. That's why the process started with: get a trademark. Also such a

Re: [mailop] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

On Thu, Jan 11, 2024 at 01:45:19PM -0600, Tim Starr via mailop wrote: > To elaborate on Marcel's answer, so he doesn't have to waste time > explaining it all over again, the "different logo" won't be displayed by > the mailbox providers, because it's not the authenticated one. What prohibits them

Re: [mailop] ECDSA DKIM validation?

On Tue, Dec 19, 2023 at 10:21:55AM +0200, Taavi Eomäe via mailop wrote: > Considering how Gmail and quite a few widespread DKIM implementations still > don't support EdDSA DKIM, I wouldn't get my hopes too high. Please note that ECDSA != EdDSA. And EdDSA stuff only turned up in FIPS a short

Re: [mailop] key exchange parameters: ECDHE, DHE, RFC 7919

Hi On Wed, Jul 12, 2023 at 01:00:43AM +0300, Taavi Eomäe via mailop wrote: > On 11/07/2023 20:43, Bastian Blank via mailop wrote: > > Given that this host only reacts on port 25 but not on port 587, I > > assume this is MX. > Ideally one would offer implicit TLS on port 46

Re: [mailop] key exchange parameters: ECDHE, DHE, RFC 7919

Hi On Tue, Jul 11, 2023 at 05:47:12PM +0200, Paul Menzel via mailop wrote: > Testing the mail setup, I was surprised to have the key exchange parameters > flagged [1]: > > a1241.mx.srv.dfn.de.DH-2048 insufficient This test is for web or e-mail? MX or MSA? Given that this host

Re: [mailop] Bell.ca servers disconnecting before QUIT

On Tue, Mar 07, 2023 at 01:29:37PM -0500, David Sovereen via mailop wrote: > > On Mar 7, 2023, at 12:54 PM, Bastian Blank via mailop > > wrote: > > On Tue, Mar 07, 2023 at 12:26:41PM -0500, David Sovereen via mailop wrote: > >> I’m trying to reach someone at bell.c

Re: [mailop] Bell.ca servers disconnecting before QUIT

On Tue, Mar 07, 2023 at 06:54:31PM +0100, Bastian Blank via mailop wrote: > What are you doing? Please show a session transcript if you think there > are SMTP protocol problems. Okay, he seems to be mercury.net. | ;; ANSWER SECTION: | mercury.net. 2975 IN MX 10 mail.mercury.net. | mercu

Re: [mailop] Bell.ca servers disconnecting before QUIT

Hi David On Tue, Mar 07, 2023 at 12:26:41PM -0500, David Sovereen via mailop wrote: > I’m trying to reach someone at bell.ca who can help us with > two inter-related issues. Why do you link to http://bell.ca/? Or is that some unhelpful client again? > 1. Their SMTP servers

Re: [mailop] Does gmail accept unicode character in From domain? I don't think so

On Thu, Mar 02, 2023 at 04:38:16PM -0700, Alex Burch via mailop wrote: > I am using unicode in the From: not the MAIL FROM. Do you have to specify > it SMTPUTF8 in the MAIL FROM to use it in the From header? I don't see > anything about that here: https://www.rfc-editor.org/rfc/rfc6531 Without

Re: [mailop] Not-in-dane/mta-sts mx for tls fallback

Hi Jasper On Tue, Feb 21, 2023 at 08:40:06AM +0100, Jasper Spaans via mailop wrote: > At StartMail we've recently changed our incoming MXes to only allow > TLSv1.2 and 1.3 on incoming connections - but because there are still > some legitimate sources of mail that only support TLSv1 or 1.1 we've

Re: [mailop] Verizon's SMS to Email Features.. broken?

Hi On Tue, Dec 27, 2022 at 04:46:31PM -0800, Michael Peddemors via mailop wrote: > From:ph...@vzwpix.com > ^^^ Borked, no padding space after from Where in RFC 5322 does it require that space? | from= "From:" mailbox-list CRLF | mailbox-list= (mailbox *("," mailbox)) |

Re: [mailop] Spamhaus DNS issues causing all incoming mail to drop for me

On Thu, Nov 03, 2022 at 10:59:22AM -0500, Brian Knight via mailop wrote: > I'm seeing DNS issues this morning connecting to sbl.spamhaus.org. > > This morning, my Postfix server was rejecting all incoming emails as spam. > Found that the A record for sbl.spamhaus.org is gone, replaced with SOA

Re: [mailop] Microsoft Office365 blocking non Oauth2 authentication on IMAP and SMTP.

On Fri, Aug 19, 2022 at 10:19:55AM -0500, Mike Hammett via mailop wrote: > Down with big mail! ;-) As you seem to be unable to properly quote e-mails, but write them without showing what you refer to? Bastian -- Each kiss is as the first. -- Miramanee, Kirk's wife, "The

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

Moin On Thu, Aug 04, 2022 at 12:51:29AM +0100, Stuart Henderson via mailop wrote: > I think when acting as SMTP-over-TLS clients, most MTAs out there are > not checking the server's certificate in any really meaningful way; they > can usually be configured to do so but, last time I looked, there

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

On Wed, Aug 03, 2022 at 03:05:43PM -0500, Jarland Donnell via mailop wrote: > > You clearly see what TLS version and what ciphers were used. So you know > > if > > it was "secure" in your opinion or not. > I don't understand why Firefox did this: >

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

On Wed, Aug 03, 2022 at 02:46:06PM -0500, Jarland Donnell via mailop wrote: > You have SSL because you want to not only know that the server you are > connecting to is who they say they are, but also to secure the packets as > they transmit to your ISP, to their upstream, to the next upstream,

Re: [mailop] Spamhaus "open resolver" errors

On Fri, May 13, 2022 at 10:57:21AM -0600, Grant Taylor via mailop wrote: > Spamhaus has stated that they were going to disable access via high -- my > words -- open public recursive resolvers since the very first message they > published about this 3-6 months ago. I'm pretty sure I've read that

Re: [mailop] suggested max received headers/hop limit

On Sat, Mar 12, 2022 at 02:31:14AM +0100, Ángel via mailop wrote: > E.g. your email arrives to the on-premises MTA, which not finding a > local user passes it to Office 365 who doesn't have that either so it > is sent again to on-pre But this is a real mail loop. One system needs to be

Re: [mailop] Auto Unsubscribing Behavior

Hi Brian On Tue, Mar 08, 2022 at 03:10:29PM -0500, Brian Toresdahl via mailop wrote: > What we've seen, corroborated with cases across different sender domains, > and different recipient domains, is that emails, as soon as they're > delivered, are being immediately unsubscribed. We've had enough

Re: [mailop] Gmail POP3/SMTP and issue with SPF record

On Tue, Feb 22, 2022 at 02:38:31PM +, Laura Atkins via mailop wrote: > Very strange indeed. web-net.gr is not in any header > that I could see. Is there something in the links pointing to that? Because "web-net.gr" should be the Name of the Google organization, which

Re: [mailop] Gmail POP3/SMTP and issue with SPF record

Hi On Tue, Feb 22, 2022 at 03:58:50PM +0200, Christos Chatzaras via mailop wrote: > https://dpaste.com/8MNNRGMX4.txt > Looks like 209.85.216.48 which is a Gmail POP3 client is used as "sender IP" > and because we don't include include:_spf.google.com in the SPF record it > shows this warning:

Re: [mailop] DMARC Reports to aliexpress.com won't be delivered.

On Fri, Jan 28, 2022 at 10:57:08PM +0100, Jan-Pieter Cornet via mailop wrote: > Oh, and then there are a number of ticket systems or mailinglists behind > dmarc reporting addresses that usually reply with something like 'Your email > to our support system could not be accepted". Usually in such

Re: [mailop] DMARC verification issues at infomaniak.com

On Wed, Jan 26, 2022 at 12:54:50PM +0100, Renaud Allard via mailop wrote: > I am getting DMARC rejections at infomaniak.com. There seems to be an issue > in their DMARC verifications. I tested DMARC sending to gmail which confirms > me DMARC is OK for that domain. Please provide us with the DKIM

Re: [mailop] DMARC verification issues at infomaniak.com

On Wed, Jan 26, 2022 at 12:54:50PM +0100, Renaud Allard via mailop wrote: > I am getting DMARC rejections at infomaniak.com. There seems to be an issue > in their DMARC verifications. I tested DMARC sending to gmail which confirms > me DMARC is OK for that domain. The email you sent to this list

Re: [mailop] Anyone else notice that MS Hotmail/o365 might not be following RFC?

Moin On Mon, Nov 29, 2021 at 01:57:54PM -0800, Michael Peddemors via mailop wrote: > No, Pipeline is not advertised, the RFC's say that when you send a command, > if you are NOT using pipelining, you need to wait for a response, and that > includes the QUIT.. wait for the receiving system to send

Re: [mailop] spamhaus blocking Linode IPv6 (2a01: 7e01)

On Fri, Nov 26, 2021 at 09:34:44AM +0200, Mary via mailop wrote: > Unlike other providers like OVH and hetzner... Hetzner does not assign less then a /64 in all their current products. Bastian -- There is an order of things in this universe. -- Apollo, "Who Mourns for Adonais?"

Re: [mailop] AOL and Message-ID headers?

On Wed, Oct 13, 2021 at 03:34:48PM +, Steven Champeon via mailop wrote: > Seems it was sent from a US Cellular phone. She just sent me another via > the phone and it also lacks a Message-ID header. So, USC's phone mail > client is the culprit. And that's where it is up to you to stop ranting

Re: [mailop] m-365 still works like a spammer !

On Sat, Jul 24, 2021 at 05:14:17PM +0200, Xavier Beaudouin via mailop wrote: > I use greylisting... So there we have the problem. Microsoft decided to implement a mailsystem that does not use the same IP for different delivery attempts. Not really common, but not forbidden. Bastian -- First

Re: [mailop] m-365 still works like a spammer !

On Sat, Jul 24, 2021 at 12:38:34PM +0200, Xavier Beaudouin via mailop wrote: > Well it seems that RFC974 is deprecated and replaced by RFC 5321, section > 5.1. "MX > records contain a preference indication that MUST be used in sorting > if more than one such record appears (see below). Lower

Re: [mailop] m-365 still works like a spammer !

On Fri, Jul 23, 2021 at 09:44:38PM +0200, Thomas Walter via mailop wrote: > Regarding RFC974 >If the list of MX RRs is not empty, the mailer SHOULD try to deliver >the message to the MXs in order (lowest preference value tried >first). The mailer IS REQUIRED to attempt delivery to the

Re: [mailop] Anyone from Google here?

On Fri, Jul 16, 2021 at 12:09:10PM -0400, Eric Tykwinski via mailop wrote: > Just a heads up, I noticed some emails piling up in our spool. > Common part is McAfee's ad in the signature. This was already reported. Kill the ads with fire, Google is (IMHO correctly) considering them spam. Bastian

Re: [mailop] I disabled Spamhaus checking due to false-positives

Hi On Thu, Jul 15, 2021 at 04:29:24AM -0700, Mark Milhollan via mailop wrote: > Spamhaus has been working fine for me and has been a wonderful resource for > many years, but I recently decided I had to disable using them on my > personal, low volume mail server because of a few recent surprises

Re: [mailop] Feedback Loop in Gmail Postmaster tools does not show anything

On Wed, Jun 02, 2021 at 01:22:31PM +0200, Tim Düsterhus, WoltLab GmbH via mailop wrote: > Mail is being sent with a 'MAIL FROM:' > with the 'From:' containing an email address of the customer's custom > domain. > We're DKIM signing the emails using a key in the 'bounce.woltlab.cloud' > domain and

Re: [mailop] Carrierzone - Incorrectly Rewriting From and Return-Path Headers?

Hi On Thu, May 27, 2021 at 02:33:10PM -0500, Chris Adams via mailop wrote: > Emails leaving our platform have a proper From header. However, when they > are received by Carrierzone, both the From and Return-Path headers have had > the domain replaced with "sparkpostmail.com". It's almost as if