Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

> On 18.05.2024 at 21:02 Dave Crocker via mailop wrote: > > On 5/17/2024 7:12 AM, Taavi Eomäe via mailop wrote: >> Although some of these dangers have been known for a while (some parts are >> even described in the RFC itself), things like the threat landscape, our >> approach and the extent

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

> On 17.05.2024 at 16:24 Taavi Eomäe via mailop wrote: > > Although some of these dangers have been known for a while (some parts are > even described in the RFC itself), things like the threat landscape, our > approach and the extent to which this can be abused have changed. In our > opinion

Re: [mailop] Line too long

On 17.05.2024 at 08:48 Cyril - ImprovMX via mailop wrote: > I've got an email from one of my user telling me our server refused an email > because of a line too long. > The issue is referenced in the RFC at > https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.3.1.6 and we follow > and

Re: [mailop] Someone at Google (GSuite) with a clue?

On 13.05.2024 at 17:12 von Aaron C. de Bruyn via mailop wrote: > While it was a groups permission issue, the GSuite logs for GMail do *not* > show anything about a permission problem. See attached photo (if the list > supports attached photos). Usually Google delivers a DSN from

Re: [mailop] "The email didn't arrive" to Office 365

> On 09.05.2024 at 20:21 Jarland Donnell via mailop wrote: > > Quick question for you experts. What do you find to be the most common root > cause for reports of emails not being received by Office 365 domains, when > you can confirm conclusively that Microsoft accepted the email? Obviously >

Re: [mailop] Strange Behavior from Microsoft IP Address

On 07.05.2024 at 17:12 Vitali Quiering via mailop wrote: > We've identified an IP address, notably tied to Microsoft (20.203.218.75), > executing thousands of hits on our URLs almost immediately after dispatching > a newsletter. However, the peculiar part is the variation in the hash >

Re: [mailop] Gmail + Spamhaus "technical values and unusual sending behaviors"

On 06.05.2024 at 19:22 K. M. Peterson via mailop wrote: The latest rejections, this morning, were from iCloud.com and indicated that the sending IP was on the Spamhaus BL list - with a link to query Spamhaus for more info. But the link returns that the IP "has no issues". Last week,

Re: [mailop] any postmaster or contact to knauf.com around? delivery issues

On 30.04.2024 at 12:34 Stefan Bauer via mailop wrote: knauf.com is accepting much of our delivered mails, however afterwards probably drop them as recipients reported via phone, that none of the mails arrive in their mailboxes. Mail to postmaster@ and a known contact at

Re: [mailop] random.onmicrosoft.com SPAM

On 21.03.2024 at 00:46 Robert Giles via mailop wrote: > Seeing this type of stuff quite a lot originating from legitimate Microsoft > infrastructure, and their abuse desk never seems to take any action; I > suppose dropping any *.onmicrosoft.com envelope-from is probably the right > course of

Re: [mailop] mailop and DKIM signatures

> On 16.03.2024 at 17:06 Marco Moock via mailop wrote: > > Wouldn't it be better to remove that and add mailop's own DKIM > signature, that will pass? Depending on the kind of changes which have been applied to the message you can reverse the transformations and verify the original DKIM

Re: [mailop] Ubuntu Noble/24.04 - TLS 1.0, 1.1 and DTLS 1.0 are forcefully disabled

On 14.03.2024 at 09:37 Cyril - ImprovMX via mailop wrote: > We previously were accepting only TLS 1.2 and higher and I was surprised to > see the amount of senders not being able to find common ciphers (I had mostly > encounters with Cisco users), so we decided to also accept TLS 1.0 and 1.1. >

Re: [mailop] Ubuntu Noble/24.04 - TLS 1.0, 1.1 and DTLS 1.0 are forcefully disabled

On 13.03.2024 at 18:25 Kai Bojens via mailop wrote: > On 2024-03-13 00:09, Andrew C Aitchison via mailop wrote: >> Given that the advice for SMTP is often to allow tls 1.0 and 1.1, >> rather than have it revert to unencrypted, this will is something to >> watch out for. > TLS 1.0/1.1 have been

Re: [mailop] Ubuntu Noble/24.04 - TLS 1.0, 1.1 and DTLS 1.0 are forcefully disabled

On 13.03.2024 at 12:28 L. Mark Stone via mailop wrote: > FWIW, our view is that poor encryption can be worse than no encryption, as it > can give the participants a false sense of security. This seems like a good > move to us. > We have configured Postfix in our Zimbra MTA servers to do only

Re: [mailop] Dot as the first character of a line ? (RFC 5321, Section 4.5.2)

> On 04.03.2024 at 11:42 Slavko via mailop: > > And what does aiosmtpd with message after it receive it? I guess, that it is > sending it out (to gmail), thus it acts as client... Does it quote (double) > that dot when message goes out? Just a little nitpick: aiosmtpd is a Python library to

Re: [mailop] Dot as the first character of a line ? (RFC 5321, Section 4.5.2)

On 01.03.2024 at 17:46 Cyril - ImprovMX via mailop wrote: Upon investigation, we discovered that indeed, checking the DKIM signature was failing because of a body mismatch. Digging further, we discovered that a dot was removed from the message when going through our servers. It turns out that

Re: [mailop] Outgoing Spam from Microsoft IPs

> On 19.02.2024 at 17:15 Michael Peddemors via mailop wrote: > > On 2024-02-19 04:46, Gellner, Oliver via mailop wrote: >>> On 16.02.2024 at 03:38 Matt Palmer via mailop wrote: >>> Although I must say that >>>> without reverse DNS >>> wou

Re: [mailop] Outgoing Spam from Microsoft IPs

On 16.02.2024 at 03:38 Matt Palmer via mailop wrote: > Although I must say that >> without reverse DNS > would seem to be the easier blocking option -- when was the last time you saw > legitimate mail from an IP without rDNS? Unfortunately every day. It's true that 99% of legitimate senders

Re: [mailop] Is forwarding to Gmail basically dead?

> On 15.02.2024 at 03:55 Philip Paeps wrote: > > On 2024-02-15 02:51:17 (+0800), Gellner, Oliver via mailop wrote: >>> On 13.02.2024 at 17:05 John Levine via mailop wrote: >>> More to the point, whether it's DKIM nor S/MIME or PGP, bad guys can >>> and do sign

Re: [mailop] Is forwarding to Gmail basically dead?

> On 13.02.2024 at 17:05 John Levine via mailop wrote: > It appears that Taavi Eomäe via mailop said: >> >> On 13/02/2024 05:16, John Levine via mailop wrote: >>> Right now if you get a message from Gmail or Yahoo with a valid DKIM >>> signature, you >>> can be quite confident that it came

Re: [mailop] Is forwarding to Gmail basically dead?

> On 13.02.2024 at 10:11 Taavi Eomäe via mailop wrote: > > I've described one of the reasons why that's the case. The other reason is > probably the fact that key management is incredibly difficult. Which is also > probably why it has seen adoption in environments that simplify it - large >

Re: [mailop] Is forwarding to Gmail basically dead?

Am 11.02.2024 um 18:40 schrieb Sebastian Nielsen via mailop : >> because SPF is too easy to forge.) Wrong. When a shared space is used, its up to that particular space, to enforce so customers cannot use other customer’s email addresses. In the same way you cannot, and should not be able to

Re: [mailop] Is forwarding to Gmail basically dead?

On 09.02.2024 at 18:22 schrieb Scott Mutter via mailop wrote: On Fri, Feb 9, 2024 at 9:56 AM Gellner, Oliver via mailop mailto:mailop@mailop.org>> wrote: While I'm no advocate on external email forwarding, SPF does not perform a good job on identifying emails regardless of forwarding

Re: [mailop] problem setting up open-dmarc

On 09.02.2024 at 22:19 Hans-Martin Mosner via mailop wrote: Am 09.02.24 um 16:20 schrieb Gellner, Oliver via mailop: A not really serious reply: I'm interested to learn how I can get amused by looking at XML data, this would greatly improve my professional life. Until now I have been more

Re: [mailop] Is forwarding to Gmail basically dead?

On 09.02.2024 at 15:51 Scott Mutter via mailop wrote: > On Thu, Feb 8, 2024 at 12:20 PM Randolf Richardson, Postmaster via mailop > wrote: >> Spammers forging eMail accounts is the primary reason SPF and DKIM >> are so prevalent these days. >> I believe the day will come when it will be

Re: [mailop] problem setting up open-dmarc

On 07.02.2024 at 18:17 John Levine via mailop wrote > You might as well publish a p=none DMARC record anyway so you can collect the > reports. Some of them can be quite amusing. A not really serious reply: I'm interested to learn how I can get amused by looking at XML data, this would greatly

Re: [mailop] Looking for feedback on the Certified Senders Alliance (CSA)

On 06.02.2024 at 21:06 Al Iverson via mailop wrote: I also observed them ejecting a company from their organization for not following their rules. I can't really go into specifics on that one. CSA actually publishes the names of the companies whose membership has recently been suspended on

Re: [mailop] Microsoft Outbound Spam Seemingly Has Morphed

On 05.02.2024 at 13:55 L. Mark Stone via mailop wrote > Overnight in our logs, we are starting to see Microsoft spam like this: > Feb 5 12:19:28 my postfix/smtpd[1015436]: NOQUEUE: filter: RCPT from > mail-mw2nam10acsn2106.outbound.protection.outlook.com[104.47.55.106]: > : Sender address

Re: [mailop] Support contact for Shaw.ca

On 02.02.2024 at 01:52 Hugh E Cruickshank via mailop wrote > We are experiencing a problem with mail delivery to Shaw.ca. Since January > 18th messages have been bounced with: 552 5.2.0 Message contains bare CR and > is violating 822.bis section 2.3. We have tried to contact postmas...@shaw.ca

Re: [mailop] DKIM signed with parent domain

> On 27.01.2024 at 03:23 Grant Taylor via mailop wrote: > On 1/26/24 16:06, Gellner, Oliver via mailop wrote: >> Independent of this I wouldn’t use r...@hostname.example.org as a sender >> address to external recipients. This doesn’t look professional, > > I'll agre

Re: [mailop] DKIM signed with parent domain

> On 25.01.2024 at 16:29 Marco Moock via mailop wrote: > > At work we are currently deploying DKIM. > > Do people here have experience with messages from sub.example.org > signed with d=example.org? > That way is much easier to handle for us because we have a lot of > domains (machines sending

Re: [mailop] Contact Google Postmaster

> On 26.01.2024 at 19:36 Scott Mutter via mailop wrote: > > It seems messages being sent from 173.225.104.91 are being delivered into > Gmail user's spam boxes. Is each and every message from different organizational domains sent by this server placed into the spam folder? Or does it affect

Re: [mailop] Spamhaus contact?

> On 16.01.2024 at 22:16 Atro Tossavainen via mailop wrote: > >  >>> https://www.talosintelligence.com/reputation_center/lookup?search=66.175.222.108 >> Thanks for this; I wasn't familiar with Talos Intelligence. Do they publish >> a blocklist? > > Paying users only. Paying users include the

Re: [mailop] Spamhaus contact?

On 16.01.2024 at 17:25 Mark Fletcher via mailop wrote:  On Mon, Jan 15, 2024 at 4:19 PM Randolf Richardson, Postmaster via mailop mailto:mailop@mailop.org>> wrote: You'll likely be interested in the reputation score, which is presently showing as "Poor" for that IP address

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

On 10.01.2024 at 21:59 Randolf Richardson, Postmaster via mailop wrote: > What's missing from BIMI in its current form? The option for mail server > oparators to use the same TLS certificates that we're already using for our > mail servers (and web servers, and FTP servers, etc.). A server

Re: [mailop] BIMI boycott?

On 11.01.2024 at 17:18 Ángel via mailop wrote: > On 2024-01-10 at 20:38 +, Gellner, Oliver wrote: >> Either way, BIMI is not suitable for reader tracking as you cannot >> provide different logo URIs for each recipient. > Sorry, but it would be possible: >> Domain Owners can specify which

Re: [mailop] BIMI boycott?

> On 10.01.2024 at 17:21 Olga Fischer via mailop wrote: > > Many bigger mailers are blogging about BIMI. > As far as I see its exclusively for brands. > It has 2 big barriers for entry: > - Expensive bespoke cert oids > - Registered trademark logos > > As from my perspective of independent

Re: [mailop] SMTP smuggling

On 03.01.2024 at 23:15 Brandon Long wrote:  Hmm, doesn't this also depend on improper handling of pipelining? You can't pipeline past DATA, https://datatracker.ietf.org/doc/html/rfc2920#section-3.1 I guess if the sender is sending line by line, maybe the server would only have up to the

Re: [mailop] Any evidence of SMTP smuggling in the wild - yet?

On 01.01.2024 at 20:38 Marco Moock wrote: Am 01.01.2024 um 17:58:47 Uhr schrieb Gellner, Oliver via mailop: To exploit the issue, an email message needs to traverse two MTAs that treat the EOM marker differently. The MTAs do not need to be in a special trust relationship or allowed to relay

Re: [mailop] Any evidence of SMTP smuggling in the wild - yet?

> On 28.12.2023 at 20:29 Marco Moock via mailop wrote: > > Am 28.12.2023 um 18:15:39 Uhr schrieb Tom Perrine via mailop: > >> Has anyone detected or seen any evidence of SMTP smuggling in the >> wild? >> >> I’m trying to get an independent read on how quickly the bad actors >> have (or haven’t)

Re: [mailop] ECDSA DKIM validation?

> Am 21.12.2023 um 13:28 schrieb Andrew C Aitchison via mailop > : > > On Thu, 21 Dec 2023, John R Levine via mailop wrote: >> I'm sure that Google has code somewhere that can validate ED25519 >> signatures. But that does not mean that it would be a good idea for them to >> use that code in

Re: [mailop] DKIM validity period

Am 21.12.2023 um 12:44 schrieb Slavko via mailop : Dňa 20. 12. o 22:38 Gellner, Oliver via mailop napísal(a): I’m not 100% sure what you mean by „signed forever“, but to change the topic of this thread once more (and still stay on topic for this mailing list): While the DKIM signature

Re: [mailop] DKIM validity period

> On 18.12.2023 at 19:06 Slavko via mailop wrote: > >> Why should everyone else be forced to do that? > > IMO for tracking purpose... Either, for good reason -- to track DKIM's domain > reputation, or other reason, as signed user@domain is more reliable source > than random user@domain (and

Re: [mailop] SMTP smuggling

On 19.12.2023 at 13:31 Mark Alley via mailop wrote: > Hey all, recently saw this mail server SMTP vulnerability that popped up on a > blog yesterday. Sharing here for those interested. > https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/ Thanks for sharing,

Re: [mailop] ECDSA DKIM validation?

> On 19.12.2023 at 12:19 Alessandro Vesely via mailop wrote: > > On Tue 19/Dec/2023 09:21:55 +0100 Taavi Eomäe 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. > > > Won't any Google insider

Re: [mailop] 451-Reject due to policy restrictions from web.de and gmx.de

On 17.12.2023 at 21:48 Michael Peddemors via mailop wrote: > On 2023-12-13 16:08, Randolf Richardson, Postmaster via mailop wrote: >> We're not seeing that error in our mail server logs here in Canada. >> >> The trend seems to be that mail servers worldwide have gradually >> been adding

Re: [mailop] dnsbl.spam.fail

> On 11.12.2023 at 12:11 Kirill Miazine via mailop wrote: > > Also, Domeneshop confirmed they operate spam.fail as internal list and > that they indeed have blacklisted Hetzner ranges because "lack of abuse > handling": > > > The IP belongs to Hetzner which have a full lack of abuse handling. >

Re: [mailop] Outlook.com losing eMail messages and SNDS reporting failures

On 2.12.2023 at 05:37 Randolf Richardson, Postmaster via mailop wrote: > Some of my users have been reporting that eMail messages are getting lost > intermittently when they're sent to users at any internet domain name that > relies on OUTLOOK.COM for its MX. > Our mail server logs confirm that

Re: [mailop] Email deliverability issues to Outlook

On 1.12.2023 at 06:49 Grant Gordon via mailop wrote: > with exactly the same problem at the moment, we thought we were the only ones. > Started noticing it last week Monday as user complaints began rolling > in.We're a rather small hosting company and it took us quite a while to > narrow down

[mailop] Vodafone contact

Hello, if someone from Vodafone Germany is on this list or someone knows how to get in contact with them, I'd appreciate a hint. Some order confirmations are rejected as spam (which they are not) and the postmaster addresses do not answer. -- BR Oliver dmTECH

Re: [mailop] Reaching out to GMAIL

On 21.11.2023 at 13:26 Yiorgos [George] Adamopoulos via mailop wrote: > On Tue, Nov 21, 2023 at 1:57 PM Ralf Hildebrandt via mailop > wrote: >> 421-4.7.28 Gmail has detected an unusual rate of unsolicited mail. To >> protect >> 421-4.7.28 our users from spam, mail has been temporarily rate >>

Re: [mailop] Reaching out to GMAIL

On 21.11.2023 at 12:44 Ralf Hildebrandt via mailop wrote: > We're running the postfix-users ML on list.sys4.de, and all over a sudden > we're being tempfailed by GMAIL: > 421-4.7.28 Gmail has detected an unusual rate of unsolicited mail. To protect > 421-4.7.28 our users from spam, mail has

Re: [mailop] If one signature is good, 72 signatures must be better

On 16.11.2023 at 03:05 John Levine via mailop wrote: > I just got a couple of quite remarkable messages from Sabre's Tripcase > service, confirming that they'd received some info I mailed thmm. > Below you can see the Authentication Results header my mail server added. > All 72 valid DKIM

Re: [mailop] valid DKIM-signed email spam-classified @gmail only; correct PASS @ other server recipients ?

On 29.10.2023 at 20:51 pgnd via mailop wrote: >> Is that domain the same as you post here from? I ask, because your >> email was signed only by one key and you mentioned dualsign previously. > nope. _this_ is not sent from one of my own servers. > all my mails from all my servers are dual

Re: [mailop] valid DKIM-signed email spam-classified @gmail only; correct PASS @ other server recipients ?

On 30.10.2023 at 15:25 Slavko via mailop wrote: > Dňa 30. októbra 2023 12:01:41 UTC používateľ "L. Mark Stone via mailop" > napísal: >> If you browse to https://www.rfc-editor.org/rfc/rfc8463 and scroll to the >> bottom you'll see the author's name and contact information. >> >> Things should

Re: [mailop] Outlook misinterpreting the Sender field ?

On 26.10.2023 at 16:16 David Verdin via mailop wrote: > So I'm one of the administrator of a big mailing lists server. One of our > user complained that when the subscribers to her list wrote to the list, only > she received the message. > Which is not possible, due to the very mechanisms of

Re: [mailop] New hotmail function: 'Put emails from unknown sender as Junk' causing false complaints?

On 24.10.2023 at 14:39 Benoît Panizzon via mailop wrote: > One of our customer is forwarding his emails on our platform to his hotmail > email address. > Today, we started getting a Microsoft Spam complaint for almost every email > that was being forwarded to his hotmail account. > I contacted

Re: [mailop] Success MiTM attack

> On 22.10.2023 at 15:06 Philip Paeps via mailop wrote: > > On 2023-10-22 14:34:39 (+0530), Slavko via mailop wrote: >> while not directly about email, recently was published details >> about success MiTM attack against XMPP server, the attacker >> was able to decrypt TLS communication without

Re: [mailop] outlook.com 421 try again later S77719

On 12.10.2023 at 09:00 MK via mailop wrote: > next day, same problem. > I also read the statement from Microsoft that the problem should be fixed but > I can not confirm this. > https://learn.microsoft.com/en-us/answers/questions/1388775/outlook-com-servers-tells-server-busy-please-try-a > Here

Re: [mailop] outlook.com 421 try again later S77719

On 11.10.2023 at 11:24 Andreas via mailop wrote: since a few hours we have problems with sending to Microsoft. We get hundreds of messages like in the subject with the reference to S77719. Also colleagues from other companies in germany are seeing the same in their logs. All mails that are

Re: [mailop] fastmail and sender score snafu

On 09.10.2023 at 08:24 Robert Mueller via mailop wrote: >> I see that current setup might be useful in case some user changes MX >> before the domain is activated at Fastmail, in which case giving 4xx >> could make sense. But it is not right to report such re-tries to >> sender score as attempts

Re: [mailop] DMARC report rejections - was Re: Recent increase in GMail 421-4.7.28 responses

On 06.10.2023 at 20:19 Bernardo Reino via mailop wrote: >> On Fri, 6 Oct 2023, Andrew C Aitchison via mailop wrote: >> >> I trust that you are applying RFC 7489 section 7.1. where appropriate. >> If the domain for dmarc reports is not the same as the requesting >> domain, you must check that the

Re: [mailop] Spamhaus listing question

On 04.10.2023 at 17:19 Marco M. wrote: > Am 04.10.2023 um 15:05:32 Uhr schrieb Gellner, Oliver via mailop: >> today starting at around 11:40 CET one of our IP addresses >> 194.127.216.50 was added to the Spamhaus CSS blocklist. The listing >> has since been removed, but as

[mailop] Spamhaus listing question

Hello, today starting at around 11:40 CET one of our IP addresses 194.127.216.50 was added to the Spamhaus CSS blocklist. The listing has since been removed, but as we have a closed user base and I do not believe the MTA behind this IP address suffers from any misconfigurations, I'd be really

Re: [mailop] Gmail says "Message bounced due to organizational settings."

On 27.09.2023 at 20:19 Brandon Long via mailop wrote: > On Wed, Sep 27, 2023 at 6:14 AM John R Levine via mailop > wrote: I'm doing some work for http://arxiv.org, the preprint server at Cornell university. Many gmail users have reported that when

Re: [mailop] Authentication Bounces by Gmail

On 21.09.2023 at 00:30 John Levine wrote: > It appears that Gellner, Oliver via mailop said: >>> Yes, I'm sure it does. >>> Using simple/simple canonicalization is not for people who want robust DKIM >>> signatures. >> >>The relaxed canonicalizati

Re: [mailop] Authentication Bounces by Gmail

On 20.09.2023 at 04:53 Bill Cole via mailop wrote: > Putting anything other than a single space between the header name and > content is a form of malicious compliance... >> This change breaks the original sender's c=simple/simple DKIM >> signature. > Yes, I'm sure it does. > Using

Re: [mailop] New Validity policy for paid FBL (ARF)

On 13.09.2023 at 16:06 Scott Mutter via mailop wrote: > I also think one thing that Validity may not be understanding with this move, > and may lead to shooting themselves in the foot, the list of email service > providers that Validity provides feedback for isn't exactly major players. > We

Re: [mailop] New Validity policy for paid FBL (ARF)

On 12.09.2023 at 22:30 Mark Fletcher via mailop wrote: > Thank you for writing this up, it's been confusing. We only receive > individual reports and not the aggregated data (or if we do it's not sent to > us). We received a slightly different email from Validity. It includes the > 'login

Re: [mailop] Let's play "What's wrong with this picture?" - perhaps Microsoft can take the first stab at this :)

On 08.09.2023 at 04:38 Mark Foster via mailop wrote: > Cannot in good faith, recommend Microsoft's free-tier mail services, and I > have a massive questionmark over their commercial ones as well, given this > experience. Unfortunately the commercial support gives you very odd experiences as

Re: [mailop] Legit-looking mail to the wrong address with no unsubscribe

> On 25.08.2023 at 13:29 Brotman, Alex via mailop wrote: > >  Are you suggesting that an unsub results in a suppression? That hardly > seems ideal. That seems to suggest I sign up for a brand's email list. > Order some stuff, get receipt. Later unsub. Later buy again, but get no >

Re: [mailop] hotmail.com SPF forgot IPv6

> On 21.08.2023 at 22:33 John Levine wrote: > > It appears that Gellner, Oliver via mailop said: >> >>>> SPF contains information about which IP addresses are authorized or >>>> unauthorized to send messages for a given domain. It does n

Re: [mailop] hotmail.com SPF forgot IPv6

> On 19.08.2023 at 19:01 Jarland Donnell via mailop wrote: > > Is "-all" not indeed a policy in SPF, directed by the domain owner? I would > argue that it is. Especially given that there are options there, each one > defining how the domain owner wishes SPF failure to be treated. I would find

Re: [mailop] DKIM AUID and subdomains

> On 21.08.2023 at 17:57 Slavko via mailop wrote: > > Dňa 21. augusta 2023 7:44:45 UTC používateľ Alessandro Vesely via mailop > napísal: > >> It is also possible to set: >> >> DKIM-Signature: ... d=sub.example.org > > Yes, that i used, and that is what i want to avoid -- to maintain

Re: [mailop] hotmail.com SPF forgot IPv6

> On 19.08.2023 at 12:30 Benny Pedersen via mailop wrote: > > prove it, it just loose dmarc aligment, if it was hardfails, lets not ignore > domain owners, ever > > spf softfails can still pass dkim, hopefully you know this You don’t have to ignore domain owners as they do not put any kind of

Re: [mailop] Send emails over O365 to Google with a specific domain are rejected

On 09.08.2023 at 10:05 Otto J. Makela via mailop wrote: > On 8/7/23 03:06, Al Iverson via mailop wrote: >> If MS is using IPv6 to send the mail to Google, you might be in an >> extra difficult spot. Not everybody agrees/believes this, but in my >> experience Gmail is more quick to block

Re: [mailop] Office365 STARTTLS not working anymore?

> On 18.07.2023 at 16:21 Benoit Panizzon wrote: > >> As far as I know Microsoft never officially supported or advertised STARTTLS >> for its mail submission services. Given that RFC8314 "Use of Transport Layer >> Security for Email Submission and Access" basically deprecates STARTTLS in >>

Re: [mailop] Office365 STARTTLS not working anymore?

On 18.07.2023 at 13:07 Benoit Panizzon via mailop wrote: > My client connects to Port 143 and performs STARTTLS but is not getting > anything in reply. > > Is there a known outage? Hast Microsoft discontinued STARTTLS? As far as I know Microsoft never officially supported or advertised STARTTLS

Re: [mailop] AOL/Yahoo requiring SOA record for MAIL FROM domain name?

> On 13.07.2023 at 20:52 Robert L Mathews via mailop wrote: > > On 7/13/23 11:12 AM, Jarland Donnell via mailop wrote: >> Perhaps it's going off topic and apologies if so, but this makes me wonder a >> second thing. Who is, and why are they, adding subdomains to the PSL when >> subdomains

Re: [mailop] Guide for setting up a mail server ?

> On 13.07.2023 at 11:12 Hans-Martin Mosner via mailop wrote: > >  > Has anyone on this list tried forwarding (e.g. for ex-employees) via > attachment? The original message would be kept intact, while the outer > message clearly originates with the forwarding agent who may even add a human >

Re: [mailop] AOL/Yahoo requiring SOA record for MAIL FROM domain name?

> On 13.07.2023 at 17:55 Bill Cole via mailop wrote: > > It's not at all logically hard to meet that arbitrary requirement, you just > need a zone cut everywhere you have a MX record. I've run a DNS and mail > hosting environment that way. Zone files are very small and numerous. >

Re: [mailop] AOL/Yahoo requiring SOA record for MAIL FROM domain name?

On 13.07.2023 at 00:38 Robert L Mathews via mailop wrote: > Aside from anything else, it implies that SOA records can be easily added to > solve this, similar to how you add MX or A records. But that is usually not > the case: SOA records can exist only at a DNS zone delegation boundary, not >

Re: [mailop] greylisting, SendGrid is deleting your mail

> On 24.06.2023 at 19:38 John Levine via mailop wrote: > According to Gellner, Oliver via mailop : >> >>It matters if the greylisting takes place before or after RBL / domain >>reputation checks. If the greylisting comes first, I could imagine that the >>connections

Re: [mailop] greylisting, SendGrid is deleting your mail

> On 24.06.2023 at 06:56 John Levine via mailop wrote: > > It appears that Al Iverson via mailop said: >> What if we just got to the heart of the matter and admitted that >> greylisting is useless 2023? > > Because it's still quite useful if you do it sensibly. Here's what my > logs say for

Re: [mailop] DMARC and subdomains

> On 16.06.2023 at 16:13 Jaroslaw Rafa via mailop wrote: > > At some time I noticed that Gmail started to indicate DMARC failure. I > checked and found out that the admins of parent eu.org domain put a DMARC > record on it, which caused emails from my domain rafa.eu.org (not from the > parent

Re: [mailop] SPF: Does include: a host without TXT entry invalidate the whole SPF entry?

> On 12.06.2023 at 12:20 Andrew C Aitchison via mailop wrote: > > On Fri, 9 Jun 2023, Gellner, Oliver via mailop wrote: > >>>> Does someone use those SPF tags or has any practical experience with >> them and ever received some reports? Or do those tags only exist i

Re: [mailop] SPF: Does include: a host without TXT entry invalidate the whole SPF entry?

> On 09.06.2023 at 09:36 Alessandro Vesely via mailop wrote: > > RFC 6652 provides for setting ra= and rr= tags, which are themselves flagged > as errors by most SPF checking sites... Does someone use those SPF tags or has any practical experience with them and ever received some reports? Or

Re: [mailop] Google Toolbox broken?

On 03.06.2023 at 00:34 John Levine via mailop wrote: > If you mean the DMARC record for johnlevine.com, it's valid, but is also a > stress test for DNS and DMARC software. Looks like it caught another one. It > has a valid DNSSEC signature too, for people who care about that. > If you mean the

Re: [mailop] Google Toolbox broken?

> On 02.06.2023 at 10:22 Johan Lavsund via mailop wrote: > Hi Oliver, > > Can you try adding a ; to the end of the dns record? > On 02.06.2023 at 10:23 Taavi Eomäe via mailop wrote: > > Your DKIM TXT record seems valid, but does not specify the key type, looking > at the length it should

[mailop] Google Toolbox broken?

Hello, the Google admin toolbox claims our DKIM keys and MTA-STS entries are invalid. Example: https://toolbox.googleapps.com/apps/checkmx/check?domain=dm.de_selector=dmglobal4 reports "Invalid format of DKIM record" and "MTA STS is malformed". I cannot find out what is invalid about them,

Re: [mailop] why some ISP domains have no spf?

> On 26.05.2023 at 10:10 Ken Peng via mailop wrote: > > Why some huge ISPs do not even have SPF for their sending domains? > such as att.net and t-online.de. > I know they may let their users to send email from home DSL via (no-auth) > relay servers, but since the IPs (no matter relay server or

Re: [mailop] Yahoo: SOA record per subdomain required?!

On 09.05.2023 at 02:11 Ken Peng via mailop wrote: May 9, 2023 at 4:07 AM, "Gellner, Oliver via mailop" wrote: If a receiver only accepts emails from sender addressed domains for which MX or A records exist (such checks are performed by many receiving servers), it means a sende

Re: [mailop] United Airlines / mileageplus DNS/rDNS mismatch issue

> On 09.05.2023 at 20:46 Michael Peddemors via mailop wrote: > > But nothing wrong with sending an email from a PTR with a name, that doens't > have the FQDN forward/reverse matched. > > As long as there is a URL associated with the domain name. > > eg. http://mileageplus.com (Redirect to UA

Re: [mailop] Yahoo: SOA record per subdomain required?!

On 08.05.2023 at 20:48 Marcel Becker via mailop wrote: On Mon, May 8, 2023 at 11:13 AM Christian Seitz via mailop mailto:mailop@mailop.org>> wrote: Now it would be great to hear anything directly from Yahoo Aber natürlich! Replied off list. I would be interested as well whether a SOA record

Re: [mailop] Yahoo: SOA record per subdomain required?!

> On 07.05.2023 at 21:55 Bill Cole via mailop wrote: > > On 2023-05-07 at 15:12:54 UTC-0400 (Sun, 7 May 2023 19:12:54 +) > Gellner, Oliver via mailop > is rumored to have said: > >> While I’m not affiliated with Yahoo, I see no reason to bash them in this &

Re: [mailop] Yahoo: SOA record per subdomain required?!

> On 07.05.2023 at 18:54 Felix Fontein via mailop wrote: > > maybe this is related to in-berlin.de being on the Public Suffix List? > This might explain why Yahoo treats subdomains of in-berlin.de > differently than for subdomains of other domains (like e.mail.de > mentioned by Ken). To put it

Re: [mailop] DKIM with 3072-bit or 4096-bit RSA signatures

p Sent: Donnerstag, 27. April 2023 00:23 To: mailop@mailop.org Cc: oliver.gell...@dm.de Subject: Re: [mailop] DKIM with 3072-bit or 4096-bit RSA signatures This email has reached Mapp via an external source It appears that Gellner, Oliver via mailop said: > >> On 26.04.2023 at 04:30 John L

Re: [mailop] DKIM with 3072-bit or 4096-bit RSA signatures

> On 26.04.2023 at 04:30 John Levine via mailop wrote: > > I rotate my keys every month, and publish the old public keys on a web > site 10 days after the end of the month so anyone can fake an old > signature from me. There's a pointer to the web server in the DNS key > records. Hello John, is

Re: [mailop] No TLS reports from microsoft.com since March 29th

On 18.04.2023 at 19:18 A. Schulze via mailop wrote: Am 12.04.23 um 17:02 schrieb Paul Menzel via mailop: >> Since March 29th, 2023 we have not received any (MTA-STS) TLS reports from >> microsoft.com. > it seems it's not only TLS reporting: more then once over the last days we > received

Re: [mailop] agilitylive.com publishing empty SPF record

On 13.04.2023 at 19:37 Mark Alley via mailop wrote: > To clarify - legitimate mail getting rejected. I have not seen any malicious > messages from these IP's, this seems to be a recent change in their DNS > according to securitytrails. > On 4/13/2023 12:22 PM, Mark Alley wrote: >> Any Kofax

Re: [mailop] No TLS reports from microsoft.com since March 29th

On 12.04.2023 at 17:03 Paul Menzel via mailop wrote: > Since March 29th, 2023 we have not received any (MTA-STS) TLS reports from > microsoft.com. We still get TLS reports from google.com and SocketLabs. I can confirm that the last TLS report from Microsoft is dated 2023-03-29. I have no idea

  1   2   >