Re: [mailop] Yahoo no longer accepting email forwards?
Have you opened a ticket with Yahoo? Are you *SURE* there’s not a problem with one of the links in your message pointing to phishing / malware / etc? Remember, Yahoo sees the entire content of the message before they reject it - so if your content contains links that are infected or hosting phishing sites then you’re the problem. I’ve found that PH01 is usually accurate but if it’s not, only opening a ticket is the way to fix it. laura > On 21 May 2024, at 20:01, Mark E. Jeftovic via mailop > wrote: > > Following on my email yesterday and after running a few more tests. > > The error message from Yahoo is simply > > Remote-MTA: dns; mta6.am0.yahoodns.net > Diagnostic-Code: smtp; 554 Message not allowed > [PH01] Email not accepted for policy reasons > > which links back to > > https://senders.yahooinc.com/smtp-error-codes/ > > The PH series errors says simply "Content Based Blocks" > > These error messages indicates that your email wasn't accepted because there > is something in the content that Yahoo won't accept for policy reasons. > Objectionable content that Yahoo deems unacceptable includes: > Viruses > Phishing attempts > Ransomware > Other malicious software > Links or URLs to any of the above > > Which is not the case - especially in our tests where we're simply sending > text only messages with no links. > > The only difference between messages that get through vs ones that are > rejected (same message) is whether we send to the Yahoo email box directly, > or else via an email forward (which has SRS enabled, and optionally SPF and > even minimal DMARC) > > So it is looking like Yahoo is not accepting email forwards (at least from > us) since Friday, May 17th. > > - mark > > -- > Mark E. Jeftovic <mailto:mar...@easydns.com> > Co-founder & CEO easyDNS Technologies Inc. > +1-(416)-535-8672 ext 225 > > "Never expect a thing you do not want, > and never desire a thing you do not expect." > -- Bob Proctor > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone from t-mobile?
yes. I’ve reported there. Repeatedly. I was looking for a contact that might be able to help. Laura Sent from my iPhone > On May 6, 2024, at 4:11 PM, Marco Moock via mailop wrote: > > Am 06.05.2024 um 15:56:31 Uhr schrieb Laura Atkins: > >> 205.183.255.162 > > Have a look in the whois database (whois in terminal): > Comment:For abuse issues, please email ab...@aup.lumen.com > Comment:All abuse reports MUST include: > Comment:* src IP > Comment:* dest IP (your IP) > Comment:* dest port > Comment:* Accurate date/timestamp and timezone of activity > Comment:* Intensity/frequency (short log extracts) > Comment:* Your contact details (phone and email) > > > -- > kind regards > Marco > > Send unsolicited bulk mail to 1715003791mu...@cartoonies.org > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone from t-mobile?
> On 6 May 2024, at 13:35, Marco Moock via mailop wrote: > > Am 06.05.2024 um 12:59:46 Uhr schrieb Laura Atkins via mailop: > >> Looking for an abuse contact there or at messagereach. > > T-Mobile is a name used by many (sub)companies. > Can you specify the IP address? > sorry, was cooking dinner and missed the IP request. But, really, it’s t-mobile and they’re advertising their business connectivity, so I’m not sure IP is relevant. But this is the sending IP. 205.183.255.162 laura -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone from t-mobile?
T-Mobile for Business > On 6 May 2024, at 12:59, Laura Atkins via mailop wrote: > > Looking for an abuse contact there or at messagereach. > > laura > > -- > The Delivery Expert > > Laura Atkins > Word to the Wise > la...@wordtothewise.com > > Delivery hints and commentary: http://wordtothewise.com/blog > > > > > > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Anyone from t-mobile?
Looking for an abuse contact there or at messagereach. laura -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Sudden spike in Gmail failures ("TempFail – Spam")
> On 30 Apr 2024, at 12:44, Mendel Kucharzeck via mailop > wrote: > > Laura, > > Thanks for your reply! Highly appreciated. Inline: > >>> - Anyone else seeing this behaviour from gmail recently? >>> - Could the newly created, custom MAIL-FROM-domain cause a behaviour like >>> this? The MAIL-FROM-Domain has not yet been used before, but the sending >>> email address was the same >> >> You changed a domain that is important in authentication. That changed the >> identity of the message. That meant you were treated as a semi-new sender by >> the machine learning filters. > > I was aware that different IPs, domains or email addresses require prior > warmup – but I was not aware that the return-path/MAIL-FROM-domain also > requires a warmup. Interesting. It’s a new domain, a new identity. It’s actually one of the authenticated domains so of COURSE it’s important. There’s also, currently, a significant problem with spammers creating subdomains and hijacking reputations. Right now I’d say that filters are more than overly suspicious of new SPF domains. That’s just the current threat model they’re working with. I will note that one ESP had a huge problem with delivery across their customer base when they rolled out a new domain in the One-Click List-Unsubscribe header to comply with the new Yahoogle recommendations. ANY domain in the email can have an impact on delivery. >>> Any insights or hints on how to investigate this would be highly >>> appreciated. >> >> You may need to back off and go through a short warmup phase to introduce >> that this SPF + this DKIM + this Header From from SES shared pool is a valid >> source of mail. > > Will do this over the coming weeks. I’ll spread out my next campaign from one > hour to 5-15 days. Are you really only sending monthly? That’s going to make it tough to really establish a reputation. >> ALSO - did you actually have any delivery problems? One thing I’ve noticed >> (at Gmail in particular) is that changes in an authenticated domain often >> result in a lower rate of pre-fetching of images *without* any corresponding >> change in delivery. > > Yes. All other metrics (hits on homepage, sales, customer responses, > unsubscribes) were WAY lower than anticipated compared to previous campaigns. > It’s not a measurement thing that’s off. Fair enough. It’s worth mentioning, though. Also, have you tracked the metrics per ISP / recipient mailserver? You may discover the problem is related to one specific MX / Filter and that will help inform what to do about it. >> Before you start freaking out about things, check to see if your delivery is >> different. Pixel loads are fickle beasts and it’s worthwhile to understand >> if this is a change in display behavior (ie, it’s a new sender of email, so >> Google isn’t going to prefetch mail until it knows if this is a valid and >> wanted mail stream or if it’s someone faking your sending domain) or if it’s >> a change in delivery behavior (ie, Google dropped all the mail in the spam >> folder). >> >> If it’s simply prefetch behavior, there’s nothing you can do. Google gonna >> Google. > > I know these things are tricky. But: In the past years, we had at least > consistent results with tracking pixels. I cannot validate the absolute > numbers, but each campaign yielded roughly the same read rates (+/-10 %). I think you misunderstood my point so let me try again. I have regularly seen when something changes (domain, IP, template, etc) in an email stream that Google stops pre-fetching pixels until the machine learning filters can catch up and decide if this is wanted mail or not. This can cause a “drop” in opens without any change in actual delivery. Your experience is different and does suggest there is some change in delivery. But, if nothing else has changed that should resolve itself with a bit of warmup. laura > > Best, > Mendel > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Sudden spike in Gmail failures ("TempFail – Spam")
> On 29 Apr 2024, at 16:02, Mendel Kucharzeck via mailop > wrote: [snip] > Questions: > > - Anyone else seeing this behaviour from gmail recently? > - Could the newly created, custom MAIL-FROM-domain cause a behaviour like > this? The MAIL-FROM-Domain has not yet been used before, but the sending > email address was the same You changed a domain that is important in authentication. That changed the identity of the message. That meant you were treated as a semi-new sender by the machine learning filters. > Any insights or hints on how to investigate this would be highly appreciated. You may need to back off and go through a short warmup phase to introduce that this SPF + this DKIM + this Header From from SES shared pool is a valid source of mail. ALSO - did you actually have any delivery problems? One thing I’ve noticed (at Gmail in particular) is that changes in an authenticated domain often result in a lower rate of pre-fetching of images *without* any corresponding change in delivery. Before you start freaking out about things, check to see if your delivery is different. Pixel loads are fickle beasts and it’s worthwhile to understand if this is a change in display behavior (ie, it’s a new sender of email, so Google isn’t going to prefetch mail until it knows if this is a valid and wanted mail stream or if it’s someone faking your sending domain) or if it’s a change in delivery behavior (ie, Google dropped all the mail in the spam folder). If it’s simply prefetch behavior, there’s nothing you can do. Google gonna Google. laura -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Are there other comparable services like spamcop.net / spamhaus.org?
> On 3 Apr 2024, at 18:32, John Levine via mailop wrote: > > It appears that Aban Dokht via mailop said: >> Hi list, >> >> are there other comparable services like spamcop.net or spamhaus.org worth >> submitting SPAM samples to? > > By the way, how do you think you're submitting stuff to spamhaus? > > They do not accept third party samples and never have. They are now. https://submit.spamhaus.org/ laura -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [EXTERNAL] Re: is warming IPs still necessary?
> 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 -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Debt Collection Client Email Servers
AWS has good IP reputation - I’ve got one client sending <500K a month and one sending >20M a day off AWS and their IP rep at google is all in the green. Mailgun/Sinch are one a lot of my clients are moving to, as well. There’s also whatever-they’re-called-now-but-used-to-be-Sparkpost. I’m really unsure that email is a good way to do this kind of contact, though. It’s too easy for the actual recipients (whether they’re the actual debtor or not) to affect your reputation. laura > On 25 Mar 2024, at 21:52, Michael Irvine via mailop wrote: > > Thank you everyone. Is there any recommendation on other 3rd party senders > that can be trusted instead of SendGrid. My last resort will be to setup some > MTA's with the few free IP they have from the Datacenter. > > I also understand that the client is in the middle of a catch-22 in terms of > sending email. I have already informed them that email will always be a best > effort and not a guarantee. > > As for contacts other than email. Email is the last resort after all other > avenues are attempted in the order of Snail Mail, Phone, SMS, and Social > Media. > > Thanks, > > Michael Irvine > > -Original Message- > From: mailop On Behalf Of Jay Hennigan via mailop > Sent: Monday, March 25, 2024 1:37 PM > To: mailop@mailop.org > Subject: Re: [mailop] Debt Collection Client Email Servers > > CAUTION: This email originated from outside of the organization. Do not click > any links or open attachments unless you recognize the sender and know the > content is safe. > > > > On 3/22/24 14:58, Michael Peddemors via mailop wrote: >> If they are 'dedicated', doesn't matter if they are coming from >> SendGrid, the PTR should reflect your clients domain. >> >> host 149.72.234.90 >> 90.234.72.149.in-addr.arpa domain name pointer >> wrqvzxrx.outbound-mail.sendgrid.net. > > If Sendgrid claimed that these IPs are dedicated to you, their PTR says > otherwise. It should reflect your sending domain. Note that Sendgrid has a > rather poor reputation when it comes to spam exiting their network. > >> And given the amount of abuse of SendGrid servers, anything you can do >> to differentiate from their generic naming conventions will help you. > > Or avoid Sendgrid entirely. > > -- > Jay Hennigan - j...@west.net > Network Engineering - CCIE #7880 > 503 897-8550 - WB6RDV > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] is warming IPs still necessary?
> On 25 Mar 2024, at 22:58, Gerald Oskoboiny via mailop > wrote: > > We are planning to move the system that hosts our email discussion lists from > its old home where it has been for decades to an EC2 instance on AWS. It does > about 15k deliveries per day, most of which go to gmail or google-hosted > email systems. Don’t use EC2 for mail. Use SES. > Is it still necessary to warm up new IP addresses gradually instead of going > directly to this volume of deliveries? My impression is that it's less and > less necessary in the age of DMARC, SPF and DKIM. It’s more necessary - you need to warm up both your IP and your domain AND the combination of IP and domain addresses. > Nothing else would be changing from the recipient's point of view aside from > the IP address (and network): the domain, return-paths, dkim keys and > selectors involved would all be the same as they have been. > > The new IP address doesn't seem to be on many public RBLs, and I have > contacted Microsoft to have it removed from their block list. Doesn’t matter. It’s a new IP - therefore it starts with a mildly negative reputation. > Do many current sites require an IP's reputation to be established gradually? > (particularly Google) Would it just greylist deliveries for a few hours, or > fail worse than that? > > The new host will be doing deliveries directly, not using SES. That is, IMO, a very poor choice. laura -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
> On 12 Feb 2024, at 14:33, Sebastian Nielsen via mailop > wrote: > > >>Do they also allow you to search for the original sender? > No not via sender search, as the encapsulated email is part of the BODY of > the container email. > So usually you have to search via body search. So you are still changing the fundamental way email works. > > >>And, again, what is the overall benefit to the end user from this scheme? > Benefit is that email can be verified in a more streamlined way, which > minimizes phishing and spam, if no servers are authorized to use any other’s > email address, even if forwarding an email. > It benefits users in the long run, as less and less people will be scammed by > bank phishing and similar schemes, making email a more secure communication > medium, by using already established systems like SPF, DMARC and DKIM to > verify email’s legitimacy. Is this actually the case, though? I’ve heard a lot of folks claim that, somehow, SPF, DMARC and DKIM verify an email’s legitimacy. But we’ve seen how bad actors are currently sending malicious mail that pass SPF and DMARC or DKIM and DMARC. I mean, someone created a PayPal account and sent PayPal phish that passed DMARC. Other folks have used SPF escalation attacks to send DMARC passing phishing mail. These attacks are happening so how does breaking forwarding help the end user? What is to stop the bad actors from setting up systems where they are simply forwarders who create a fake email with SPF / DKIM and DMARC and then encapsulate it and forward it on to the end user? Additionally, most actual research shows that trust indicators simply don’t work for end users. I’ve seen studies related to email trust / brand indicators in the inbox not changing user behavior and there are lots of studies that show that’s the case with the web and the lock or the green bar or whatever type of SSL there is. So we have a situation where a) trust indicators can’t be trusted because they are already being exploited by bad actors to send SPF / DKIM / DMARC passing email and b) wrapping up an email and forwarding it through an untrusted source means authentication can be trivially forged, and c) trust indicators don’t actually work. In the face of those facts, what value does this bring to email? laura -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
> On 12 Feb 2024, at 13:44, Sebastian Nielsen via mailop > wrote: > > >> it basically makes it impossible to respond to the original email sender > Nope, you just open the encapsulated email (open the .EML attachment), and > respond to that. > > Some mail clients show the encapsulated email in a “frame” which has its own > reply buttons. Do they also allow you to search for the original sender? Or is this another way we’re hiding the sender of a message (much like rewriting mailing lists do)? And, again, what is the overall benefit to the end user from this scheme? laura -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
The problem with encapsulating like that is it basically makes it impossible to respond to the original email sender. It destroys functionality that has been around since the early stages of email. If we’re going to break email for people, then we should at least give them some good reason to break it. So what is the tangible win here? laura > On 12 Feb 2024, at 11:15, Sebastian Nielsen via mailop > wrote: > >>> Many antispam filters will right away classify such an email as spam. > > No, that’s not true, UNLESS the antispam filter resides as a local software > in the client's software as a plugin to the email client, which would of > course detect the "attached file" even its not technically an attached file. > > Remember that it’s the end user client who renders the encapsulated email as > an attachment. > Technically it is not an attachment, and will not get detected as an > attachment in mail filters. > Its technically an email encapsulated in an outer email. > NDR also is technically the original email encapsulated in an outer email. > > Technically, an encapsulated email looks like this: > > From: exam...@example.org > To: exam...@example.com > Subject: Fwd: Hi! > Content-Type: message/rfc822 > > From: exam...@example.org > To: exam...@example.com > Subject: Hi! > Content-Type: text/plain > > Content text. > > Spam filters react on 'Content-Disposition: attachment; filename="test.txt"' > and similar things. > >>> Conceptually, it's more like a HTTP proxy server. > > No, because in the proxy case, it’s the "sender" who asks the proxy server to > "fetch" something from "receiver"s location. It’s the opposite way, the > "sender" trust the proxy, and know that the "content" is genuine if he trust > the proxy, thus the proxy bears no responsibility for the content from a > location he asked the proxy to fetch content from. > > However, if an end user SENDS something via the proxy, let's say a forum > post, the proxy usually bears the responsibility for the content, which we > have seen in numerous court cases where a proxy have been used to hide the > origin of illegal content, where the proxy owner have knowlingly been a > forwarder of such a content (eg, been negligent and refusing to for example > block forum posts from his proxy). > > -- > You could see it more like a reverse proxy. > > A reverse proxy is a proxy, which is configured to show a domain (let's say > example.org) and show another web page (let's say letsencrypt.org) inside. > The reverse proxy of course bears ALL responsibility for the content its > "hosting" via its proxy function, meaning if letsencrypt.org would > accidentially host something illegal, the proxy owner will take the blow for > the content visible via "his website". > > Best regards, Sebastian Nielsen > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamfolder mini rant (Was: Contact Google Postmaster)
> On 30 Jan 2024, at 01:20, Randolf Richardson, Postmaster via mailop > wrote: > >>> On 28 Jan 2024, at 20:23, Thomas Walter via mailop >>> wrote: >>> >>> >>> >>> On 28.01.24 20:02, Jaroslaw Rafa via mailop wrote: >>>> There are "edge cases" when the mail couldn't be reliably classified as >>>> spam >>>> or non-spam. Even with best tuned spam filtering systems false positives >>>> will happen. >>> >>> So why not just deliver these to the Inbox then - and add a tag/label >>> instead if you have to? >> >> A very experienced spam filter person, who worked at a not-for-profit spam >> filtering company and two of the major mailbox providers once told me that >> the biggest challenge with their job was that there were messages that some >> recipients were SURE were spam and messages that some recipients absolutely >> wanted. Those were the hardest messages to decide what to do with. They >> couldn´t block them because some recipients would be mad and they couldn´t >> deliver them because other recipients would be mad. > > It's a catch-22 that becomes a more common challenge as the number > of users increases. Ultimately, the spam problem has many human > factors to it, so a purely-technical solution will be imperfect. Exactly. >>> In 95% of the cases, I can just identify the bad emails by subject. A quick >>> press on DEL and it's gone. >>> >>> I don't see any advantage of a Spam folder if I have to regularly check it >>> anyway. In fact it can even be more difficult to identify a false positive >>> between the Junk that collected in there. >> >> Some mail clients allow you to turn off the spam folder option and get every >> mail, spam or not, in your inbox. That may be a solution for you. I know >> mail.app will also tag it in a different color, so you can visually see what >> mail.app thinks is spam in you rinbox. > > SpamAssassin tagging can also continue as-is because it's just in an > SMTP header. Ditto for other solutions that add SMTP headers. And you can configure Apple mail to respect those headers. We run a very unique and special setup for Reasons (tm) that doesn’t involve any SMTP based filtering. > >>> Plus there are still customers that use POP3 for different reasons >>> (connectors that collect mails for internal Exchange systems for example). >>> Those never get to see the content of a spam folder. >> >> Google heavily discourages POP, to the extent it throws up security warnings >> if you try and enable it. They´re pretty clear they don´t want their >> customers using it, so why would they go out of their way to suppor tht >> usage? > [sNip] > > Interestingly, Google's GMail allows access to external eMail > accounts via POP3. There's no IMAP4 support there. It's as if they > want only the rest of the world to keep supporting POP3. Anything to keep the user in an environment google controls. laura -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [EXTERNAL] Re: Spamfolder mini rant (Was: Contact Google Postmaster)
> On 29 Jan 2024, at 18:02, Todd Herr via mailop wrote: > > On Mon, Jan 29, 2024 at 12:24 PM Scott Mutter via mailop <mailto:mailop@mailop.org>> wrote: >> On Mon, Jan 29, 2024 at 10:01 AM Todd Herr via mailop > <mailto:mailop@mailop.org>> wrote: >>> Users can only click "This is spam" on messages that end up in their inbox. >>> If all of your traffic went to the spam folder, perhaps because it was >>> unfortunately remarkably similar to previous traffic that was deemed spam, >>> you won't get any complaints through an FBL, because the "This is spam" >>> button isn't available when viewing the Spam folder. >>> >> There have been topics on this list as to what actually qualifies an FBL >> trigger. Is it when a user flags the message as spam? Or is it when the >> receiving server's MTA delivers the message into the recipient's spambox? >> As far as I know, there's never been a consensus on that. Some providers >> may do it one way, other providers may do it another. >> > > I am not familiar with any FBLs that are not complaint-driven, but I'll allow > that such things might exist, and if anyone's got pointers to them, please > share. All the ones I'm aware of are ones that basically follow the gameplan > laid out in RFC 6449. I’ve been informed by one provider that they trigger an ARF report when they see mail move into the spam folder on an IMAP server. So if the built in MUA filters move the mail (say, Apple Mail or the spam filters built into outlook) then that will trigger a report. Other mailbox providers have specifically said they don’t monitor IMAP movement. > There are mailbox providers out there that provide insight into what > percentage of mail from a given source was classified as spam, such as > Microsoft's SNDS program and Google's Postmaster Tools, but I've never > understood those to be feedback loops, per se, as they didn't and don't tell > you which specific messages were judged to be spam by a recipient or other > entity. It’s been a while since I’ve looked at SNDS, but I don’t believe they provide a complaint percentage. What I remember is they provide a % of mail going to spamtraps. Microsoft does provide an ARF feed for mail to their consumer domains. laura -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamfolder mini rant (Was: Contact Google Postmaster)
> On 28 Jan 2024, at 20:23, Thomas Walter via mailop wrote: > > > > On 28.01.24 20:02, Jaroslaw Rafa via mailop wrote: >> There are "edge cases" when the mail couldn't be reliably classified as spam >> or non-spam. Even with best tuned spam filtering systems false positives >> will happen. > > So why not just deliver these to the Inbox then - and add a tag/label instead > if you have to? A very experienced spam filter person, who worked at a not-for-profit spam filtering company and two of the major mailbox providers once told me that the biggest challenge with their job was that there were messages that some recipients were SURE were spam and messages that some recipients absolutely wanted. Those were the hardest messages to decide what to do with. They couldn’t block them because some recipients would be mad and they couldn’t deliver them because other recipients would be mad. > In 95% of the cases, I can just identify the bad emails by subject. A quick > press on DEL and it's gone. > > I don't see any advantage of a Spam folder if I have to regularly check it > anyway. In fact it can even be more difficult to identify a false positive > between the Junk that collected in there. Some mail clients allow you to turn off the spam folder option and get every mail, spam or not, in your inbox. That may be a solution for you. I know mail.app will also tag it in a different color, so you can visually see what mail.app thinks is spam in you rinbox. > Plus there are still customers that use POP3 for different reasons > (connectors that collect mails for internal Exchange systems for example). > Those never get to see the content of a spam folder. Google heavily discourages POP, to the extent it throws up security warnings if you try and enable it. They’re pretty clear they don’t want their customers using it, so why would they go out of their way to suppor tht usage? > >> Just having a binary distinction - reject or deliver to inbox - would be a >> much bigger obstacle to communication than delivering to spam folder, >> because it's still easier to reach the recipient in some different way and >> tell them to check the spam folder, than to make the recipient's provider >> fine-tune their email filtering to exempt you from rejection. > > It should be just as easy to contact the recipient and tell him his provider > is blocking the email - and for the recipient itself to lift the block in > some way instead of having to convince the provider. I totally agree with you. It is a regular part of my followup process for some business messages when I’m unsure if my response was delivered. A lot of my customers are senders with poor enough domain reputation that if I leave their domain name in my replies their provider puts it in the spam folder. I do go find another way to contact them, be that through their website or LinkedIn or another non-email channel. >> Of course, the users should be aware that they *should* check the spam >> folder, which means, the provider should inform them about this with a very >> clear and prominently visible message. Sadly, most providers don't do it, >> therefore the users are convinced that they don't need to check the spam >> folder at all, since it's clearly labelled "spam" or "junk", so "by >> definition" it cannot contain anything useful to them. > > We've done this in the past and sent out daily mails with a list of subjects > that got sorted as Spam. After a week or so nobody read that email anymore. > > And after we had some issues with important documents and deadlines that got > missed, because nobody checked their Spam folder, we just leave them in the > Inbox. > > Yes, I do see my share of Spam this way, but I also do see the Spam if I have > to check the Spam folder regularly… Different audiences have different needs. Not all providers are going to meet the needs of all senders and all recipients. IDIC. laura -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Contact Google Postmaster
> On 26 Jan 2024, at 23:21, Scott Mutter via mailop wrote: > > I've had domains listed in Google Postmaster Tools since 2016. Never gotten > one lick of any information from any of those except for "No data to display > at this time. Please come back later. Postmaster Tools requires that your > domain satisfies certain conditions before data is visible for this chart." > > I eventually stopped adding domains because it didn't do me any good. > > The 173.225.104.91 server has sent 68 emails to gmail.com <http://gmail.com/> > email addresses thus far in January 2024. As far as I know, this block just > happened today. Today was the first time it was brought to my attention that > messages from this server are going into the spam folder. > > Again, how am I supposed to know that Google is treating this IP's reputation > poorly? > > How am I supposed to remedy a low reputation? > > > I set up another domain on the same 173.225.104.91 server, SPF, DKIM, and > DMARC all set up (and verified with https://www.learndmarc.com > <https://www.learndmarc.com/>). Sent a message to an @gmail.com > <http://gmail.com/> address through this account, and it went to the spam > folder. > > Set up the same domain on another server - 205.209.102.251 - which, > coincidentally is also an Interserver IP. Again, verified that SPF, DKIM, > and DMARC were all set up with https://www.learndmarc.com > <https://www.learndmarc.com/>. I sent the same test message to the same > @gmail.com <http://gmail.com/> address. Message came through in the INBOX > without incident. > > What conclusions would everybody else draw? That spam filtering is fickle and deliverability troubleshooting is about statistics and machine learning. It’s near impossible to troubleshoot delivery failures at this volume. It may or may not be a reputation issue. It might be a link you’re using, it might be the domain is too new, it might be any of a dozen different things. > It's frustrating because none of the too big to fail email service providers > have any way to test a sending IP or sending domain's reputation with their > service. They block them or weigh them heavily without any method of > remediation. There is remediation available. What there isn’t is some imprimatur that ensures that every email is delivered to the inbox every time unless the sender considers it spam and agrees with the decision. That’s just not how it works. > It would be nice if I could check the reputation of my outbound IPs daily and > be proactive in remedying any issues with these major email service > providers, rather than have to be told by my clients that something is amiss. > And then battle through a 2 week waiting period for the provider to reply > back or hope that someone from the provider is on MailOps and can provide any > insight. You’re blaming the IP but Google filtering isn’t that determinative. laura -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is Google jumping the gun for SPF / DKIM requirement?
> On 25 Jan 2024, at 07:57, Thomas Walter via mailop wrote: > > Moin, > > On 25.01.24 04:48, Grant Taylor via mailop wrote: >> I knew that Google was going to start requiring SPF or DKIM (in addition to >> other sender guidelines [1]. But I thought they were starting February 1st, >> per their own sender guidelines. > > Just to clarify, because some of our customers were irritated by marketing > emails from newsletter services. > > It's SPF or DKIM for < 5000 emails per day, but > it's SPF AND DKIM AND DMARC for >=5000 emails per day. > > That said: Does anyone know if Google identifies "senders" by From:-Domain or > IP? Most of the new regs include alignment so I’m expecting this is a domain based “sender” calculation. Google has never been IP reputation heavy anyway and have generally focused on domain reputation and ensuring domain alignment. laura -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] ECDSA DKIM validation?
> On 21 Dec 2023, at 17:13, John R Levine via mailop wrote: > > On Thu, 21 Dec 2023, Mike Hillyer wrote: >> John Said: >> >>> 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 production today and try to update their reputation >>> systems to deal with the dual signing that implies. >> >> With the number of messages already arriving with multiple DKIM signatures I >> can't imagine their reputation systems don't already handle dual signing >> just fine. Granted this would be two signatures on the same domain, but that >> seems that a small change from handling a signature on the From plus one >> from the ESP and maybe even one for the list-unsubscribe domain. > > If there's two signatures for the same domain, one is good and one is bad, > which do you believe? I know what the spec says, but we have no practical > experience. For a while we were checking DKIM with 2 different parsers. There were keys that passed in one parser and not the other. It was consistent across signing - so all microsoft signatures failed with parser 1 and passed with parser 2. But there were other signatures that passed with parser 1 and failed with parser 2. Point is, I have orthogonal experience to the one you’re positing: same signature, 2 different results using two different parsers. I believed the one that passed (ie, I believed it was validly signed by the responsible domain). Laura > In any event, as I've said at least three times now, RSA keys are fine for > the forseeable future so there is no benefit to using ED25519 keys unless > there is an unexpected key break. -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Convincing clients of the importance of eMail recipient consent for mailing list subscriptions
> On 27 Nov 2023, at 20:09, Greg Brooks via mailop wrote: > > Maybe it's just like this in my world but: Everyone understands money. > > Can you make a compelling case about the hard-dollar expenses and time that > bungled IP rep and/or impacted deliverability costs? Or the math behind high > deliverability to an engaged, opt-in list vs. iffy deliverability to a > firehose list? > > Mind you, the math might not be compelling -- it's possible that there really > is higher ROI in that firehose list, or that management is utterly unwilling > to consider the sunk costs of I.T. time. But if it were my issue? Money math > is how I'd try to tackle it. I’ve been trying for 20 years to make the money work better for COI. The challenge is that all too many companies are wildly successful and make tons of money without COI. I’ve even had big clients (tens of millions of emails a day) tell me that their executive team would not even consider COI - too much friction for their users. Now, it wasn’t just marketing - these were emails related to activity on line. Now, I do try and “sneak” COI in and create tiers of subscribers and such. But, if it were actually more profitable I think you’d discover more companies would be doing it. Coming at it from a money approach… if you’re actually honest about the costs - even when you add in the ‘hidden’ IT costs and the costs of recovering from a significant deliverability problem the numbers don’t support COI. I know this is wildly unpopular - which I why I tend to stay out of these discussions. But my experience is that if you are even slightly honest about the numbers then COI doesn’t work for most companies. Hell, even if you are dishonest and make the costs of deliverability problems higher than they are it can still be challenging to make COI look more profitable. I really wish this weren’t true and I’ve been trying to make it true for years. But, sometimes reality bites. laura > > Greg > > --- > Greg Brooks > Better Cities Project > > > > On 2023-11-27 11:04, Randolf Richardson, Postmaster via mailop wrote: >>> Am 27.11.2023 um 10:42:58 Uhr schrieb Randolf Richardson, Postmaster >>> via mailop: >>> > Many marketing people seem to be terrified of the idea of >>> > users having to confirm their consent when subscribing to a mailing >>> > list (e.g., by following a unique link in an eMail message to >>> > complete the process). The marketers almost always say "it will be >>> > too complicated for the average user," and want to eliminate the >>> > confirmation step altogether (which is not an ethical approach from >>> > my perspective). >>> Tell them that not doing opt-in will make them spammers and that the >>> servers of your company will be listed in blacklists, so you cannot >>> reach anybody until that listing is expired. >> We already do this, and we refuse to host any eMail lists that are >> not confirming consent properly because of the ethics considerations, >> and for the very reason that you just covered. >>> Without a confirmation, everybody can simply subscribe any address and >>> that will be abused. >> I agree. What I'm trying to do is convince non-technical management >> to side with taking care to respect consent instead of siding with >> the marketing people who obviously don't care. In a way, this is a >> struggle between technical people who care about consent vs. >> marketing people who just want to advertise and use damage-control >> methods to clean up the mess (the marketers also seem to refuse to >> care about the ethics or the blacklists, and have the attitude that >> everyone's replaceable as long as they get what they want). >>> Even the confirmation messages can already be used for mass mailing if >>> an abuser submits the form many times for many addresses. >> Yes. There are ways to mitigate at least some of that, but these >> techniques are beyond the scope of what I'm asking for -- I'm trying >> to find ways to persuade management that the technical measures are >> necessary and must take precedence over what the marketers want. >> (Thanks for your prompt reply.) >> Postmaster - postmas...@inter-corporate.com >> Randolf Richardson - rand...@inter-corporate.com >> Inter-Corporate Computer & Network Services, Inc. >> Vancouver, British Columbia, Canada >> https://www.inter-corporate.com/ >> ___ >> mailop mailing list >> mailop@mailop.org >> https://list.mailop.org/listinfo/mailop > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] How to report abuse to cloudflare? Only via Web-Form?!? Phishing sites not against cloudflare policy!?!
On 16 Nov 2023, at 19:57, Jay Hennigan via mailop wrote: > > On 11/16/23 02:54, Laura Atkins via mailop wrote: >> The New York Times >> Laura > > Can you be more specific? Link to an article? https://letmegooglethat.com/?q=cloudflare+doxx https://letmegooglethat.com/?q=cloudflare+new+york+times https://letmegooglethat.com/?q=cloudflare+csam+new+york+times And, well, if those reports are too old for you: https://www.streamingmediablog.com/2021/11/piracy-traffic-on-cloudflare.html https://corsearch.com/about/press-releases/cloudflare-provides-services-to-a-high-proportion-of-websites-dedicated-to-piracy-and-counterfeiting/ Cloudflare is not on the side of good here and never have been. laura -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Email Bounces
Did you follow the links and do what they told you to do? How long have you waited for a response?LauraSent from my iPhoneOn Nov 16, 2023, at 11:35 AM, Polath, Kiran via mailop wrote:
Hello Team,
We at Broadridge Financial Solutions sends millions of email as financial customer communication on behalf of our clients .We see
our emails are frequently getting blocked by charter.net
& rr.com, this is impacting our reputation . Can you take it as high priority and remediate this as it is very important to our customers to have this resolved. please find the below reasons
550 5.1.0
...@... sender rejected. Please see
https://www.spectrum.net/support/internet/{hash}-{hash} for more information. AUP#In-1310
rest
2023-11-15 02:52:11 EST
charter.net
550 5.1.0
...@... sender rejected. Please see
https://www.spectrum.net/support/internet/{hash}-{hash} for more information. AUP#In-1310
rest
2023-11-15 02:52:11 EST
wi.rr.com
550 5.1.0
...@... sender rejected. Please see
https://www.spectrum.net/support/internet/{hash}-{hash} for more information. AUP#In-1310
rest
2023-11-15 02:52:11 EST
charter.net
550 5.1.0
...@... sender rejected. Please see
https://www.spectrum.net/support/internet/{hash}-{hash} for more information. AUP#In-1310
rest
2023-11-15 02:52:10 EST
wi.rr.com
550 5.1.0
...@... sender rejected. Please see
https://www.spectrum.net/support/internet/{hash}-{hash} for more information. AUP#In-1310
rest
2023-11-15 02:52:10 EST
wi.rr.com
Regards,
Kiran Kumar Polath |
ICS-Email Operations
| Broadridge Financial Solutions (India) Private Limited
Adjacent to Cyber Towers, Hi-Tech City, Madhapur | Hyderabad 500081 Telangana | India | m +91 8008297767| m +91 9154044691
broadridge.com
This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
___mailop mailing listmailop@mailop.orghttps://list.mailop.org/listinfo/mailop___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: [mailop] How to report abuse to cloudflare? Only via Web-Form?!? Phishing sites not against cloudflare policy!?!
The New York Times Laura Sent from my iPhone > On Nov 16, 2023, at 10:19 AM, Marco wrote: > > Am 16.11.2023 schrieb Laura Atkins via mailop : > >> They protect a whole lot worse than phishing sites and have doxxed >> people who complain about abuse. > > Is there a source for the latter? ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] How to report abuse to cloudflare? Only via Web-Form?!? Phishing sites not against cloudflare policy!?!
> On 16 Nov 2023, at 08:49, Benoit Panizzon via mailop > wrote: > > Hi > >> If you want any real action from Cloudflare, you have to jump through the >> hoop of filling in the web based abuse form. It sucks but only you can >> decide whether it's worth your time and effort. > > Yes, but what I don't get is, why on their first reply, they confirm > opening a case but then never send any update that they are not > working on it, until you ask about the status. Cloudflare does not concern itself with abuse. It does not host any websites, it only proxies back to the web host. They are not responsible for the content and they are unable to disconnect customers. I can’t imagine anyone who has been paying attention to expect cloudflare to take action against any abusive content. It’s not in their nature, and never has been. They protect a whole lot worse than phishing sites and have doxxed people who complain about abuse. laura -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SpamHaus FPs on 10/16 ?
Hi, Giovanni, The problem is the domain you’re sending to is using an open resolver, not that your sending IP is on spamhaus. That is explained in the link that was returned in the message. You need to contact the recipients and tell them they need to get their admins to fix it. At this point, though, those systems have not been receiving mail for months so it’s unlikely they’re in active use. If you’re being blocked at Yahoo that’s a different issue, but you’d need to share the Yahoo rejection message before we can help with that. laura > On 17 Oct 2023, at 10:05, Giovanni Bechis via mailop > wrote: > > Hi, > yesterday some email have been blocked by SpamHaus and Yahoo (which might > query SpamHaus as well). > Error message are: > 503-Rejected because 38.124.232.237 is in a black list at zen.spamhaus.org > 503-Error: open resolver; https://www.spamhaus.org/returnc/pub/172.69.169.15 > > Checking the mentioned ip addresses on https://check.spamhaus.org, all ip > addresses are clean. > Does SpamHaus had known issues yesterday ? > > Regards > Giovanni > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail says "Message bounced due to organizational settings."
> On 27 Sep 2023, at 01:57, John Levine via mailop wrote: > > I'm doing some work for arxiv.org, the preprint server at Cornell university. > > Many gmail users have reported that when they try to send mail to > arxiv.org addresses to update their subscriptions, it fails saying > Message Blocked, with the explanation "Message bounced due to > organizational settings." > > This affects some but not all mail from Gmail. I am reasonably sure > that Gmail is not trying to deliver this mail before rejecting it. > > Any suggestions? Is this gmail.com <http://gmail.com/> directly or google hosted domains? laura -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] New Validity policy for paid FBL (ARF)
wE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDzdypi6WPqhVkFKkuLiMX0pY_5fawxs7P25-lwfZUyr7w==> >>> >>> >>> >>> <https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDyIo6EwBskR6pg3M12nuwEx_9G03qmurLHy8H_IjsK3cg==> >>> >>> >>> <https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDweOZAf2SFcCyyLHlLyd4j2GB_p_YWWJ_3WJxEqTQND2A==> >>> >>> >>> <https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDz5UNyOTEm_EvRFXdshn5-xBpkDGWEZYln2qrkxaFuQc-FVdHa5XQ8gkUA8UK9te-A=> >>> >>> >>> <https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDyEop3qI2i2HFrm2U65Sd5oxcB4tERwhAI5MzR-NKIKtw==> >>> >>> >>> CONFIDENTIALITY This email and any attachments are confidential and may >>> also be privileged or otherwise protected from disclosure. If you are not >>> the named recipient, please notify the sender immediately and do not >>> disclose the contents to another person, use it for any purpose, or store >>> or copy the information in any medium. >>> >>> You’ll find further information about privacy here >>> <https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDwp6TTQAR8uw54LR3mph76uODAm2MU0ep-sVltZqsar_A==>. >>> >> >> >> -- >> Steve Freegard >> | >> Senior Product Owner >> T. >> >> +44 7740 364348 >> abusix.com >> <https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDzZTf64_AIC7pyl-xmo2L5eYJtYu1PnTYrDUUBmQW-VxiqyfDuPS_3WZnIEFz1xocGdBhnxAEyhHhg3_G29KPX5gu0-0JxXoL3Lw4zV1rZI4zA5EgDWnGc90iUX1HRTDIs=> >> >> Book a meeting >> <https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDzdypi6WPqhVkFKkuLiMX0pY_5fawxs7P25-lwfZUyr7w==> >> >> >> >> <https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDyIo6EwBskR6pg3M12nuwEx_9G03qmurLHy8H_IjsK3cg==> >> >> >> <https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDweOZAf2SFcCyyLHlLyd4j2GB_p_YWWJ_3WJxEqTQND2A==> >> >> >> <https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDz5UNyOTEm_EvRFXdshn5-xBpkDGWEZYln2qrkxaFuQc-FVdHa5XQ8gkUA8UK9te-A=> >> >> >> <https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDyEop3qI2i2HFrm2U65Sd5oxcB4tERwhAI5MzR-NKIKtw==> >> >> >> CONFIDENTIALITY This email and any attachments are confidential and may also >> be privileged or otherwise protected from disclosure. If you are not the >> named recipient, please notify the sender immediately and do not disclose >> the contents to another person, use it for any purpose, or store or copy the >> information in any medium. >> >> You’ll find further information about privacy here >> <https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDwp6TTQAR8uw54LR3mph76uODAm2MU0ep-sVltZqsar_A==>. >> >> ___ >> mailop mailing list >> mailop@mailop.org <mailto:mailop@mailop.org> >> https://list.mailop.org/listinfo/mailop > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] WPEngine, Mail Channels, 365, MX Toolbox, Mail Genius
Your SPF record is not causing your mail to hit your junk folder. Also, the link from MXtoolbox shows there is a SPF record there. It’s red because the domain doesn’t align with your 5322.from address, but you aren’t going to be able to fix that. That’s a valid SPF record and the IP address the mail is sent from is within that block. https://tools.wordtothewise.com/spf/check/mail1.wpengine.com is a different way of looking at the SPF record itself. Things that could be causing or contributing to mail going to the junk folder: newish domain without a reputation bots triggering WP admin mail (wp websites were a big contributor to listbombing when we were hit some years back) your own filter configuration that blocks mail “from” your domain not coming from your MX or signed with your DKIM d=domain. the mailchannels IP has a bad reputation with your spam filter something about the mail is triggering bayesian filtering in your email client you’re using PHPmailer and there’s a lot of spam that uses PHPmailer Overall, there doesn’t appear to be anything wrong with your technical configuration. You may want to talk to the folks who are running your spam filtering service to see what they can tell you about how to adjust your settings to get mail in your inbox. If the problem is at other domains, you’re going to need to be more specific about which filters are treating your mail poorly before anyone can really give you a lot of assistance here. laura > On 5 Sep 2023, at 23:00, Mike Hammett via mailop wrote: > > We have a website on WP Engine. WP Engine sends its email through Mail > Channels. It's ending up in our Junk Mail box on 365. > > I test via MX Toolbox's Mail Deliverability Report. It fails for "Domain not > found in SPF", yet manually, everything I look up appears good. The IP it > sends from is included in the SPF record MXToolbox says. > > I test via MailGenius, and it says the SPF is good. > > > I'm clearly getting an undesired result by it hitting our Junk Mail folder. > MXToolbox says it's bad, but then has conflicting info elsewhere. Someone > else says it's fine. I'm not sure on how to proceed. It's not for sending > campaigns, just transactional email (sending to us website contact forms, > etc.). The domain is newish, but it's been around a few months. > > > https://mxtoolbox.com/deliverability/6e6dc435-d515-4fc9-afab-776a215a5095 > https://app.mailgenius.com/spam-test/5783b6?_gl=1*9cwct7*_ga*OTE0Njc2NTgzLjE2OTM5NDg0NTc.*_ga_2BJPW3X1ZW*MTY5Mzk0ODQ1Ny4xLjAuMTY5Mzk0ODQ2Mi41NS4wLjA. > > > I think I could set up DKIM, but that seems like it's not part of the > low-hanging fruit problem. > > > > - > Mike Hammett > Intelligent Computing Solutions <http://www.ics-il.com/> > <https://www.facebook.com/ICSIL> > <https://plus.google.com/+IntelligentComputingSolutionsDeKalb> > <https://www.linkedin.com/company/intelligent-computing-solutions> > <https://twitter.com/ICSIL> > Midwest Internet Exchange <http://www.midwest-ix.com/> > <https://www.facebook.com/mdwestix> > <https://www.linkedin.com/company/midwest-internet-exchange> > <https://twitter.com/mdwestix> > The Brothers WISP <http://www.thebrotherswisp.com/> > <https://www.facebook.com/thebrotherswisp> > <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg> > ___ > mailop mailing list > mailop@mailop.org <mailto:mailop@mailop.org> > https://list.mailop.org/listinfo/mailop -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] RNC v. Google Dispositioin
> On 29 Aug 2023, at 03:31, John Levine via mailop wrote: > > It appears that Anne Mitchell via mailop said: >> I'm surprised that nobody has mentioned this here, because it was a big win >> for Gmail plus has language which is applicable to any ISP. > > Mike Masnick at the always interesting Techdirt blog has a longer take. You > can tell from the URL what he thinks of it. > > https://www.techdirt.com/2023/08/28/as-predicted-judge-laughs-gops-laughable-google-spam-bias-lawsuit-right-out-of-court/ Reading that article was a trip down memory lane for all the spammers that sued ISPs to try and get them to deliver the mail. I’d forgotten e360 sued Comcast, though. laura -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] hotmail.com SPF forgot IPv6
> On 21 Aug 2023, at 10:08, Laurent S. via mailop wrote: > > > On 21.08.23 10:26, Laura Atkins via mailop wrote: > >> This recommendation doesn’t make sense. For companies that actually >> reject due to SPF, they’re most likely going to do it after MAIL FROM: >> At this point in the transaction, they don’t know what the DMARC domain >> is. They can look up DMARC for the domain in the MAIL FROM: but that may >> or may not be connected to the actual domain in the 5322.from. >> >> I mean, I think it’s a bad idea to reject for SPF failures, but for >> folks who do I can’t imagine they want to see the full content of the >> message before just throwing it away. That seems wasteful. >> >> laura >> > > > Exactly. Also, I don't think that all the scenario where a legitimate > mails gets a SPF failure (due to forward/relay for instance) a DKIM will > still be good. If they don't care about breaking SPF, I guess they don't > care about breaking DKIM either. Avoiding to break SPF isn't rocket science. I think you misunderstood me. There are lots of straight forwarding situations where SPF is broken, but DKIM is intact. I think it’s a poor operational decision to block on SPF failure, but I also think it’s a poor operational decision to SPF -all. But this is all chickens coming home to roost where folks are rejecting wanted mail due to SPF failures. I think it says something that we’re almost 20 years into SPF being a thing, and it’s just now where it’s causing consequences. Does that mean no one has been enforcing it right? Or we’re just now noticing? Or something else completely. > We reject on SPF hard failure (-all) after RCPT TO, in order to still > let our users welcome list repeat offenders. For this, the sender host > (or ip) must have been provided. This works great with mailing-lists and > forwards for instance. How do your users know to welcome list if the mail is rejected before it gets to the user? Do you notify them you rejected mail being sent to them or something? laura -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] hotmail.com SPF forgot IPv6
> On 19 Aug 2023, at 12:31, Gellner, Oliver via mailop > wrote: > > >> 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 policy > into SPF records. SPF does not allow one to to this. > What domain owners can do is set up a policy in the DMARC record. Of course > on the receiver side you can make up any number of additional or even > contradictory policies like the one you described, as in „your server, your > rules“. But I believe the guidance from M3AAWG which actually takes existing > policies from the sender side into account is more friendly and provides less > false positives. In a nutshell this means: Do not reject emails based solely > on SPF failures as soon as the sending domain has a valid DMARC record. This recommendation doesn’t make sense. For companies that actually reject due to SPF, they’re most likely going to do it after MAIL FROM: At this point in the transaction, they don’t know what the DMARC domain is. They can look up DMARC for the domain in the MAIL FROM: but that may or may not be connected to the actual domain in the 5322.from. I mean, I think it’s a bad idea to reject for SPF failures, but for folks who do I can’t imagine they want to see the full content of the message before just throwing it away. That seems wasteful. laura -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Guide for setting up a mail server ?
> On 10 Jul 2023, at 17:44, Grant Taylor via mailop wrote:
>
> Dear ${FELLOW_EMAIL_ADMINIATRATOR},
>
> I don't know how to preface this email other than to say -- I believe the
> following needs to be said lest we loose even more control of our email
> community.
>
> I'm sorry that both 1) I feel that the following needs to be said and 2) that
> I'm the one that's saying it.
>
> ...
>
> I can't say that any of Richard's comments are technically wrong. But I will
> say that the tone of what the email represents is both disappointing and
> concerning to me.
>
> N.B. that Richard is one of many that have said similar things. My comments
> are *NOT* directed at Richard.
>
> Rather many of us are culpable for allowing things to get into this state by
> not actively fighting against it. -- The first step is admitting you have a
> problem.
>
> ...
>
> I agree that email is not easy by any stretch of the imagination. But
> comparatively I suspect it's easier to host your own email than starting a
> company to build a car from scratch. Is this a good comparison, probably
> not. But is it true? I really hop so.
>
> On 7/10/23 7:48 AM, Richard Clayton via mailop wrote:
>> not that I know of -- arguably there should be one, but perhaps it will just
>> encourage unwise activity. I am reminded of Usenet advice of not posting for
>> the first six months and if you ask why that is good advice then add another
>> six months...
>
> I agree with -- what I'll call -- auditing. I don't agree with asking
> questions meaning that you need to extend the audit time. I've seen some
> EXTREMELY intelligent questions asked by people very knew to the situation.
>
> Simply asking a question does not, in and of itself, mean that someone is
> ignorant of the topic. Quite the opposite can be true. E.g. "Is there any
> reason to ever run an open relay? There seem to be LOTS of negative points
> to doing so; ." type thing.
>
>> I recently reviewed an IETF draft on (de)centralisation which observed that
>> running your own mail system, rather than using a centralised provider was
>> far too hard.
>
> This disappoints me, greatly. Both the idea that running a decentralized
> mail server is hard and more so that such recommendations would admit or
> worse support such a stance.
>
>> In discussions with Eliot Lear we ended up with a list of things you had to
>> do:
>> * configure and manage the MTA
>
> This is obvious and not specific to email. You have to configure the service
> for any and all services. Chances of defaults doing exactly what you want
> are quite rare.
>
>> * arrange for a backup MTA
>
> I'll argue that requiring a backup MTA is not strictly required.
>
> I'll absolutely agree that a backup MTA is best practice.
>
> There is a really big delta between strict requirement and best practice.
>
>> * manage DNS MX, DKIM, DMARC and SPF records
>
> None of those are strictly required either. Business to business email can
> function without any of them.
This is bad advice.
B2B email requires a MX (like, if you don’t have an MX do you even email?)
In order for mail to be accepted at Google Workspace you must have either SPF
or DKIM. There have been long discussions here about that. If you’re on IPv6
they’re a MUST (in the traditional RFC sense))
DMARC is wholly optional.
laura
--
Having an Email Crisis? 800 823-9674
Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741
Email Delivery Blog: http://wordtothewise.com/blog
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: [mailop] Transparency is key... Here is a perfect example.. M3AAWG is coming.. time to take a st
> operated by the same company, but the domain info itself does not say that. > > I know that whois is a lost cause, and I still believe that methods for > identifying the real controlling entities of domains would help quite a bit > in reducing unwanted e-mail spam. > > Cheers, > Hans-Martin > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Microsoft Office365 not rejecting emails when instructed so by SPF recored?
> On 26 May 2023, at 19:16, Scott Mutter via mailop wrote: > > On Fri, May 26, 2023 at 12:34 PM Brandon Long <mailto:bl...@google.com>> wrote: >> When forwarding mail, there are two options: rewrite the envelope sender or >> not. There are a variety of pros and cons to both of them, and cases where >> one or the other is more prominent. Not rewriting has been the dominant >> form of 1:1 forwarding such as aliases and address migration, and enforcing >> SPF -all would break that use case. > > If you ask me - a better solution would be to do away with forwarding > completely and incorporate POP checks, like Gmail does. This alleviates all > of the issues with forwarding mail in relation to SPF and DKIM. Sure, let’s do that. How? How do we get (conservatively, covering 80% of the mail in the US) 100 systems to take away functionality that users rely on. Don’t forget, you’ll need to explain to those systems why they should do it, how they should explain it to users and full training programs for customer support staff to be able to deal with the influx of calls from upset people who are no longer able to use functionality they are accustomed to. You’ll also need to provide ample time for forwarding only services (like alumni accounts) to go through a budget cycle to acquire hardware and employees to manage the POP services for their users. Some states have 2 year budget cycles, so we’re probably looking at a minimum 3 to 4 years before they’ll be able to transition. > But I know that stance is wildly unpopular since it breaks the "it used to > work that way" narrative. But at some point you add so much to a system that > it becomes so bloated and overloaded that nothing can be accomplished. The > more simple a system is the more efficient it is going to be. Outside of > external mail server forwarders, a properly constructed SPF record can go a > long, long way towards alleviating the spam problem. How? I’ll give you a hint: spammers use SPF, too! > How much is it worth to keep external forwarders working at the cost of spam > prevention? SPF was never expected to solve the spam problem. I know the original author claimed it would, but the rest of the folks working on it were very clear this was not a spam solution. > If forwarding mail is so important, can a better system for handling > forwarded mail be developed? I'm just not sure if the answer is to continue > to add systems and directives to email to solve all of this. All the questions I asked above will also need to be answered for deploying a new solution to forwarding. These are major hurdles to adoption, so they should really be addressed as part of the protocol development stage. laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Microsoft Office365 not rejecting emails when instructed so by SPF recored?
> On 23 May 2023, at 21:09, Benny Pedersen via mailop wrote: > > Todd Herr via mailop skrev den 2023-05-23 20:54: > >>> Indeed, an email will only be rejected if it has DMARC setup as >>> reject. >> There should be one exception to the rule of waiting till after DATA >> to check for a DMARC policy, and that's in the case of the following >> SPF record: >>> "v=spf1 -all" >> It seems wholly appropriate to reject at MAIL FROM if the RFC5321.From >> domain publishes an SPF policy that says "This domain is not used to >> send mail, ever." > > domains with this spf would possible know that spf is more weak then then rfc > 7505 (nullMX) ? nullMX means the domain doesn’t receive mail. v=spf1 -all means the domain doesn’t send mail. When I’m working with clients who are setting up domains for not-email I recommend both as they address the issue from different directions. It’s also perfectly legit for a domain to receive email while never sending email. I have domains set up to receive client mail, for instance. They never send mail, they’re collection addresses. laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] United Airlines / mileageplus DNS/rDNS mismatch issue
That’s a Sendgrid IP, they likely told UA to put in a DNS record, but UA never did. ¯\_(ツ)_/¯ n > On 9 May 2023, at 18:01, Stephen Frost via mailop wrote: > > Greetings, > > I'm getting some inbound email attempts that I believe are legitimate > from United Airlines that are being rejected due to: > > May 9 12:55:38 tamriel postfix/smtpd[1221960]: warning: hostname > o1.email.smallbusiness.mileageplus.com does not resolve to address > 50.31.61.242 > > Tracking this back, near as I can tell, postfix is correct here in that > 50.31.61.242 / 242.61.31.50.in-addr.arpa resolves to > o1.email.smallbusiness.mileageplus.com but > o1.email.smallbusiness.mileageplus.com doesn't seem to actually exist: > > dig o1.email.smallbusiness.mileageplus.com a > > ;o1.email.smallbusiness.mileageplus.com. IN A > > ;; AUTHORITY SECTION: > smallbusiness.mileageplus.com. 600 IN SOA vndcdf-fs-gma3-vip.ual.com. > ualipconfig.united.com. 40 10800 3600 2592000 600 > > Hopefully someone on here is from UA or knows how to get in touch with > someone there who could like into fixing that. > > Thanks, > > Stephen > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Google cannot verify email authentication any more?
How long has it been since you changed it? Is it possible Google is caching SPF for longer periods of time than are in the cache to reduce their overhead? laura > On 21 Apr 2023, at 08:53, Alessandro Vesely via mailop > wrote: > > This morning I found this: > > 421-4.7.0 This mail is unauthenticated, which poses a security risk to the > 421-4.7.0 sender and Gmail users, and has been blocked. The sender must > 421-4.7.0 authenticate with at least one of SPF or DKIM. For this message, > DKIM > 421-4.7.0 checks did not pass and SPF check for [tana.it] did not pass with > ip: > 421-4.7.0 [94.198.96.74]. The sender should visit > 421-4.7.0 https://support.google.com/mail/answer/81126#authentication for > 421 4.7.0 instructions on setting up authentication. > d9-20020a05640208c900b00504b18d24f8si586620edz.362 - gsmtp > > I changed SPF recently (after changing ISP), while DKIM signing remained the > same. I attach the message. > > Best > Ale > -- > 2023.eml>___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Outlook.com: missing data in SNDS + IPs blocked on Apr 06
> On 16 Apr 2023, at 13:33, Fernando MM via mailop wrote: > > Hi Mark, > > April 6 data is still missing on SNDS and most of the IPs are still blocked. > > But a few hours ago I received these replies for 3 tickets that were created > on Apr 10: > > We have implemented mitigation for your IP (XX.XX.XX.XX) and this process may > take 24 - 48 hours to replicate completely throughout our system. > > I don't know why they reviewed the ticket again after replying that the IPs > wouldn't be unblocked. I will wait and check if they will review the other > tickets too. One thing I try and remind myself with dealing with Microsoft is that they have an extremely limited selection of uneditable boilerplates to work with in terms of replying to messages. So I often keep pushing even when they say things like “don’t qualify for mitigation” because I know that’s just the boilerplate they have to use. If I think there really is a good reason for mitigation (ie, I’m not trying to actually get a client to make a change) I write back and explain why I think it does qualify (briefly) and ask for mitigation. Sometimes I’ll even ask for escalation. > I hope that Microsoft starts providing some information about why IPs are > suddenly blocked, specially for IPs that have a long term reputation without > issues. As I understand it, this will require negotiation with the MS legal team. I honestly don’t see that happening. > No need for internal details about their anti-spam system, of course, but > just a tiny amount of info would be extremely helpful for senders that want > to do the right thing. > > I just don't know what happened and if I should change something. Was there > an issue on our end? Or did they changed something on their end that > generated problems? Unfortunately, we have to black box it. laura > > On Sat, Apr 15, 2023 at 7:12 PM Mark Dale <mailto:m...@mailmanlists.net>> wrote: >> >> Hi Fernando, >> >> Did you make any headway this issue? We've been having the same issues since >> April 6. >> >> Regards, >> Mark >> >> On 2023-04-13 15:25, Fernando MM via mailop wrote: >> > Hi, >> > >> > On Apr 06 we detected that 28 IPs were blocked in Outlook.com, all with >> > the following error: >> > >> > 550 5.7.1 Unfortunately, messages from [185.103.9.41] weren't sent. >> > Please contact your Internet service provider since part of their network >> > is on our block list (S3150). You can also refer your provider to >> > http://mail.live.com/mail/troubleshooting.aspx#errors >> > <http://mail.live.com/mail/troubleshooting.aspx#errors>. >> > >> > >> > Although some of the blocked IPs were new, most of them were in use by the >> > same customers for years without issues. Part of them didn't had a single >> > spam report or spam trap hit in the last 3-6 months. >> > >> > After making sure that these servers weren't compromised, I opened tickets >> > at https://olcsupport.office.com/ <https://olcsupport.office.com/> and, >> > after escalation, the response was that the IPs didn't qualify for >> > mitigation at this time or that there were "changes in email sending >> > volume" ( there weren't, the volume hasn't changed since we have limits >> > for each IP/customer to avoid these issues ) >> > >> > Today I noticed that the data on Apr 06 in missing in SNDS. All other >> > dates are showing up, just Apr 06 is missing. >> > >> > I was wondering if anyone else experienced similar issues on Apr 06 with >> > missing data on SNDS or a high number of IPs getting blocked? >> > >> > Thanks. >> > >> > ___ >> > mailop mailing list >> > mailop@mailop.org <mailto:mailop@mailop.org> >> > https://list.mailop.org/listinfo/mailop >> >> > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SPF behavior on email forwarding
> On 14 Apr 2023, at 12:26, Cyril - ImprovMX via mailop
> wrote:
>
> Hi!
>
> What is the best approach when you receive an email that doesn't respect the
> SPF (with a hard fail)?
>
> I'm asking because we've been running ImprovMX for a few years now and the
> decision we took was that if you send us an email with a SPF that is failing
> ("-a"), we immediately refuse the email.
>
> For me, the reason was pretty straight forward ; you set your SPF in a way
> that you ask for it to fail, so it makes sense that we refuse it if ... it
> fails.
>
> But I just discovered that, among others, Google Workspace and Namecheap
> breaks the SPF when they forward an email!
Unless they’re rewriting the envelope, yes. This is part and parcel of how SPF
works. I’m somewhat surprised that those services are not rewriting the
envelope, though. Unfortunately, I don’t have the Google access /
infrastructure to test this and see what they’re doing.
> If you set up a forwarding for your email, say "supp...@domain.com
> <mailto:supp...@domain.com>" that redirects to al...@destination.com
> <mailto:al...@destination.com> and send an email from b...@example.com
> <mailto:b...@example.com> to supp...@domain.com <mailto:supp...@domain.com>,
> the server @destination.com <http://destination.com/> will see an email
> coming from b...@example.com <mailto:b...@example.com>, but with the IPs of
> Google (or Namecheap).
>
> Since b...@example.com <mailto:b...@example.com> hasn't put the Google (or
> Namecheap) IPs in their SPF because they don't use it, their email will break
> SPF at @destination.com domain. <>
Google is using ARC which gives the recipient server the ability to see the
authentication as it was when the message was received by Google.
> So, since Google Workspace and Namecheap are doing this, it means that others
> are certainly also doing this.
Many forwarders rewrite the Envelope From so that the SPF record is theirs.
There’s even a standard documenting how to do this (SRS).
> What would be the best behavior here? Should we rely on both the SPF AND DKIM
> to refuse an email (compared to just the SPF), even if no DMARC are set?
> Should we allow all emails, even those who fail SPF?
> Should we only block when DMARC is set and fails?
>
> What is the best approach here?
The best approach really depends on what your goal is here. Refusing to deliver
mail that fails authentication checks will always result in legitimate and
wanted mail. It’s just the nature of the beast. These are really internal and
business decisions and while we all have opinions about how to handle
authentication failures and deliver mail, I don’t think we can tell you how to
manage your business.
> I personally don't want to accept emails that fails SPF with no further
> checks, otherwise it will be hell on the amount of emails we'll handle.
That is a valid business choice. But given the type of service you run, it is
going to result in a lot of lost mail and possibly unhappy customers.
When clients come to me with questions like this, we go through a discussion
designed to get them to identify what are their business priorities, what are
your business and technical constraints and how do you want your customers to
see you. Typically those discussions lead to clarity and then the business can
make the decision that’s best for them.
Overall, I think it’s generally a bad idea to block mail for SPF failures and,
quite honestly, most of the industry doesn’t do that.
laura
--
The Delivery Experts
Laura Atkins
Word to the Wise
la...@wordtothewise.com
Email Delivery Blog: http://wordtothewise.com/blog
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: [mailop] mailgun anybody? (variable sender address) time
> On 23 Mar 2023, at 14:47, Heiko Schlittermann via mailop > wrote: > > Hi, > > does anybody from mailgun read here? > Your messages are tmprejected at our systems, w/o any chance to pass > ever. Why are you using tmp rejections for something permanent? laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] warming up IPs, Microsoft?
> On 5 Mar 2023, at 21:53, Mark Fletcher via mailop wrote: > > On Sun, Mar 5, 2023 at 1:15 PM John R Levine <mailto:jo...@taugh.com>> wrote: >> >> If you need a big VM there's always AWS. They do a surprisingly good job >> of managing outbound mail. You get 62K messages/mo for free, then 10c per >> 1000 messages sent from a VM. > > For the amount of email we send, that cost structure wouldn't work for us. > And I thought AWS SES didn't have a good reputation, although I admit it's > been awhile since I looked. I have had a number of clients over the last 3 or 4 years using SES without any delivery problems that we could attribute to the IP addresses. Once we ran through fixing the things under their control, delivery was great. In the B2C space domain reputation is more important than IP reputation anyway. You may also want to look at SSDNodes for VPSes. laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] h-email.net
All of the domains I’ve checked with that MX are parked. Many of them go through multiple rounds of redirects and some of them even attempt to load apps when visited. I don’t know what they’re used for, but there don’t appear to be users there. When I do hygiene for clients I list anything using h-email.net as “parked domain” and start digging into what’s broken about client’s subscription process that led to parked domains getting on their lists. laura > On 3 Mar 2023, at 23:12, Jan Schaumann via mailop wrote: > > Hey, > > Does anybody here know who h-email.net is? I see > mail.h-email.net listed as the MX for a large number > of domains, but can't identify the organization behind > it. (Registered through Amazon, but whois privacy...) > > There are some indicators on the web that this might > be used for disposable mails, but it's not clear to me > if that is the sole use. > > The other curious thing is that mail.h-email.net has > only IPv4 addresses (in Digital Ocean and Hetzner), > but h-email.net has an SPF policy that only allows > IPv6 connections: > > $ host mail.h-email.net > mail.h-email.net has address 178.62.199.248 > mail.h-email.net has address 165.227.156.49 > mail.h-email.net has address 165.227.159.144 > mail.h-email.net has address 5.75.171.74 > mail.h-email.net has address 5.161.98.212 > mail.h-email.net has address 167.235.143.33 > $ host -t txt h-email.net > h-email.net descriptive text "v=spf1 ip6:fd96:1c8a:43ad::/48 -all" > > Any thoughts? > > -Jan > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] New member, trying to bring our mail server inline.
oops! Looks like I grabbed the wrong value. laura > On 3 Mar 2023, at 16:58, Mark Alley via mailop wrote: > > The selector seems to just be "1", of which the published record appears to > be valid in DNS. > > https://tools.wordtothewise.com/dkim/check/warwickri.gov/1 > > DNS propagation <https://dnschecker.org/#TXT/1._domainkey.warwickri.gov> > shows the DKIM record is resolvable across the internet, so resolution isn't > the problem, and it appears to be syntactically valid. > > @Salvatore - if you send a test message to the address provided to you on > https://learndmarc.com <https://learndmarc.com/>, it will show you > authentication results of direct messages from your mail server which you can > use to troubleshoot authentication further. > > - Mark Alley > > > > On 3/3/2023 10:27 AM, Laura Atkins via mailop wrote: >> Based on the headers of the message you sent here (to mailop), you have yet >> to actually publish a public key in DNS. >> >> https://tools.wordtothewise.com/dkim/check/warwickri/1677852725 >> >> laura >> >>> On 3 Mar 2023, at 14:12, Salvatore Jr Walter P via mailop >>> <mailto:mailop@mailop.org> wrote: >>> >>> We are in the final stages of migrating our exchange server from 2013 to >>> 2019. >>> I found out we had no SPF, DMARC, DKIM etc setup on our domains. >>> >>> Trying to get us setup properly and have SPF and DMARC working, DKIM is >>> another story. >>> Setup on the server, sent the key to our ISP for the DNS to be added. >>> Headers show the signature is being included. >>> >>> DKIM-Signature: v=1; a=rsa-sha256; d=redacted.gov <http://redacted.gov/>; >>> s=1; c=relaxed/relaxed; >>> t=1677851456; h=from:subject:to:date:message-id;(rest of key) >>> >>> >>> Also from the headers: >>> >>> Authentication-Results: inbound.redacted.net <http://inbound.redacted.net/>; >>> spf=pass smtp.mailfrom=redacted@ redacted.gov <http://redacted.gov/>; >>> dkim=fail header.d= redacted.gov <http://redacted.gov/>; >>> dmarc=pass (policy=none; pct=100; status=pass); >>> arc=none >>> >>> Any suggestion where to go from here? We are having all emails blocked by >>> AT, no idea why so trying to get all our ducks in a row and make sure we >>> are doing everything the “right” way. >>> ___ >>> mailop mailing list >>> mailop@mailop.org <mailto:mailop@mailop.org> >>> https://list.mailop.org/listinfo/mailop >> >> -- >> The Delivery Experts >> >> Laura Atkins >> Word to the Wise >> la...@wordtothewise.com <mailto:la...@wordtothewise.com> >> >> Email Delivery Blog: http://wordtothewise.com/blog >> >> >> >> >> >> >> >> >> ___ >> mailop mailing list >> mailop@mailop.org <mailto:mailop@mailop.org> >> https://list.mailop.org/listinfo/mailop > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] New member, trying to bring our mail server inline.
The message he sent to mailop had the selector I used and is also failing DKIM. laura > On 3 Mar 2023, at 16:58, Mark Alley via mailop wrote: > > The selector seems to just be "1", of which the published record appears to > be valid in DNS. > > https://tools.wordtothewise.com/dkim/check/warwickri.gov/1 > > DNS propagation <https://dnschecker.org/#TXT/1._domainkey.warwickri.gov> > shows the DKIM record is resolvable across the internet, so resolution isn't > the problem, and it appears to be syntactically valid. > > @Salvatore - if you send a test message to the address provided to you on > https://learndmarc.com <https://learndmarc.com/>, it will show you > authentication results of direct messages from your mail server which you can > use to troubleshoot authentication further. > > - Mark Alley > > > > On 3/3/2023 10:27 AM, Laura Atkins via mailop wrote: >> Based on the headers of the message you sent here (to mailop), you have yet >> to actually publish a public key in DNS. >> >> https://tools.wordtothewise.com/dkim/check/warwickri/1677852725 >> >> laura >> >>> On 3 Mar 2023, at 14:12, Salvatore Jr Walter P via mailop >>> <mailto:mailop@mailop.org> wrote: >>> >>> We are in the final stages of migrating our exchange server from 2013 to >>> 2019. >>> I found out we had no SPF, DMARC, DKIM etc setup on our domains. >>> >>> Trying to get us setup properly and have SPF and DMARC working, DKIM is >>> another story. >>> Setup on the server, sent the key to our ISP for the DNS to be added. >>> Headers show the signature is being included. >>> >>> DKIM-Signature: v=1; a=rsa-sha256; d=redacted.gov <http://redacted.gov/>; >>> s=1; c=relaxed/relaxed; >>> t=1677851456; h=from:subject:to:date:message-id;(rest of key) >>> >>> >>> Also from the headers: >>> >>> Authentication-Results: inbound.redacted.net <http://inbound.redacted.net/>; >>> spf=pass smtp.mailfrom=redacted@ redacted.gov <http://redacted.gov/>; >>> dkim=fail header.d= redacted.gov <http://redacted.gov/>; >>> dmarc=pass (policy=none; pct=100; status=pass); >>> arc=none >>> >>> Any suggestion where to go from here? We are having all emails blocked by >>> AT, no idea why so trying to get all our ducks in a row and make sure we >>> are doing everything the “right” way. >>> ___ >>> mailop mailing list >>> mailop@mailop.org <mailto:mailop@mailop.org> >>> https://list.mailop.org/listinfo/mailop >> >> -- >> The Delivery Experts >> >> Laura Atkins >> Word to the Wise >> la...@wordtothewise.com <mailto:la...@wordtothewise.com> >> >> Email Delivery Blog: http://wordtothewise.com/blog >> >> >> >> >> >> >> >> >> ___ >> mailop mailing list >> mailop@mailop.org <mailto:mailop@mailop.org> >> https://list.mailop.org/listinfo/mailop > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] New member, trying to bring our mail server inline.
Based on the headers of the message you sent here (to mailop), you have yet to actually publish a public key in DNS. https://tools.wordtothewise.com/dkim/check/warwickri/1677852725 laura > On 3 Mar 2023, at 14:12, Salvatore Jr Walter P via mailop > wrote: > > We are in the final stages of migrating our exchange server from 2013 to 2019. > I found out we had no SPF, DMARC, DKIM etc setup on our domains. > > Trying to get us setup properly and have SPF and DMARC working, DKIM is > another story. > Setup on the server, sent the key to our ISP for the DNS to be added. > Headers show the signature is being included. > > DKIM-Signature: v=1; a=rsa-sha256; d=redacted.gov <http://redacted.gov/>; > s=1; c=relaxed/relaxed; > t=1677851456; h=from:subject:to:date:message-id;(rest of key) > > > Also from the headers: > > Authentication-Results: inbound.redacted.net <http://inbound.redacted.net/>; > spf=pass smtp.mailfrom=redacted@ redacted.gov <http://redacted.gov/>; > dkim=fail header.d= redacted.gov <http://redacted.gov/>; > dmarc=pass (policy=none; pct=100; status=pass); > arc=none > > Any suggestion where to go from here? We are having all emails blocked by > AT, no idea why so trying to get all our ducks in a row and make sure we > are doing everything the “right” way. > ___ > mailop mailing list > mailop@mailop.org <mailto:mailop@mailop.org> > https://list.mailop.org/listinfo/mailop -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mail Sending Self-Test Platform
> On 1 Mar 2023, at 16:21, John R Levine via mailop wrote: > >> Still, i am a bit wondering; Looking at the data flushed in so far (and >> already multiple bugs filed against implementations)... there are a lot >> of funny milters and often unmaintained software integrated in funny >> docker stacks (probably preaching to the choir there, but i have a lot >> of grievances with those setups), and generally a lot of awry things >> (example.com. IN TXT "v=spf1 include:example.com -all" is, for example, >> far more common than i'd have ever believed...). > > In the DMARC working group we've had endless arguments about what changes > will or won't break existing DMARC setups, informed by a lot of opinions and > very little data. Actual data would be greatly appreciated. > > It's not surprising that there are a lot of broken DMARC and SPF records. The > question is whether anyone cares. My impression is that in many cases there > was a checklist item "DMARC" so someone did the absolute mimimum. A p=none > policy, a sloppy SPF record, and no DKIM is a strong hint. Likewise, there are countless folks out there recommending implement DMARC for every deliverability problem (with absolutely zero recommendations as to what that means). There are also soom EXTREMELY broken SaaS providers who have instructions for that say: publish this DKIM key in your DNS, publish this DMARC record and publish this SPF record - while the SaaS provider uses none of the customer domains anywhere in the mail. Additionally, there are scammers out there hunting for bug bounties using “your domain is at risk due to a lack of DMARC record, how much will you pay me for letting you know?” laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail blocking of good customer
If people intend to be interoperable, there is NO variation in what a 4xx and a 5xx mean. 4xx means: this message can be queued and retried at a future date. 5xx means: this message cannot be retried without human intervention. Those interactions are defined in RFC 821 and it’s successors. [1] The variation / confusion / problems / conflict comes when we try and use these very clear *transactional* signals to interpret what to do with a different and future message to the same address. Bounce handling in the transaction should follow the RFC. If the SMTP response starts with a 4, queue it and retry. If the SMTP response starts with a 5, stop trying to deliver it. Address handling and list hygiene is undefined in the SMTP spec. It’s something we’ve tried to cobble together with every group doing a different thing over the years. It’s a mess and it is complicated and there probably should be documentation of what to do with it. [2] laura [1] I’m still annoyed by “4xy: this message will never deliver” that a major ISP uses. If the message will never deliver, give it a 5xx. [2] Yes, this is my current project - figuring out a way to make bounce handling less of a maze of twisty little codes all alike and making it a clearer communication channel. > On 26 Feb 2023, at 05:12, Evan Burke via mailop wrote: > > > There's a lot of variation in what 4xx and 5xx mean in practice. This means > there's room for some senders to spend time investigating and understanding > what each receiving domain's 4xx and 5xx (and subcategories thereof) actually > mean for address delivery over time, and for designing rules and policies to > handle them based on observed outcomes - IF those are a more reliable > indicator than the general guidance from RFCs. > > That doesn't mean Luke is ignoring null MXes. > > On Sat, Feb 25, 2023 at 8:00 PM Benny Pedersen via mailop <mailto:mailop@mailop.org>> wrote: >> Luke via mailop skrev den 2023-02-26 04:15: >> > I can assure you sendgrid retries 4xx. We also don't retry 4xx. We >> > also retry 5xx. We also don't retry 5xx. How is it 2023 and people >> > still think 4xx means retry and 5xx means don't retry? >> >> what books do you read ? >> >> maybe rfc 7505 is soon or later for all ? >> ___ >> mailop mailing list >> mailop@mailop.org <mailto:mailop@mailop.org> >> https://list.mailop.org/listinfo/mailop > _______ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Feedback Loops and Sub-Domains
> On 9 Feb 2023, at 09:21, Gellner, Oliver via mailop wrote: > > On 2023-02-08 22:51, Support 3Hound via mailop wrote: > >> Note that especially on some providers, most user "feel" the reporting as a >> sort of "fast unsubscribe"... > > Just as a side note: In my experience the spam report button is not only used > as a sort of fast unsubscribe, but also as a replacement for the delete > button. We have countless examples of back-and-forth conversations of > hand-written messages between friends or relatives which then end up in a > FBL. In those cases it is obvious that the reporters do not want to not > receive any more messages of the other party, but more probably thought "I > have read this email, it can be removed now from my inbox". Who cares whether > its moved into the recycle bin, the spam folder or some other place. This is why complaints is such a noisy metric to use and why many compliance teams work on the total volume of complaints rather than working each one individually. We know that some of the mail reported as spam isn’t actually actionable by the hosting company. This is actually true for the non-FBL complaints as well, although those are usually sent by more experienced folks. But, sometimes, it’s just not sensible to turn off a customer based on one or two complaints. > Of course with newsletter or other automated messages you cannot tell whether > the reporter wanted to actually mark this email as spam or just wanted to > delete it, so you end up unsubscribing them. And adding the number to reporting so you can identify if this is simply a one off or if your customer is behaving badly. laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Intentionally vague SPF records.
> On 11 Jan 2023, at 13:08, Simon Burke via mailop wrote: > > All, > > This is an odd scenario, but sadly one I find myself in. > > Work is a large organisation, and currently does not have an SPF record. The > reason is that there are a large (and unknown) number of internal and > external parties that send mail on our domain, as well as sub-domains. Most bulk services use either a custom subdomain in the customer’s domain space for the 5321.from or their own string in the 5321.from. This is primarily to deal with bounces - as anything that fails to deliver should go back to the sending service not to the original sender. A lot of places (SES, Mailchimp, Constant Contact) use their own 5321.from addresses by default and there’s no need to add the include: record at all. If your user base is using custom 5321.from you’re going to need to set up DNS records for those (CNAMEs are common). Do you have a lot of users with 1 to 1 email through external relays? > So, even if we do determine who sends email on the domain, we would then have > an issue with max lookups and record length. I find, generally, this happens but in most cases it doesn’t have to. Despite what a lot of people think, they don’t need to add an include for every service they’re using in the spf record for their organizational domain. > I know we can use an SPF flattening service. However that either has a cost. > Or, although we can develop something in house, there's a 'bought not built' > ethos being pushed by management. Sparkpost uses macros, would that be possible? > As an out the box idea, what would the potential impact be of having an SPF > record stating just: > > "V=spf1 a mx +all" > > How bad of an idea would this be? If we also had a DMARC record set to either > quarantine or reject. Anecdotally, that would be a bad idea. What I’ve heard is this is actually something done for botnet sending and is treated as a bad reputation indicator. I don’t ever recommend this. laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is there a way to unsubscribe from Nextdoor emails?
I did have the same problem with them adding me to a ton of lists I didn’t want to be on (I’ve not lived in the US in 4 years, GTFO). Disabling notifications followed by deleting my account worked to stop the mail. If it’s not working for you, I might contact the privacy folks and tell them their mail system is broken if I was feeling generous. But the blocking the email at the source may be your only solution. laura > On 19 Dec 2022, at 16:26, Daniele Nicolodi via mailop > wrote: > > I had an account, I disabled all email delivery, and deleted the account. Now > Nextdoor is back with several messages per day. Unsubscribe link does not do > anything. > > Cheers, > Dan > > On 19/12/2022 16:51, Laura Atkins via mailop wrote: >> If you have an actual nextdoor account going into the account and setting >> everything to “never send me email, ever, no not even then” works fine. >> laura >>> On 19 Dec 2022, at 15:21, Daniele Nicolodi via mailop >> <mailto:mailop@mailop.org>> wrote: >>> >>> Hello, >>> >>> it seems that Nextdoor recently went on a mission to expand their user base >>> and are mailing former users with whatever crap. The unsubscribe link at >>> the end of their emails does nothing. If anything it seems that following >>> the link is seen as engagement and the number of usolicited emails >>> increases. >>> >>> Is there anything that can be done to make them desist or should their >>> messages simply be directed to /dev/null? >>> >>> Cheers, >>> Dan >>> ___ >>> mailop mailing list >>> mailop@mailop.org <mailto:mailop@mailop.org> >>> https://list.mailop.org/listinfo/mailop >> -- >> The Delivery Experts >> Laura Atkins >> Word to the Wise >> la...@wordtothewise.com <mailto:la...@wordtothewise.com> >> Email Delivery Blog: http://wordtothewise.com/blog >> <http://wordtothewise.com/blog> >> _______ >> mailop mailing list >> mailop@mailop.org >> https://list.mailop.org/listinfo/mailop > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is there a way to unsubscribe from Nextdoor emails?
If you have an actual nextdoor account going into the account and setting everything to “never send me email, ever, no not even then” works fine. laura > On 19 Dec 2022, at 15:21, Daniele Nicolodi via mailop > wrote: > > Hello, > > it seems that Nextdoor recently went on a mission to expand their user base > and are mailing former users with whatever crap. The unsubscribe link at the > end of their emails does nothing. If anything it seems that following the > link is seen as engagement and the number of usolicited emails increases. > > Is there anything that can be done to make them desist or should their > messages simply be directed to /dev/null? > > Cheers, > Dan > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Massive bounce report campaign
eceive emails from Outlook sender legitimately. > > > > What I'm hoping by reaching out to you is to hope someone has already > > faced something similar and has some suggestions on how to mitigate - > > or ideally block - this. > > > > This could be a pretty well DDoS attack done by mail servers. > > > > On the comment above regarding the bounce report being sent: That is > > my suspicion, by looking at the domain names (sp-bounce), the email it > > receives, and the sender activity. But maybe there is another logical > > explanation I'm missing! > > I mean, to have 50k connections per minute to deliver bounce reports > > means that the running campaign must be in the order of millions of > > emails just for Outlook! > > > > All help is deeply appreciated!!! > > > > Thank you all in advance. > > > > Best regards, > > Cyril > > ___ > > mailop mailing list > > mailop@mailop.org <mailto:mailop@mailop.org> > > https://list.mailop.org/listinfo/mailop > > <https://list.mailop.org/listinfo/mailop> > ___ > mailop mailing list > mailop@mailop.org <mailto:mailop@mailop.org> > https://list.mailop.org/listinfo/mailop > <https://list.mailop.org/listinfo/mailop> > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Massive bounce report campaign
> On 22 Nov 2022, at 11:39, Peter N. M. Hansteen via mailop > wrote: > > On Tue, Nov 22, 2022 at 11:54:21AM +0100, Cyril - ImprovMX via mailop wrote: >> I mean, to have 50k connections per minute to deliver bounce reports means >> that the running campaign must be in the order of millions of emails just >> for Outlook! > > 50k bounces per minute is abnormal, that's for sure. Agreed. I have clients who send tens of millions of emails a day and don’t get 50K delayed bounces. Most well configured systems don’t send delayed bounces, they reject inline. I’m not even sure how they’re getting the bounces from Outlook, as most are handled inline. > This sounds to me like your customer is using a really bottom of the > barrel spamto: list (on par with our bait list, to be found at > https://www.bsdly.net/~peter/traplist.shtml, which serves a > slightly different purpose). Yeah, the customer is a problem and needs to go away. > I would attack the problem at its source (your customer) and find out > what they thought they were doing. Or just tell them that their contract doesn’t allow for this type of mail handling. But, really, this isn’t a customer worth keeping. This is not accidental. laura > > - Peter > > -- > Peter N. M. Hansteen, member of the first RFC 1149 implementation team > https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/ > "Remember to set the evil bit on all malicious network traffic" > delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SPF (and other email security protocols) Survey
On Nov 21, 2022, at 7:45 PM, Stuart Henderson via mailop wrote: > > On 2022/11/21 13:55, Taejoong (tijay) Chung via mailop wrote: >> Please note that we do NOT collect any personal information, thus >> the Institutional Review Board (IRB) at Virginia Tech determined the >> survey as Non-Human Subjects Research. > > eh, that doesn't make any kind of sense. Do you know what an IRB is and what their role is? While the terminology may be not what I’d choose the underlying message is: - This research project has been reviewed by the appropriate panel at the research institution; - This research project has been determined not to be performing research that can harm people and/of collect clinical data about them as individuals that can be tied directly to them; - This research project is not subject to the more extensive rules and regulations related to human research. If you’d like to discuss the form of the warning and the wording specifically, I’m sure there are fora hosted by the various government agencies and oversight organizations that you can join to tell them their wording is confusing. Finding those fora is left as an exercise for the reader. Laura ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [EXTERNAL] Really good paypal phishing email this morning
Looks like this is evolving. The first round was the scammers impersonating PayPal. Looks like they got a handle on that (after a few weeks) but failed to think like the bad guys and anticipate the next round. Hopefully the fix is something that can be tweaked to cover brands not PayPal rather than having to invent a new system to identify this kind of phish. Laura Sent from my iPhone > On Nov 18, 2022, at 9:35 PM, Michael Wise via mailop > wrote: > > > > This .. is what I wanted to see. > Did it really go to you, or did it stop off somewhere else first? > > To: zachery Rose > > It does appear that it went direct, so my initial theory is off I guess. > > Aloha, > Michael. > -- > Michael J Wise > Microsoft Corporation| Spam Analysis > "Your Spam Specimen Has Been Processed." > Open a ticket for Hotmail ? > > From: mailop On Behalf Of Zach Rose via mailop > Sent: Friday, November 18, 2022 11:38 AM > Cc: mailop@mailop.org > Subject: Re: [mailop] [EXTERNAL] Really good paypal phishing email this > morning > > Yeah, that's my theory at the moment, very likely that the call is coming > from inside the house, but they didn't find the person who made the call > before it was made. > > > Delivered-To: REDACTED > Received: by 2002:a05:640c:1b81:b0:190:7afb:ee7a with SMTP id r1csp516216eiw; > Fri, 18 Nov 2022 06:23:32 -0800 (PST) > X-Google-Smtp-Source: > AA0mqf6dcoQaNhG4JYaaq7jvwEAJxfF8XCQ2Zy1qPt4mGssaSyPzrvU0HsohJxkBvLOIjhuKLb6N > X-Received: by 2002:a65:67d1:0:b0:476:87ad:9d78 with SMTP id > b17-20020a6567d100b0047687ad9d78mr6785903pgs.169.1668781412334; > Fri, 18 Nov 2022 06:23:32 -0800 (PST) > ARC-Seal: i=1; a=rsa-sha256; t=1668781412; cv=none; > d=google.com; s=arc-20160816; > b=U4pbrfCYSxjulk8kCNLer1j7TfaCaowzf2yDYMqeQMVmG4g/JvAXzf0m4serzWoqTi > OBEY9TrwfM2j3yQssfS8OMOnWmBP+pO7KYBmg67sBb57BdZlx/+txIylik9rNKuyXsEh > O5+LN63Y1RqiSPLK44tgV3uHSeYS5n+qE0gJHgS1lojzvH/tEkxESiQHix+K7sWYnBUt > EXjoD4UKa4x1WGOsOPsb64AYM/AMs2TImhoZCqg+tT2Otsn1/Hz34iMozy9tR0yBB15q > +Eq4bNx9gjV8EpetyAjAQF7XHwWknzhig/MtiVy76GwNuCpUxd8yW+Bw3/fwTtBL6zl6 > QFYQ== > ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; > s=arc-20160816; > h=amq-delivery-message-id:mime-version:from:to:subject > :pp-correlation-id:message-id:date:content-transfer-encoding > :dkim-signature; > bh=+ooJ/KHJ7NcHSktaVA2Efxv2wUuyyzgRC9OcH8lTKPI=; > b=PbkHny3v4CR7wqQUcdh8f9PRFBMO+7dUlCVLzG9d8uDG0Uc+4jNqlkRB5chwPq1AUw > QG3rN1n+lpU1t/MEz0fnZ2k1Rwzrr0j/2L0fHhhX0eJ8UheOHbcVNDSF1hjDfwPayN43 > ggWon6WA5mEYJ6jTPt5ODvSC0shj5SrQBq2C57tCG4WOjWGK63UhilfiZS/GgpoyzgvG > UItaCRQKijOkG9k8bNub0rZ77LEdRoCK6RaEe6mhKmTv0doesmgdyhlb8+1e8V8Uvy7T > tqhqfvqUyzVOgL5HmUZIjNl/XkNXA966EGTLfDqf1DWDsf0LRjpZpJiJViixPJ63UMKA > /azQ== > ARC-Authentication-Results: i=1; mx.google.com; >dkim=pass header.i=@paypal.com header.s=pp-dkim1 header.b=i5V5Jd8P; >spf=pass (google.com: domain of serv...@paypal.com designates > 66.211.170.89 as permitted sender) smtp.mailfrom=serv...@paypal.com; >dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=paypal.com > Return-Path: > Received: from mx1.phx.paypal.com (mx3.phx.paypal.com. [66.211.170.89]) > by mx.google.com with ESMTPS id > c5-20020a655a8500b0044fb332e9c2si4180181pgt.560.2022.11.18.06.23.32 > for > (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); > Fri, 18 Nov 2022 06:23:32 -0800 (PST) > Received-SPF: pass (google.com: domain of serv...@paypal.com designates > 66.211.170.89 as permitted sender) client-ip=66.211.170.89; > Authentication-Results: mx.google.com; >dkim=pass header.i=@paypal.com header.s=pp-dkim1 header.b=i5V5Jd8P; >spf=pass (google.com: domain of serv...@paypal.com designates > 66.211.170.89 as permitted sender) smtp.mailfrom=serv...@paypal.com; >dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=paypal.com > DKIM-Signature: v=1; a=rsa-sha256; d=paypal.com; s=pp-dkim1; > c=relaxed/relaxed; > q=dns/txt; i=@paypal.com; t=1668781410; > h=From:From:Subject:Date:To:MIME-Version:Content-Type; > bh=+ooJ/KHJ7NcHSktaVA2Efxv2wUuyyzgRC9OcH8lTKPI=; > b=i5V5Jd8PU85hThj/qbYYNVtrAe9utMx13ls4RqO/wxfIUwhUDUQ0jzygOkTfY88K > BE74YiE8NsQGHdn4tMuGpInCw+7bnGFPBmOrlk22QztSUjqPH80z6lDtI7NrPpF6 > RYaiNevk4cJU4eEXXyr6fIT1fdcDwFdL4WErZ0w0KLpgYwd7dnwgqDrgvDWNJQWd > wzgmA+qZ+9UUrDCsv/h3JCmWBoJaFs3Eaph019ifvg2hLCvZ6Zo3iEqE8aLFQx3b > PDgFKnpTxxI+E1HaIpZJGQwpSI2q7TYrSKvwEBwko9OFXkWe9zlngcE/Km17TlpB > 0ujZJGDU7e4EtiOBfTM96g==; > Content-Transfer-Encoding: quoted-printable > Content-Type: text/html; charset="UTF-8" > Date: Fri, 18 Nov 2022 06:23:30 -0800 > Message-ID: <65.AC.09725.26597736@ccg01mail05> > X-PP-REQUESTED-TIME: 1668781403501 > X-PP-Email-transmission-Id: 917850f8-674c-11ed-96b4-3cecef6afc2b > PP-Correlation-Id:
Re: [mailop] Looks like I am getting blocked by msn.com only.
sender.office.com is for issues with O365 accounts only, it’s not for issues with the free mailbox domains. If you go to the URL in the message there will be additional information about how to resolve this. If the blocked IP is the same as the one you’re sending to the list, however, you should escalate to support office365 - exactly as the instructions tell you to do. If it’s from a different network, you should escalate to them. laura > On 18 Nov 2022, at 08:47, Faisal Misle via mailop wrote: > > Just to be sure because I didn't see you mention it, make sure you've > contacted them via the form I often see linked so many different ways: > https://sender.office.com <https://sender.office.com/> > > On Thu, Nov 17, 2022, at 10:26 PM, Ryan Prihoda via mailop wrote: >> Hey all, >> >> I received this rejection going to an msn account is there any way to >> resolve this? >> >> host msn-com.olc.protection.outlook.com >> <http://msn-com.olc.protection.outlook.com/> [104.47.18.97] SMTP error from >> remote mail server after pipelined sending data block: 550 5.7.1 >> Unfortunately, messages from [xxx.xxx.xxx.xxx] weren't sent. Please contact >> your Internet service provider since part of their network is on our block >> list (S3140). You can also refer your provider to >> http://mail.live.com/mail/troubleshooting.aspx#errors >> <http://mail.live.com/mail/troubleshooting.aspx#errors>. >> [AM6EUR05FT038.eop-eur05.prod.protection.outlook.com >> <http://eop-eur05.prod.protection.outlook.com/>] >> >> Thanks in advance, >> >> R. Prihoda >> >> ___ >> mailop mailing list >> mailop@mailop.org <mailto:mailop@mailop.org> >> https://list.mailop.org/listinfo/mailop >> <https://list.mailop.org/listinfo/mailop> >> > > _______ > mailop mailing list > mailop@mailop.org <mailto:mailop@mailop.org> > https://list.mailop.org/listinfo/mailop > <https://list.mailop.org/listinfo/mailop> -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Update: it's not. Re: T-Online is now really blocking messages from non-commercial and simliar senders
No, they belong to all senders. For instance, my mail server can connect and send mail to t-online. I’m not the only person who has said that in this thread. Laura Sent from my iPhone > On Oct 21, 2022, at 6:49 PM, Gellner, Oliver via mailop > wrote: > > >>> Am 21.10.2022 um 18:43 schrieb Laura Atkins via mailop : >>> >> The above statement is untrue. I know a number of mailservers that are able >> to successfully send mail to t-online.de and have never contacted the tosa@ >> address. > > Since when do those mailservers exist? Do they belong to a large ESP? > > — > BR Oliver > dmTECH GmbH > Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe > Telefon 0721 5592-2500 Telefax 0721 5592-2777 > dmt...@dm.de * www.dmTECH.de > GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927 > Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher > Datenschutzrechtliche Informationen > Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser > ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in > Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder > sich bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen > unter anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren > Rechten sowie die Kontaktdaten unserer Datenschutzbeauftragten finden Sie > hier. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Update: it's not. Re: T-Online is now really blocking messages from non-commercial and simliar senders
> On 21 Oct 2022, at 17:16, Kai 'wusel' Siering via mailop > wrote: > > Moin, > >> Consider T-Onlines move more like the overall accepted policy of not >> accepting mail from IPs that somehow have traces of residential in their PTR >> (cable, dialup etc.)? > > No. As it's not relevant what your PTR says, you are always 554'd until you > contact t...@rx.t-online.de. Add a second IP to your mail-out.fqdn? 50% > 554's. As you put it: "That is the trouble with examples." ;-) Just so we don’t end up in a position where people spread this disinformation. The above statement is untrue. I know a number of mailservers that are able to successfully send mail to t-online.de <http://t-online.de/> and have never contacted the tosa@ address. laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Email Cloud Providers
> On 20 Sep 2022, at 20:09, Michael Ellis via mailop wrote: > > Anyone have a suggestion for a good cloud email provider with good > deliverability and control over their customers? > > My client asked and said: > The big three seem to be Google, Microsoft, or Amazon. I expect that Google > would be good but they are the most expensive and I have concerns about them > reading every email that goes through. I use a lot of Microsoft software but > I have mixed feelings about the company. They can make some good products, > but they also screw up regularly and are difficult to work with. Amazon is an > amazing company and I’m doing more and more business with them, even though I > worry about them becoming too dominate. Their SES email has terrible > deliverability, from what I’ve seen, but I don’t know much about their > regular mailbox service. Do you know how their deliverability is? Amazon SES delivery is fine for senders who are doing the right things. I have had multiple clients using Amazon SES shared IP pools (including one that is sending in the 10s of millions range per day) over the last few years and have not seen any universal problem with reputation and delivery. I can see the reputation of the IPs in Google Postmaster Tools and there’s no real problem with their IP rep. Even my clients that are using the default 5321.from domain are seeing good inboxing and few delivery problems for decent senders. Clients are both B2B and B2C, which covers a lot of different filtering types. If you’re looking for mail hosting, I generally recommend Fastmail for folks looking for mail hosting. It’d be where we’d move, but we have some special needs in terms of filters and they (understandably) can’t accommodate that. -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Feedback loops (was: The oligopoly has won.)
> On 14 Sep 2022, at 09:48, Otto J. Makela via mailop wrote: > > On 13/09/2022 02.44, Brandon Long via mailop wrote: > >> Most of the major mailbox providers do have other feedback loops, >> many based on ARF, that can be used for this... > Has anyone put together a good summary of available feedback loops, > specially from big players? I used to maintain one but now I point folks at the Validity universal FBL signup page. Last I looked they were also including FBLs that they didn’t handle the signup for. A few things to note: * all the FBLs that I am aware of include consumer mail, even when the mailbox provider handles mail for hosted domains * with the exception of Google’s complaint percentage calculation in postmaster tools, FBL %s may not reflect actual complaint percentages. In most places recipients cannot report spam for mail already in the spam folder. * FBL reports typically are only generated when the recipient is using a client provided by the FBL provider. If someone is using Outlook for desktop or Apple’s mail.app the “this is spam” button does not generate a FBL complaint. * it is common (and has been for a decade or more) for bad players to manipulate complaint percentages through waterfalling another other techniques as a way to hide their activities from abuse desks. * from my perspective, complaint rates are an increasingly unreliable signal. a very high complaint rate is informative, but the a lot of spam goes to the bulk folder and gets few or zero complaints. laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] The oligopoly has won.
> On 14 Sep 2022, at 01:24, Jay Hennigan via mailop wrote: > > On 9/13/22 16:13, John Levine via mailop wrote: > >> Um, why is it Google's fault that some random blacklist erroneously >> listed some of their IPs? >> As someone else said, it only makes sense to block IPs if you believe >> they will never, ever send mail your users want. > > That's not how blocklists work. They lists IPs that are sources of spam. You forgot the modifier “some” in front of blocklists. There are many different kinds of blocklists, some which have nothing to do with IPs sending spam. laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] The oligopoly has won.
> On 13 Sep 2022, at 00:54, Brandon Long via mailop wrote: > > On Mon, Sep 12, 2022 at 4:16 PM Paul Kincaid-Smith <mailto:p...@emailgrades.com>> wrote: > > We have a reasonably large sample of messages sent from Gmail, Yahoo and > Outlook and can assess how much was "spam foldered" by each of those > services. We are in the same ballpark as John Levine, who estimated that > "about 30% of the mail I get from Gmail is spam." > > EmailGrades collects metrics about senders and receivers, primarily to > measure inbox placement and recipient engagement for commercial ESPs vs a > cohort of their peers, but we also have insights regarding messages sent by > mailbox providers like Gmail, Yahoo and Outlook. For the month of August > 2022, millions of messages received from Gmail, Yahoo and Outlook's email > infrastructure by hundreds of thousands of panel mailboxes reveals the > following spam foldering rates: > > Received at Gmail | Received at Yahoo | Received at Outlook > Sent from Gmail 16% 38% 49% > Sent from Outlook 47% 78% 47% > Sent from Yahoo5% 3% 9% > > The way to read this table is, "Of the messages received by our Yahoo panel > mailboxes, 38% of those sent by Gmail were routed to Yahoo's spam folder" and > "Of the messages received by our Outlook panel mailboxes, 9% of those sent by > Yahoo were routed to Outlook's junk mail folder" and "Of the messages > received by our Gmail panel mailboxes, 47% of those sent by Outlook were > routed to Gmail's spam folder." > > Does this indicate actual spam or just marked spam by the mailbox provider? > Does this indicate authenticated by > the sender provider, or less? This gets even more complicated when you talk > dkim replay. There was an interesting BoF discussion about this in London recently. I can share more details in a less public channel if you’re interested in discussing it. The upshot is that there is a LOT of B2B spam coming out of Gmail, Google Apps and O365. In fact the shared numbers track pretty closely with what was reported during the session. There’s an entire ecosystem of software, consultants and tools to help companies use Google to spam. There’s even advice on how to avoid google’s automated filters that stop a single user from sending more than 500 (or 1000 depending) emails per day. > Anyways, this also may indicate something else we know, which is that > spammers know that spamming another > gmail account is a great way for us to find them, so they tend to use Gmail > to spam non-Gmail. Google is great at blocking mail coming into their systems. They’re very much less good at blocking mail going out of their systems. > These numbers are also worse than when I worked on Gmail years ago, but it's > always possible things > got worse. As a recipient, Google is one of the primary sources of spam that makes it to my inbox. These percentages are higher than I’ve seen others report, but are in the same ballpark. > All other things being equal, Outlook filters messages from Gmail most > aggressively. Yahoo filters messages from Outlook most aggressively. Outlook > filters messages from Yahoo most aggressively. > > Outlook's spam percentages are higher than Gmail's but that may be because > Outlook chooses to block less outbound mail and instead flags questionable > outbound messages, sending them via a pool of IPs that ought to receive > additional filtering scrutiny. > > I expect any reputation based anti-spam system should be able to tell whether > an MSP does this. Google definitely had separate sending pools for various > things in the past, and does expect that receivers would eventually learn and > apply differential filtering based on that. No idea what the current system > does. The current system is pretty broken, but the bulk of the abuse is to business addresses and is designed to look like relatively normal B2B mail. The fact that the addresses are purchased or scraped is the big sign that the mail is spam. OTOH, I’m hearing a lot of complaining from the B2B spammers that the effectiveness of this mail is going way down. I don’t think this is really a filter issue - a lot of business filters let this mail through and let the company decide if they want to block the sender. I think the volume has gotten so high that recipients are Just Done with this baloney. laura — The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] The oligopoly has won.
> On 13 Sep 2022, at 04:07, Grant Taylor via mailop wrote: > > On 9/12/22 8:15 PM, Dave Crocker via mailop wrote: >> I believe 'impossible' is not the prevailing sentiment. >> I believe the prevailing sentiment is that it is a challenging task, >> requiring significant expertise. > > The prevailing sentiment that I see represented is that it's difficult enough > to host your own email as to be tantamount to impossible for an individual / > small company to be able to do so themselves. That’s not what I’m seeing at all. What I’m seeing is complaints that it’s difficult to host your own email without any real commitment of resources (whether those resources be time or money). A lot of the complaints I’m seeing are from folks who don’t want to really pay for hosting at a reputable provider that takes action against abuse. I know I’ve told this story before. Back in 2014 we needed to move our mailserver around onto a different IP SWIPed to us from HE. That did cause some delivery issues briefly, so we switched IPs back. By 2018, when we were shutting down the HE cabinet in preparation for our move out of CA, we moved to a VPS. We had zero problems with delivery at that time. Every once in a while a mail will end up in a spam folder but we don’t have problems with blocking at all. In fact, most of the time mail ends up in spam I’m replying to an inquiry from a potential client and it’s *their* domain rep that is the problem. > The frequency at which I see such comments is growing and the comments seem > to be more dire as time goes on. Don’t believe everything you read on the internet. laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SMTP noise from *.bouncer.cloud
e, provides the same results and -- can be automated. > > I hope, that soon or latter here will be DNSRBL with those "services", IMO > Spamhaus SBL starts with something similar recently (while not exactly > washers, it is good start). > > regards > > -- > Slavko > _______ > mailop mailing list > mailop@mailop.org <mailto:mailop@mailop.org> > https://list.mailop.org/listinfo/mailop > > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] double-singing with 2 independant DKIM-signatures for same domain
To answer your first question: a lot of mail is double signed. Signing with 2 identical d= but different s= is unusual, but I don’t think it’s prohibited anywhere. I also don’t think the RFC addresses anything about mail disposition in case of failures. It could be that the 2 identical d= one passing and one failing is causing a spam filter somewhere to act up. Given the problem is inside your infrastructure, the easiest fix is probably on your end. I’ve not had good experiences getting 3rd parties to modify these kinds of decisions (even when they’re clearly buggy and acting in ways that are probably unintended) and they often have what they perceive as valid reasons for making them. laura > On 26 Aug 2022, at 11:02, Stefan Bauer via mailop wrote: > > The other party is putting our mails in junk/spam folder. Mail is not > rejected and reports, that the reason is invalid dkim signatur. > > Am Fr., 26. Aug. 2022 um 11:56 Uhr schrieb Laura Atkins via mailop > mailto:mailop@mailop.org>>: > When you say “fail” do you mean the mail is being rejected? Or just that one > signature is failing to verify with DKIM? > > laura > > > >> On 26 Aug 2022, at 10:32, Stefan Bauer via mailop > <mailto:mailop@mailop.org>> wrote: >> >> Hi folks, >> >> are 2 DKIM-signatures in a mail with different s= but for same d= a problem >> in general? >> >> According to RFC 6376 4.2 i would say no, the receiver should check both >> signatures and not perm fail on the first, however we see some trouble with >> some recipients: >> >> Log from receivers: >> >> 2022-08-22T06:35:38+02:00 S2VG300MR01 MTA[10124]: 2022-08-22 06:35:38 >> [10124] 1oPzA2-0002dI-Qd acl_check_dkim: fail domain.tld domain.tld >> 2022-08-22T06:35:38+02:00 S2VG300MR01 MTA[10124]: 2022-08-22 06:35:38 >> [10124] 1oPzA2-0002dI-Qd DKIM: d=domain.tld s=18022801 c=relaxed/relaxed >> a=rsa-sha256 b=2048 t=1661142932 [verification failed - signature did not >> verify (headers probably modified in transit)] >> >> We have 2 mail worlds, that send mail for same domain. Sometimes, a mail >> from world 1, enters world 2, gets processed and send to third party. This >> way, the mail has 2 signatures. >> >> Thank you. >> >> Stefan >> >> >> _______ >> mailop mailing list >> mailop@mailop.org <mailto:mailop@mailop.org> >> https://list.mailop.org/listinfo/mailop >> <https://list.mailop.org/listinfo/mailop> > > -- > The Delivery Experts > > Laura Atkins > Word to the Wise > la...@wordtothewise.com <mailto:la...@wordtothewise.com> > > Email Delivery Blog: http://wordtothewise.com/blog > <http://wordtothewise.com/blog> > > > > > > > _______ > mailop mailing list > mailop@mailop.org <mailto:mailop@mailop.org> > https://list.mailop.org/listinfo/mailop > <https://list.mailop.org/listinfo/mailop> > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] double-singing with 2 independant DKIM-signatures for same domain
When you say “fail” do you mean the mail is being rejected? Or just that one signature is failing to verify with DKIM? laura > On 26 Aug 2022, at 10:32, Stefan Bauer via mailop wrote: > > Hi folks, > > are 2 DKIM-signatures in a mail with different s= but for same d= a problem > in general? > > According to RFC 6376 4.2 i would say no, the receiver should check both > signatures and not perm fail on the first, however we see some trouble with > some recipients: > > Log from receivers: > > 2022-08-22T06:35:38+02:00 S2VG300MR01 MTA[10124]: 2022-08-22 06:35:38 [10124] > 1oPzA2-0002dI-Qd acl_check_dkim: fail domain.tld domain.tld > 2022-08-22T06:35:38+02:00 S2VG300MR01 MTA[10124]: 2022-08-22 06:35:38 [10124] > 1oPzA2-0002dI-Qd DKIM: d=domain.tld s=18022801 c=relaxed/relaxed a=rsa-sha256 > b=2048 t=1661142932 [verification failed - signature did not verify (headers > probably modified in transit)] > > We have 2 mail worlds, that send mail for same domain. Sometimes, a mail from > world 1, enters world 2, gets processed and send to third party. This way, > the mail has 2 signatures. > > Thank you. > > Stefan > > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] Re: Gmail spam scoring via IPv6 different than IPv4?
I once (many years ago) used eBay as an example of a large company the couldn’t get SPF right in a talk I gave to a bunch of marketers. Unknown to me, eBay was in the audience. Their SPF record is no longer broken. Laura Sent from my iPhone > On Aug 12, 2022, at 7:10 PM, Marcel Becker via mailop > wrote: > > >> On Fri, Aug 12, 2022 at 11:01 AM Michael Peddemors via mailop >> wrote: >> >> Pop Quiz.. how many recursive DNS queries are supposed to be >> in SPF max? > > 42? > > - Marcel > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] HR 8160 and SB 4409: The "You're not allowed to run political campaign email through your spam filter" act
The research paper seems reasonably well done and I encourage people to actually read it and their conclusions rather than paying attention to the popular press takes on it. Laura Sent from my iPhone > On Jul 30, 2022, at 7:54 PM, Larry M. Smith via mailop > wrote: > > On 7/29/2022, Anne Mitchell via mailop wrote: >> I want to be sure that everyone here is aware of a piece of pending >> legislation in the U.S. that is in committee in both the House and the >> Senate right now. It's called the Political BIAS Emails Act of 2022 (BIAS is >> short for “Bias In Algorithm Sorting”), and it requires that, and I quote: >> “It shall be unlawful for an operator of an email service to use a filtering >> algorithm to apply a label to an email sent to an email account from a >> political campaign unless the owner or user of the account took action to >> apply such a label.” >> It is getting relatively very little press, and of course the chances of it >> passing are greater if nobody knows to oppose it. >> We've written an article about it, which includes what to do, whom to >> contact and how, etc., and which includes all relevant links, here: >> https://www.isipp.com/blog/do-you-want-political-email-to-bypass-spam-filters-and-go-directly-to-your-inbox-congress-does-heres-what-to-do/ >> Feel free to share - in fact please do, if this thing passes it's the >> camel's nose under the tent. > > IIRC, this all started because a research paper somewhere noted that a > specific political party seemed to have more deliverability issues than the > other prominent party did. Fast forward a bit and there exists a > vast conspiracy in anti-spam against that specific political party . > > I can't speak to all anti-spam systems, but the vast majority of them work on > behavioral models and not some list of word that someone has entered into a > list somewhere. > > I have noted that a large number that political party's members seem to be > quick to label those that disagree with some its policies and positions as > either the enemy or disloyal. Perhaps it is an attitude "I will do what I > want, and if you disagree with me, then you are some sort of commie scum," > that has resulted in them not following advise offered to them, so that they > don't look like a bunch of spammers taking a bump all over everyone's inboxes. > > .. I really don't know, but I tend to discount the belief that this is a > conspiracy against them. > > > SgtChains > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
> On 25 Jul 2022, at 15:49, Luis E. Muñoz via mailop wrote: > > On 24 Jul 2022, at 4:38, Laura Atkins via mailop wrote: > >> We’re trying to pull ‘what to do with a completely different message that >> might be sent in the future, possibly by a completely different sender' out >> of a signalling system that was never designed to convey that signal. And, >> yes, even the eSMTP codes RFCs are about this message in this SMTP >> transaction. They don’t convey what to do with future mail, either. > > This poses a (perverse?) choice on the sender side. > > In the current state of affairs, ESPs presume they know more than the > receivers, so they keep trying to send. Since the ESPs essentially disregard > the 5xx codes using the line of reasoning that you described, The ESPs are not disregarding the 5xx. They’re actively respecting it, and not attempting a second delivery of the message that received the 5xx. laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
> On 23 Jul 2022, at 20:34, John Levine via mailop wrote: > > It appears that Bill Cole via mailop > said: >> If only we had a framework for error codes in SMTP that carry useful >> semantics... > > We do. That's what the enhanced error codes are for. See RFCs 1893 and > 5248. A lot of them are quite informative, e.g. 5.2.2 mailbox full, > 5.7.13 user account disabled, 5.5.3 too many recipients, or > 5.7.28 mail flood detected. You both missed my point. The RFCs in question both discuss about disposition of the message currently being attempted. None of the semantics involve what to do with future mail to that address. Part of the problem here is we’re trying to apply semantics that not only do not exist they were never intended to exist in the current framework. As I once explained it as part of a deposition (and this is a very short excerpt) to lawyers and judges the following way: Bounce handling is like calling a receptionist that is only allowed to say three things when you ask to speak to someone at their company. 2xy “Yes, I will put you right through.” 4xy “I cannot put you through now, try to call back about this issue later” 5xy “I cannot put you through now and won’t unless you do something different” That’s it. It says nothing about whether or not the employee is still there. It says nothing about whether or not the employee is the right one to talk to. It says nothing about whether or not the employee even works there any longer. It’s simply a Yes, No, Maybe regarding the call (email) currently being attempted. We’re trying to pull ‘what to do with a completely different message that might be sent in the future, possibly by a completely different sender' out of a signalling system that was never designed to convey that signal. And, yes, even the eSMTP codes RFCs are about this message in this SMTP transaction. They don’t convey what to do with future mail, either. > Recipient systems don't have a whole lot of incentive to provide those codes > because they correctly believe that most senders will ignore them, and some > senders will use them to try to game their filters. And many recipient systems don’t have enhanced SMTP codes at all. Yahoo doesn’t, for instance. Mimecast handles a lot of SMB mail and they don’t provide them, either. A bunch of the German mailbox providers don’t provide them. In fact, I’d say that eSMTP codes are the exception, not the rule. At the risk of derailing the conversation by providing actual facts and numbers: Client 1 B2B list: short excerpt of bounce logs. 882 entries, 734 do not have eSMTP codes (84%) . Client 2 B2C list: short excerpt of bounce logs. 141,142 entries. 116,243 do not have eSMTP codes (82%) These are two random bits of bounce logs I picked (mostly because they were a B2B client and a B2C client and their logs are loaded in my OpenRefine instance). Honestly, it’s even lower than I thought. I was going to say only 40 - 60% of bounces had eSMTP codes. But apparently I was overestimating. laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
> On 23 Jul 2022, at 05:18, Bill Cole via mailop wrote: > > On 2022-07-22 at 12:45:18 UTC-0400 (Fri, 22 Jul 2022 12:45:18 -0400) > Luis E. Muñoz via mailop > is rumored to have said: > >> On 22 Jul 2022, at 11:49, Laura Atkins via mailop wrote: >> >>>> This would allow the ESP to quickly "fail" the API request to send to that >>>> email address. There are other metrics that could be tied into those >>>> addresses and used to provide a more expedite response to the caller, >>>> which incidentally would also help deter abuse. >>> >>> In many, many cases the issue is that other customers are mailing to the >>> same address - and just because an address bounces for X sender doesn’t >>> mean that it shouldn’t be mailed for Y sender. One clear example is when >>> senders push individual user blocks out to the SMTP transaction. >> >> I question your assertion that "bounces for X sender doesn’t mean that it >> shouldn’t be mailed for Y sender". If recipient R has a history of blocking >> many senders, continuing to send from other senders is not worth it in the >> long run for the ESP. Just as receivers reject with errors such as "this >> account is receiving email at a rate that...", the ESP could respond to its >> client with "this receiver has a history of bounces / rejections / >> complaints that is incompatible with our policies...". > > If only we had a framework for error codes in SMTP that carry useful > semantics... I agree, it would have been nice if the authors of 821 and 822 had considered this use case and provided us with semantics. Unfortunately, the semantics described in those RFCs (and their successors) only talk about what to do with the message that is rejected. There are no semantics or recommendations about what to do with future messages to the addresses that failed to accept the mail. And on the receiving side it’s not much better. All too many receiving mailservers don’t use the codes specified in the RFCs and decide to use their own implementation. A very large ISP, for instance, uses “451 this message will never deliver” as part of their repertoire of bounces. Another widely used filter rejects everything with 571 5.7.1 and in order to determine what the problem is, the sender needs to visit a webpage to search for a specific code in the text string of the bounce. Again, anyone saying this is simple doesn’t understand the complexities involved at scale and hasn’t thought about the implications of what they’re asking senders to do. Consider the case where Microsoft spits out a incorrect and false 550 user unknown (which happens every couple years). What you’re suggesting is that when this happens the next time, Gmail block every gmail user from ever sending to those hotmail users at any point in the future. That’s what you’re asking for. Unfortunately, it doesn’t take into account the actual realities of sending at scale. This is actually a problem, one I’m working with various folks in the industry to address in a way that preserves the functionality of email. I’m probably going to step away from this discussion now, though. There’s nothing being suggested here that hasn’t been tried and failed in the past. -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
> On 22 Jul 2022, at 16:02, Luis E. Muñoz via mailop wrote: > > On 22 Jul 2022, at 6:31, Laura Atkins via mailop wrote: > >> I’m agreeing there is a problem with ESPs and have said so to ESPs >> individually and as a group over the last few weeks. > > Something that I don't see mentioned often enough and that would help, is to > retain records of bounces—even of hashed email addresses vs the bounce. That’s normal practice as far as I’m aware. If an address bounces the ESP prevents the sender from mailing to it in the future. There are some ESPs that don’t (and they know how I feel about their practices). I’ve also heard complaints from ISP representatives about ESPs that do this and make it impossible to troubleshoot why their customer isn’t getting the mail they asked for. > This would allow the ESP to quickly "fail" the API request to send to that > email address. There are other metrics that could be tied into those > addresses and used to provide a more expedite response to the caller, which > incidentally would also help deter abuse. In many, many cases the issue is that other customers are mailing to the same address - and just because an address bounces for X sender doesn’t mean that it shouldn’t be mailed for Y sender. One clear example is when senders push individual user blocks out to the SMTP transaction. This is another “simple” solution that demonstrates a significant lack of understanding of how bulk email is sent. laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
> On 22 Jul 2022, at 12:22, Simon Arlott via mailop wrote: > > On 22/07/2022 10:21, Laura Atkins via mailop wrote: >>> After that there should be an integrated opt-in process to verify any >>> new email address for that ESP customer's list. >> >> While this sounds simple and like a no-brainer, it doesn’t account for how >> complex many companies email programs are. In many, many cases full customer >> data isn’t kept at the ESP - nor should it be. The ESP doesn’t need to know >> (and in fact absolutely shouldn’t know) things like credit card numbers or >> login passwords. There are also a number of systems that don’t keep email >> addresses at all. Mail is triggered through an API call and all of the email >> addresses are stored on the sender’s system, “lists” never go near the ESP. >> All the ESP sees are send requests. > > At no point did I suggest the ESP needs to receive more than the email > address? You didn’t say it, no. But that’s what your comment "It should only be possible to import addresses from a list once or twice, not on a regular basis” leads to. That’s what I meant by “it sounds simple but it’s not.” The “simple" solution you're suggesting cannot work because it doesn’t address the reality of how bulk email is handled. The only practical way to not upload addresses on a regular basis is to keep all customer data at the ESP and build your entire customer database around the ESP. Otherwise, you’re going to need to import addresses on a regular basis. On a practical level, say you want to send email to users that have purchased a particular product because that’s been recalled. Either, the purchase data needs to be inside the ESP or the list of users who have purchased that product needs to be updated. Or, you want to send email to users that have opened your application in the last month. Either you need to have that data inside the ESP or you need to upload the list of users to the ESP on a regular basis. > Only the email verification message needs to go through the ESP. It > could insert a confirmation token in a URL that the ESP customer then > presents to confirm opt-in for that ESP account. The user experience is an issue here. I have multiple big senders who use 2 or even 3 different ESPs - typically for different types of messages. Are they supposed to confirm the email address through each ESP individually? Is that a reasonable process to expect to happen? > None of this prevents PayPal, banks, etc. from operating. It also > doesn't prevent online shops from operating but it does complicate the > process of receiving a receipt if that normally comes direct from the > payment processor because all messages would need to use the same ESP. My point exactly. And expecting people to confirm every source of email independently is not a solution. > There's just a conflict of interest between "people pay us to send > email" and "people who pay us nothing don't want to receive that email”. You’re forgetting another group: People who pay us nothing want to and expect to receive this email. One of the most challenging bits of email filtering is dealing with emails that are wanted by some recipients and are unwanted by other recipients. This isn’t a new concept at all, it’s a problem that I remember having discussions with JD about back when he was at Y! (and he’s been gone for more than a decade at this point). laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
> On 22 Jul 2022, at 11:13, Slavko via mailop wrote: > > Ahoj, > > Dňa Fri, 22 Jul 2022 10:21:44 +0100 Laura Atkins via mailop > napísal: > >> ESPs have many, many problems, but the fixes being suggested here on >> mailop are overly simplistic and evidence a lack of conceptual >> understanding of how bulk email is sent in 2022. > > Sure, complex things has complex problems, no doubts. > > But IMO the right question is: > > "Are (big) ESPs interested in its (as sender) reputation at all?" I’ll point out, this isn’t an ESP only problem. Two of the biggest sources of spam right now are O365 and Google IP addresses. They are actually a bigger problem in my (mostly unfiltered for reasons) inbox than any ESP. I’m agreeing there is a problem with ESPs and have said so to ESPs individually and as a group over the last few weeks. The ESPs are interested in sender reputation. But, in this context, reputation means “Our mail gets accepted at the ISPs”. In that context their reputation is fine. They’re not being blocked. Specific customers may have delivery problems, but a lot of the modern machine learning filters are very good at blocking the problem customers without blocking the good ones. laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
>>> The basic problem is allowing an ESP customer to import a list that >>> existed before the customer became a customer of this ESP. I can't >>> think of an ESP that would not allow that. >> >> I saw this again as someone replied to it. >> >> Sadly, there is at least one legitimate reasons to allow this: >> how else could a customer change ESP ? > > It should only be possible to import addresses from a list once or > twice, not on a regular basis. > > After that there should be an integrated opt-in process to verify any > new email address for that ESP customer's list. While this sounds simple and like a no-brainer, it doesn’t account for how complex many companies email programs are. In many, many cases full customer data isn’t kept at the ESP - nor should it be. The ESP doesn’t need to know (and in fact absolutely shouldn’t know) things like credit card numbers or login passwords. There are also a number of systems that don’t keep email addresses at all. Mail is triggered through an API call and all of the email addresses are stored on the sender’s system, “lists” never go near the ESP. All the ESP sees are send requests. There are opt-in processes that don’t involve “signing up for a list” as well. You register an account with PayPal, or your bank, or whatever. Yes, those organizations should (and many do) have verification processes in place. But that should be handled by the data controller, not the ESP. ESPs have many, many problems, but the fixes being suggested here on mailop are overly simplistic and evidence a lack of conceptual understanding of how bulk email is sent in 2022. laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Did Google become stricter about RFC 5322?
> On 13 Jul 2022, at 09:07, Philip Paeps via mailop wrote: > > On 2022-07-13 15:31:17 (+0800), Philip Paeps via mailop wrote: >> In the past couple of days, I'm seeing an uptick in rejects from Gmail as >> follows: [...] >> >> As far as I can tell, the message is compliant. It doesn't have any of the >> obvious problems, at least. From, To, Message-ID and Date are supplied. No >> duplicate headers. > > It turns out there was, in fact, a duplicate Date: header. Sigh. I am > blind. I was looking for duplicate To: headers, which are a lot easier to > introduce. I wonder how that happened. > > Apologies for the noise. > > (Still wondering if Google has gotten stricter though... As far as I know, > this commit mail script hasn't been touched in a very long time. Though I > won't exclude the possibility of something else in the mail pipeline having > changed.) There are currently quite a number of anecdotal reports that Google is moving towards rejecting more email that doesn’t comply with their interpretation of the standards. This includes 5321/2 and the authentication standards. laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [EXTERNAL] Re: Moving email server to new IP
s://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist.mailop.org%2Flistinfo%2Fmailop=05%7C01%7Cjdellapina%40microsoft.com%7C4d57fb54ed3a48c5630208da6049a450%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637928166673653439%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=3b9gAgZIWj8ODrYNPyNPXjS5cyTFKH%2FsDHogtAisxHo%3D=0>___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Interesting question from a team member, MX chaining, list-manage.com
> On 1 Jul 2022, at 10:00, Paul Smith via mailop wrote: > > On 01/07/2022 09:52, Laura Atkins via mailop wrote: >> >>> It has a single MX record pointed at: >>> >>> mail.admin.mailchimp.com <http://mail.admin.mailchimp.com/> >>> >>> That hostname exists, but it doesn't have an A RECORD. >> >> Again, what’s the problem? Not every mailserver needs to have a >> corresponding website. > Normally, an MX record would point to an A record. > Yeah, I get it now. I thought the complaint was about domains not having websites. I missed the chained MXs. > A records are not exclusively for websites, they have many other uses. For > instance, *ALL* mail servers intended for incoming mail using the standard > SMTP system must have an A record pointing to them. > > Without an A record here, mail to b...@list-manage.com > <mailto:b...@list-manage.com> has nowhere to go. > Which is fine because there are no email addresses in that domain. > f you don't want to accept mail for a domain, usually, you'd accomplish that > by simply not having an MX record. Having an MX record which points nowhere > is odd, but not illegal - it just means that mail is undeliverable. > Understood. >>> It in turn has just a single MX Record. >>> >>> inbound-mx1.mailchimpapp.net <http://inbound-mx1.mailchimpapp.net/> >>> >>> Kind of a strange MX delegation.. I assume to avoid CNAME's >>> >>> But it does seem very strange. Comments anyone? I didn't have an answer >>> for him.. >> >> What’s so strange about it? > 'mail.admin.mailchimp.com' having an MX record is fine, it means that mail to > 'b...@mail.admin.mailchimp.com <mailto:b...@mail.admin.mailchimp.com>' has > somewhere to go. > > But it doesn't mean that mail to 'b...@list-manage.com > <mailto:b...@list-manage.com>' has anywhere to go. You can't chain MX records > like that. > Right. I missed that point. Thank you for clarifying. laura___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Interesting question from a team member, MX chaining, list-manage.com
> On 30 Jun 2022, at 22:00, Michael Peddemors via mailop > wrote: > > I know this doesn't look professional, but the question from the team member > does this contravene any rules or best practices. > > list-manage.com > > This domain does not have any A records. If there’s no website it doesn’t need an A record. Given how that particular domain is used there isn’t a lot of reason to host a website there. > It has a single MX record pointed at: > > mail.admin.mailchimp.com > > That hostname exists, but it doesn't have an A RECORD. Again, what’s the problem? Not every mailserver needs to have a corresponding website. > > It in turn has just a single MX Record. > > inbound-mx1.mailchimpapp.net > > Kind of a strange MX delegation.. I assume to avoid CNAME's > > But it does seem very strange. Comments anyone? I didn't have an answer for > him.. What’s so strange about it? laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Looking for contact at iphmx.com
If you put iphmx into google, you get a clear statement in the first page of responses that says iphmx is controlled by Cisco. But the rejection message is telling you to contact the recipient - not the filter owner. laura > On 28 Jun 2022, at 11:09, Sidsel Jensen via mailop wrote: > > Hi > > I'm trying to locate a contact to mx1.hc1932.iphmx.com - does anybody know > who to reach out to? They don't respond through ab...@enom.com > <mailto:ab...@enom.com> (which was the only address whois showed as > everything else was heavily redacted) > > I'm trying to solve a deliverability problem towards them: > > host mx1.hc1932.iphmx.com[216.71.154.96] refused to talk to me: > 554-esa6.hc1932.iphmx.com 554 Your access to this mail system has been > rejected due to the sending MTA's poor reputation. If you believe that this > failure is in error, please contact the intended recipient via alternate > means. > > I guess mailop applies as "alternate means" ;-) > > Kind Regards, > Sidsel Jensen > > Architect of Deliverability and Abuse @ Open-Xchange > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Microsoft Announces Tenant Trusted ARC Seal
> On 20 Jun 2022, at 18:05, Al Iverson via mailop wrote: > > I didn't really "get" ARC when it comes to mailing lists, there seems > to be little point, as I felt that most people already dealt with > mailing lists under DMARC via header rewriting. Header rewriting is awful if you’re using search to try and find that message someone sent and you want to respond to or refer to. Header rewriting is awful when you’re on multiple lists with many of the same participants and you know X wrote something on one of them but you can’t remember which list and you’re trying to search for it, but can’t find it. Or when there’s an invite for an event from someone that went to a list and, again, you don’t remember which list and can’t find it. There are also lists which, for reasons, don’t set the original author in the reply-to, they keep the list as the reply-to. Sometimes folks contribute to the list, but don’t sign their messages or have anything resembling a .sig file. If you’re on a list like this with two of those people you don’t always know who you’re talking to. Header rewriting is a bad hack, but it happened faster than the IETF process so we’re basically stuck with it. It’s neither a clean solution nor a good one, IMO. laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Microsoft Announces Tenant Trusted ARC Seal
> On 19 Jun 2022, at 20:22, Dave Crocker via mailop wrote: > > It occurred to me that it might help for me to provide more context to the > questions I asked. I was possibly relying too much on the thread context... > > > On 6/18/2022 3:40 PM, Noel Butler via mailop wrote: > >> I was a very early (even in testing) user of SPF, It's rather commical >> reading these FUD sayers about SPF and mailing lists, it has never been a >> problem with mailing lists, not using mailman nor its more common >> predecessor majordomo, and I've never noticed anything wrong with qmail >> users ezmlm. > > This establishes the context of SPF and mailing lists. Hence my question. > > Also, the above text makes the incorrect assertion that this isn't a problem > when a message passes through a mailing list. However, SPF breaks even with > basic MTA relaying, nevermind mailing lists -- unless the MTA is registered > in the SPF record. The delivery/re-post behavior of mailing lists not only > breaks SPF but almost always also breaks DKIM. (This latter point is what > motivated ARC.) Most modern mailing lists rewrite the 5321.from by default so they can bounce handle. I don’t think SPF breaks mailing lists as much as folks claim. I have heard, and in the past made, the “SPF breaks mailing lists” but I stopped saying it because it’s not true in the vast majority of cases. For instance, the 5321.from on this list is boun...@mailop.org <mailto:boun...@mailop.org>. Looking at other lists in my mailbox it’s similar. Mailing lists rewrite the 5321.from and thus does not break SPF. It does break DMARC, but that’s another discussion. laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Help with identifying invalid email domains
Given that DuckDuckGo is in the business of forwarding email, they MUST use confirmed opt-in to avoid having someone mistype an email address. It’s not just the domain part that’s in consideration here, they need to ensure that typos don’t happen on the left hand side as well. I’d argue that typos on the LHS to different are a bigger problem than the occasional hit to a spamtrap as they’re forwarding PII to the address. laura > On 26 May 2022, at 10:21, Ken O'Driscoll via mailop wrote: > > Hi Omid, > > If you are specifically looking to reduce domain related typos on user input, > then you can use a project such asTypofinder > <https://github.com/nccgroup/typofinder>. They also have a commercial > offering. > > Alternatively, you could also look at implementing an address validation > services. Most will do the same thing (and more) but will already have it > wrapped up in an API for you to call. Validation can be a sketchy industry, > EmailHippo <https://www.emailhippo.com/> and Kickbox <https://kickbox.com/> > are examples of two legitimate players. > > Ken. > > From: mailop mailto:mailop-boun...@mailop.org>> > On Behalf Of Omid Majdi via mailop > Sent: Wednesday 25 May 2022 20:00 > To: mailop_at_mailop.org_o...@duck.com > <mailto:mailop_at_mailop.org_o...@duck.com> <mailto:mailop@mailop.org>> > Subject: [mailop] Help with identifying invalid email domains > > Hey all, > > I'm looking to see if anyone has compiled any lists of invalid email domains? > Examples of such would be typo domains and/or domains that accept all > local-part addresses such as gmai.com <http://gmai.com/>, gmail.co > <http://gmail.co/>, googlemai.com <http://googlemai.com/>, or proton.com > <http://proton.com/>. If there's any resources someone could share for known > invalid domains that would be incredibly helpful. > > Thanks, > Omid Majdi > Product Lead > DuckDuckGo, Inc. > ___ > mailop mailing list > mailop@mailop.org <mailto:mailop@mailop.org> > https://list.mailop.org/listinfo/mailop > <https://list.mailop.org/listinfo/mailop> -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Does anyone know, how operates h-email.net email service?
According to the wayback machine that domain has been redirecting to swisshost.ch <http://swisshost.ch/>’s “domain for sale page” since at least December 2014. There’s an earlier crawl in mid-2014 that looks like it might be a real domain. laura > On 29 Apr 2022, at 14:16, Benoît Panizzon via mailop > wrote: > > Hi List > > Privacy Policies make it hard for us to solve the email issue of one of > our customers. > > schlageropenair.ch mail is handled by 5 mail.h-email.net. > > It looks like the MX was recently changed. > > Our customer has an email account on that domain that was 'sponsored' > for an event. Unfortunately the owner of the domain is not known to > our customer and he can not access his email account any more. > > Furthermore, we get spam reports from Netcraft UK, when sending emails > to the account in question. So somebody is reading those emails (or > using the domain as spamtrap). But Netcraft does not reply to any > attempt to contact them by email. > > I have contacted the registrar openresolver. I have contacted the > Hoster Parkingcrew. > > Both tell me, they can neither reveal who their customer is, nor pass > on a message. > > I supposed, the domain was put for sale and a grabber might have > acquired it. > > So I contacted nic.ch. They confirm that there was no owner change of > the domain. But same privacy: They can not reveal the owner or pass on > a message. > > Knowing it was a sponsored domain. I checked with our customer, who the > sponsors are and contacted all of them. All confirmed, not being the > domain owner. > > So the last option I wanted to try, is contact the operator of the MX > receiving the emails. Hosted on AWS, so contacting Amazon is useless. > > Unfortunately h-email.net has no website, is registered anonymously, has > DNS server operated by GoDaddy. Useless going down that rabbit hole. > > schlageropenair.ch descriptive text "v=spf1 ip6:fd1b:212c:a5f9::/48 > -all" > h-email.net descriptive text "v=spf1 ip6:fd96:1c8a:43ad::/48 -all" > > unfortunately ip ranges that are not announced, and not registered > with any IP registry. > > Does anyone know, if h-email.net also operated by GoDaddy? Or does one > know who operates that h-email.net email service? > > -- > Mit freundlichen Grüssen > > -Benoît Panizzon- @ HomeOffice und normal erreichbar > -- > I m p r o W a r e A G-Leiter Commerce Kunden > __ > > Zurlindenstrasse 29 Tel +41 61 826 93 00 > CH-4133 PrattelnFax +41 61 826 93 01 > Schweiz Web http://www.imp.ch > __ > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] $GOOG
> On 15 Apr 2022, at 18:29, Luis E. Muñoz via mailop wrote: > > > Dnia 15.04.2022 o godz. 16:53:11 Laura Atkins via mailop pisze: > > "EU.org, free domain names since 1996” > > You quoted that. Eu.org is a *domain registrar*. Only. They don't offer any > email service and never did. So how can they "police users for email"? > > Do you know any paid domain registrar - for example for .com domain - that > "polices users for email", if they don't host any email for the user? > > There are many who claim that there's a correlation between easily, cheap (or > free) domain names and spam. Their rationale is that spammers can secure > disposable domain names for very low price. > > Therefore, they claim, domain names meeting that criteria need to be > subjected to additional scrubbing. Less sophisticated receivers could simply > opt to reject while providers with more sophisticated mechanisms could > implement that "additional scrubbing" in the form of tighter tolerances, > starting the "reputation calculation" from a lower value or whatever makes > sense to them. > > Their common goal according to this narrative, is to reduce the amount of > spam these mailbox providers have to deliver to their products/clients. > The most recent Spamhaus botnet update report addresses this very nicely and provides direct evidence that free domain registrations are heavily abused. https://www.spamhaus.com/custom-content/uploads/2022/04/Botnet-Report-Q1-2022.pdf <https://www.spamhaus.com/custom-content/uploads/2022/04/Botnet-Report-Q1-2022.pdf> "A more detailed review of our data reveals that the majority of fraudulent domain registrations within Freenom’s TLDs are not linked to highly advanced and sophisticated threat actors, but users of freely available crimeware kits that they have bought for a few bucks on the dark web. These somewhat “amateur” threat actors do not have the same financial resources as more “professional” cybercriminals. Therefore, it is no surprise that they try to (ab)use services that are available for free – such as Freenom offers.” Spamhaus ultimately concludes that section: "It’s evident that where there’s a freebie, there’s abuse!” laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM by the third party
A major reason many ESPs double DKIM sign is because two major providers (Google and Yahoo) will only provide compliance data (FBL in the case of Yahoo and access to Google Postmaster Tools in the case of Google) based on DKIM. While it is possible to have customers (or register for customers), it is time consuming and does mean that truly bad customers can simply remove access to those compliance metrics. I do know one major ESP that didn’t double DKIM sign and my understanding is that it took more than 6 months to get access to all their customers’ Yahoo FBLs. I don’t know if they cared enough about GPT to set that up. laura > On 21 Apr 2022, at 23:28, Brandon Long via mailop wrote: > > Generally speaking, adding a dkim signature to your message adds a "source" > anchor, something that ties a message to other messages. > > For us, this means another reputation in addition to things like IP address, > IP range, ASN, SPF domain. We do rank signatures when there are > multiple ones, ie for whether or not they are "test" signatures, the strength > of the key, and how well it matches the from header domain. > > Whether that helps you or not will depend on the reputation of the DKIM > domain. If I was a third party smtp server, I would only DKIM sign messages > we > a shared domain if I had a reasonable belief that the messages are non-spam. > One could even assign different signatures depending on how spammy > the message is, or how new the customer is, or other metrics (similar to how > one might use separate IP pools for different types of customers). > > If one does have a high value DKIM domain, then one should be very careful > about signing relayed messages. One could imagine only signing > outbound mailing list messages if the inbound message passes spam check and > is authenticated already... don't add auth to something that wasn't > authed, for example. This is doubly true for mail which has a from address > which matches what you're going to sign for, you don't want to relay a forged > message that isn't auth and add auth to it. > > As for receivers, phishing and spam evaluation are similar but not identical, > especially if you're looking for spear phishing. How you use the signals will > vary for those use cases... and an unmatched auth domain is definitely a > lesser signal when it comes to phishing. > > There's also the resurgence of dkim replay spam, which means that > non-matching spf/dkim domains are more likely to be penalized now.. or one > could even > "learn" the IPs for a given dkim domain and "usual" IPs may do better than > "unusual" IPs in that case. > > It's complicated. > > Brandon > > On Wed, Apr 20, 2022 at 7:09 PM Henrik S via mailop <mailto:mailop@mailop.org>> wrote: > Hello > > My mail is sent by the third party smtp server, and the dkim signature > is made for the third party domain (for this case, it's pobox.com > <http://pobox.com/>). > > does this DKIM have helps to the authorization of my outgoing messages? > > Thanks > ___ > mailop mailing list > mailop@mailop.org <mailto:mailop@mailop.org> > https://list.mailop.org/listinfo/mailop > <https://list.mailop.org/listinfo/mailop> > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Odd delay at Gmail ?
> On 20 Apr 2022, at 16:44, Cyril - ImprovMX via mailop > wrote: > > Thank you all. > > About Laura's question, I can confirm that on our end, we successfully > forwarded the message with a 2XX response from Google within a few seconds. > Our timestamp show that this user should have received the email 8 hours > before he really received it. How was he accessing the mail? Was he using an IMAP client or one of the Google controlled MUAs? Like, I’m wondering if this was just a display issue (say: Google won’t display mail until the actual timestamp) or if Google really held onto the mail somewhere in a spool until the timestamp was accurate. It seems weird to me that Google would sit on an email for exactly 8 hours and then deliver it to him. But it seems not-unreasonable to me that Google would have their client set to not display email until after it was delivered (and because of the timestamp issue it wasn’t ‘delivered’ for 8 hours. But an IMAP client that isn’t under the control of Google will display the message if it’s in the inbox, no matter if it was delivered yet or not. laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] FYI - Google/Gmail hard enforcing SPF presence
> On 19 Apr 2022, at 18:53, Tim Düsterhus via mailop wrote: > > On 4/19/22 16:57, Laura Atkins via mailop wrote: >> We just did 2 tests, one with an email that violated half a dozen best >> practices and one that has a SPFSoftfail (with no DKIM). > > I believe you accidentally pasted the same test twice, the headers look 100% > identical to me. Oops. Really badly formatted email: Delivered-To: wttwla...@gmail.com Received: by 2002:a05:6a20:54a6:b0:7d:b75e:81cc with SMTP id i38csp2956940pzk; Tue, 19 Apr 2022 07:44:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJznmP9P9y29YlGiaLzZTxw0NXW8HUbBKmVBAeegvyAXSFlmXFYoYl/b2Xkgh7yVLnt6UuK7 X-Received: by 2002:a5d:6d03:0:b0:20a:7af0:380f with SMTP id e3-20020a5d6d0300b0020a7af0380fmr11823278wrq.148.1650379498973; Tue, 19 Apr 2022 07:44:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650379498; cv=none; d=google.com; s=arc-20160816; b=oAA3r/bEkAyRjN7ZL7C2R9PNSNlehAqTYFpiww5W9ojBBIcPeXwmLRZiMZr3B/Ug5d BiJezi7mylKI+UO2ywcAG7h1jmTAeizH3j1ghCzukMp2uh3w3oHZ64R+3JAAajACtRcH lc1BkI/RLdsj7uv7tU3ECElQPX80PC1/hPzxYzc8Si/U761BLX3gVgK+QBeie1HX81JO HJFtAqVxp/AaVFH4qZuScWJGC23wN5C2Q0pNIytEAc3xk2momvTNrNvYERAqPlYfz32c 9Li7Yh330SYhCfGwNrCM0tWZJN7/G9YFDPRyWbWh8j71Xqnx3M7XiNrXGPIbcBrvpoNw INbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=message-id:subject:from:to:date; bh=ecGWgWCJeWxJFeM0urOVWP+KOlqqvsQYKOpYUP8nk7I=; b=P1PMZlNCzI7TENQ2QO8kaSWDTckbB3jDkrrzxUbjxzgJ/SfGFjHSJpyFttLPHKnatk pTDj/P5r07tRG7lQ4msWgKZocbyj3y5j6ZNqWRgs189MgDCAb1u533ZJlmRyzWZi2n/3 u50p14IatncLBfPrcxOwMACDBzPRd8P2h72VGcG5V9cRz27WziJmVOxtVEUJk5Hd+c2Z KoQ+Uzf/lRkGwcKo0MDcQ6qMG3swCdMioHmG4N26/VVOBSNDVbRJZ4J0KR+4TZNO4NlT gZZKMuWeQvr54C+rtg8ht/OekVrhbksGrKWNoicG78FwORNoUINzJVMAdxhVAWzvWAPq Vv2g== ARC-Authentication-Results: i=1; mx.google.com; spf=neutral (google.com: 185.97.236.152 is neither permitted nor denied by best guess record for domain of steve@sliver) smtp.mailfrom=steve@sliver Return-Path: Received: from sliver ([185.97.236.152]) by mx.google.com with ESMTP id p7-20020adfe60700b00203e90194c2si8108892wrm.582.2022.04.19.07.44.58 for ; Tue, 19 Apr 2022 07:44:58 -0700 (PDT) Received-SPF: neutral (google.com: 185.97.236.152 is neither permitted nor denied by best guess record for domain of steve@sliver) client-ip=185.97.236.152; Authentication-Results: mx.google.com; spf=neutral (google.com: 185.97.236.152 is neither permitted nor denied by best guess record for domain of steve@sliver) smtp.mailfrom=steve@sliver Date: Tue, 19 Apr 2022 15:44:58 +0100 To: wttwla...@gmail.com From: steve@sliver Subject: test Tue, 19 Apr 2022 15:44:58 +0100 Message-Id: <20220419154458.051019@sliver> X-Mailer: swaks v20201014.0 jetmore.org/john/code/swaks/ This is a test mailing One that mostly conforms to the RFCs. Delivered-To: wttwla...@gmail.com Received: by 2002:a05:6a20:54a6:b0:7d:b75e:81cc with SMTP id i38csp2961601pzk; Tue, 19 Apr 2022 07:50:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzdelAB/vcgsTFh7OdsgiN0lLCP24pEqpJQB3u5+BeRw0wJWFERr07eWGD1nqmfVWBYzp/g X-Received: by 2002:adf:f943:0:b0:203:b456:c71d with SMTP id q3-20020adff94300b00203b456c71dmr12103183wrr.568.1650379836971; Tue, 19 Apr 2022 07:50:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650379836; cv=none; d=google.com; s=arc-20160816; b=u9bUGGpAm++qienOOtsdojZxEDHIcDQA2kuYs40BSeleAFtgg/mekwNjXxz0MzGQ/w a51PSfokRCPDxcDKgcOU7TdlSIVHI4elF1fAKLwHDzwYQfAUZS7zRumHYQ89qD0JqKPm b0Ua3iEgDbDEHZEdUZJmEnh7MojFMh7LSu/jM38+mq/rWyneDhZwXFDuaHza7tfqYvNZ Vayo2fPrwDGYCxzPZFnU9phFhsU4owWslKy2cL9fQ8BHfA3RqSS2b6UOTFwYXoexp3GR ZdUPB4U/D/fD1+zZi7Pyk/FKxkXECzyMlzS0ltyOu813nqikPJu2w6PtrMBucFtz3sDq rxsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=message-id:subject:from:to:date; bh=ecGWgWCJeWxJFeM0urOVWP+KOlqqvsQYKOpYUP8nk7I=; b=0kz6ln2tXtO/lp0uY8fdTNdWTC//vgV8edm8edlqR9E1Glh4C9dIW1nN/GARf+bwZ7 5jqDTuQBbeeCeBa6f2h5Qa+/EnTscHcgATJtdC8Vlw8KCp1zbdIVPzBUdPzidAcx0GdO Dzt+TpkZAHsmT32xR47of9FRroHppwyyMYfDkgPTIiMQNdwi5k6v7QfCu39SGML3v9LO fLzrohKxQ3C2fXzxM6E3S/AzbGZEDC4Dp8PValm2ijSirasPxiseExlquViTXf3kf2M+ NMtk2A5Ozs2ySwLj+SGzA81n8SbqaHneLBetFjou5aqy0Ty3hZrzht9Z3yo9bYDeySGA lhyw== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning st...@wordtothewise.com does not designate 185.97.236.152 as permitted sender) smtp.mailfrom=st...@wordtothewise.com Return-Path: Received: from m.wordtothewise.com ([185.97.236.152]) by mx.google.com with ESMTP id c8-20020adffb4800b00206174b2125si8483775wrs.338.2022.04.19.07.50.36 for ; Tue, 19 Ap
Re: [mailop] FYI - Google/Gmail hard enforcing SPF presence
On 19 Apr 2022, at 16:11, Michael Peddemors via mailop wrote: > > And we also see that they have not yet 'hard enforced', but it looks like > some trigger on a domain results in requiring SPF for that domain. It wouldn’t surprise me if there were some triggers that made authentication be looked at harder. But it is demonstrably incorrect to say that Google is requiring certain types of authentication for delivery. > Of course, we don't expect Google to reveal their secrets, but we can assume > things like new IP(s), new domains, sudden traffic surges, or customers > clicking on 'this is spam' all might cause the requirement for SPF on a > certain domain. This was a brand new IP without any rDNS (ie, it’s not intended to send mail). I do expect volume plays into it. But, as I’ve been saying: Google’s filtering is nuanced and tries to do the right thing most of the time. laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] FYI - Google/Gmail hard enforcing SPF presence
LBfPrcxOwMACDBzPRd8P2h72VGcG5V9cRz27WziJmVOxtVEUJk5Hd+c2Z KoQ+Uzf/lRkGwcKo0MDcQ6qMG3swCdMioHmG4N26/VVOBSNDVbRJZ4J0KR+4TZNO4NlT gZZKMuWeQvr54C+rtg8ht/OekVrhbksGrKWNoicG78FwORNoUINzJVMAdxhVAWzvWAPq Vv2g== ARC-Authentication-Results: i=1; mx.google.com; spf=neutral (google.com: 185.97.236.152 is neither permitted nor denied by best guess record for domain of steve@sliver) smtp.mailfrom=steve@sliver Return-Path: Received: from sliver ([185.97.236.152]) by mx.google.com with ESMTP id p7-20020adfe60700b00203e90194c2si8108892wrm.582.2022.04.19.07.44.58 for ; Tue, 19 Apr 2022 07:44:58 -0700 (PDT) Received-SPF: neutral (google.com: 185.97.236.152 is neither permitted nor denied by best guess record for domain of steve@sliver) client-ip=185.97.236.152; Authentication-Results: mx.google.com; spf=neutral (google.com: 185.97.236.152 is neither permitted nor denied by best guess record for domain of steve@sliver) smtp.mailfrom=steve@sliver Date: Tue, 19 Apr 2022 15:44:58 +0100 To: wttwla...@gmail.com From: steve@sliver Subject: test Tue, 19 Apr 2022 15:44:58 +0100 Message-Id: <20220419154458.051019@sliver> X-Mailer: swaks v20201014.0 jetmore.org/john/code/swaks/ This is a test mailing > > > Regards, > Bernhard > > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Office 365 Different Hop Count Exceeded
Content filters on the final destination domain rejecting the mail in a way that isn’t a permanent failure. Laura Sent from my iPhone > On Apr 18, 2022, at 9:49 PM, Mike Hammett via mailop > wrote: > > > Reported error: 554 5.4.14 Hop count exceeded - possible mail loop > ATTR34 [BN1NAM02FT041.eop-nam02.prod.protection.outlook.com] > DSN generated by: CH2PR18MB3414.namprd18.prod.outlook.com > > > I send an email from the same environment (my Zimbra server) to a forwarding > account in that environment through the same gateway (Proxmox Mail Gateway) > to the same platform (365). One set succeeds, while the other gives me the > above error. I've verified that the settings on the two forwarding accounts > are the same. The differences are that the failures are from a PBX to a > customer domain whereas the testing is from a mail client to our domain. > > What gives? > > One has 11 message hops to delivery, the other has 16 hops to failure. > > Any ideas? > > > > - > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] does ESP have the preference for email domains
> On 17 Apr 2022, at 23:57, wilson via mailop wrote: > > Hello > > some people told me not to use .xyz domain b/c it's more spammers liked. > may I ask if the big ESP or the open antispam policies have the preference on > domains? such as com/net/org is preferred, but xyz/top/pro is not. It’s a little more nuanced than that. Some of the ’non-standard’ domains have a huge amount of spam coming out of them. We were having a discussion about another TLD and one of the anti-spam vendors pointed out that of the mail they saw containing that TLD more than 90% was spam. They did not say they were blocking the TLD outright, though. It goes back to the spam filters as a bucket analogy. Every negative puts something in the bucket, every positive takes something out of the bucket. If the bucket overflows then mail is at risk. Using a not .com/.net/.org TLD can be a negative but that doesn’t necessarily mean all mail using it will be blocked. It just means you are starting with a slightly smaller bucket than you might have started with using a more standard TLD. It doesn’t mean that you’re going to have a huge problem. I have heard a lot of folks running systems (usually midsize or small) say they block all ‘weird’ TLDs on sight. I tend to recommend to clients that they stick with the standard ones. I’m not sure how extensive those blocks are, though. It just seems like an easy box to tick. laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] $GOOG
> On 18 Apr 2022, at 08:35, Vittorio Bertola via mailop > wrote: > > >> Il 15/04/2022 16:43 Laura Atkins via mailop ha scritto: >> >> All of the complaints I’ve seen about google track back to: the person was >> either actively sending spam (possibly unknowingly, but that doesn’t exactly >> reflect well on the sender) or they’re using a free service that is >> regularly used to send spam and they refuse to actually move to a service >> that doesn’t allow abuse. > Well, no. I have been running a personal VPS with a personal .eu email domain > for almost 20 years now, moving across a handful of major hosting providers > in Europe, and several times throughout this period Gmail started to reject > my mail without any clear reason to do so, even if I followed all the > instructions on their website. Usually it got better after a few months, also > without any clear reason. Without any clear reason you could see. That doesn’t mean they didn’t have a reason. >> No one is forced to use google as a recipient mail server and everyone who >> is using it made a choice to do so - either by moving their domain there or >> actively signing up for a gmail.com <http://gmail.com/> address. > This is also not entirely true. People are forced to get a Gmail account and > strongly encouraged to use it (for example, by defaults and preinstalled > apps) when they get an Android phone, or for a number of other reasons > related to other services. Having a google account != being forced to use it for email. > Also, people are told to get a Gmail account as a solution to their email > provider being unable to deliver to Gmail :) So, sure, Gmail offers good > service, perhaps the best among the free ones, but a good part of their > success is is due to their overall dominant market position. I do a LOT of work with lists of domains for clients. Part of that work is looking at what filters are handling mail. The process is simple: do DNS lookups on all the domains, do some classification of the underlying MXs and then rank them by who is handling the most mail / domains for the client. The data is pretty consistent across a wide range of clients. Google and Microsoft are the top, followed by Yahoo if the list is a consumer list, and Proofpoint if it’s a business list. Then another handful of domains - mimecast is a big one for both consumer and business users. What’s interesting is the difference when I’m looking at bounce logs. When clients send me logs, I do roughly the same thing - grab the domains, do MX lookups and the classify them. Google is rarely at the top of the list in those cases. So in terms of sending mail, Google handles maybe 30 - 40% of email. Microsoft handles slightly less, but still quite a bit, then about a dozen different and very recognizable filters. In terms of bouncing mail, the numbers are all over the place, but Google rarely enters into it. The biggest IP blocking problem I see is because mimecast uses spamcop. Spamcop seems to be randomly blocking a shared IP pool one of my clients is using and no one can tell me if it’s my client’s problem (which I can fix) or just the IP pool. My biggest problem with Google is actually some of their customers reach out to me about their domains having a bad reputation and wanting help. When I reply to them google puts my reply in their spam folder. (Lost a couple potential clients that way ‘your mail ended up in spam, so you clearly don’t know what you’re doing.’ The answer is pretty simple, though, when I remove their domain from the email it makes it to the inbox. Their domain reputation is that bad. I don’t think I’ve ever had Google actually block my VPS ever. I’m not saying it doesn’t happen, I’m just saying that it’s generally for a reason. Google doesn’t just throw up random blocks for no reason. We may not understand it, but that doesn’t mean it’s random. The claims that Google is somehow a monopoly and that they’re using blocking to force people to use their systems is based on conjecture. It is demonstrably false. They’re not aggressive in terms of blocking mail - there are folks who handle less mail than Google but block much more mail. laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] $GOOG
> On 17 Apr 2022, at 04:51, John Levine via mailop wrote: > > It appears that Paul Vixie via mailop said: >> srsly? do you really think changing one's domain name or ISP is a >> reasonable way forward when google isn't accepting one's e-mail? > > When your domain is a cruddy free one which has earned a poor > reputation, yes. As I have said a few times, sometimes free services > are worth what they cost. What’s remarkable here is that Google’s filtering is normally *incredibly* nuanced. They don’t deploy domain or IP level blocks by default or as a first response to a problem. There is an escalation path to their spam filtering. When they get to the point that they’re blocking IP addresses or domains, it means the operator has really, really screwed up for a long time. The times I’ve seen widespread IP / domain blocks include (but aren’t limited to): 1) There’s been ongoing abuse that the operator just ignored for months and months. No one noticed that mail from that operator was going to spam, and then no one at the operator noticed the short term blocks and notices in their logs. The system was running unmonitored and was being abused and finally Google just decided that the sender didn’t care if their mail was accepted or not and blocked it. 2) There’s something about the configuration or technical setup that is triggering google to determine that the current system isn’t run by someone who understands modern email standards. Note: these requirements are higher for mail over IPv6 than IPv4 because Google (and many other folks receiving mail) expect that if you’re technically progressive enough to send mail over IPv6 then you can implement authentication, set up FcrDNS, use a EHLO value that maps back to the sending IP, set up SPF for EHLO, use TLS, etc. 3) The provider one is using has a clear history of allowing problematic mail (may not just be spam, could be malware or whatever) from their customers. Google will block mail with any mention of that provider - in headers, rDNS of the connecting IP, body of the message, whatever. I’ve seen less of this recently, but I don’t think Google is going to have removed that particular tool from their box. As I tell my clients: it takes at least as long to repair a reputation as it did to break it in the first place. The reality is it can often take longer because there’s a lot of bad actors out there and no system can actually be trusted to send good mail all the time. Fundamentally, though, whether or not we like google’s rules and their filtering (or Spamhaus’ or the RBL or UCEProtect or any of the other hundreds of services that filter mail) yelling about it on a public mailing list isn’t going to get them to change their rules. The people who can make changes are the users of the service by pointing out the service isn’t meeting their needs. And I say that as someone who has actually gotten multiple providers over the years to change their filtering when it was legitimately blocking mail it shouldn't. It required a lot of work, a lot of data gathering, and an openness to dialog on all sides. laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] $GOOG
> On 15 Apr 2022, at 18:29, Luis E. Muñoz via mailop wrote: > > On 15 Apr 2022, at 12:50, Jaroslaw Rafa via mailop wrote: > > Dnia 15.04.2022 o godz. 16:53:11 Laura Atkins via mailop pisze: > > "EU.org, free domain names since 1996” > > You quoted that. Eu.org is a *domain registrar*. Only. They don't offer any > email service and never did. So how can they "police users for email"? > > Do you know any paid domain registrar - for example for .com domain - that > "polices users for email", if they don't host any email for the user? > > There are many who claim that there's a correlation between easily, cheap (or > free) domain names and spam. Their rationale is that spammers can secure > disposable domain names for very low price. > That wasn’t what I was claiming, honestly. what I was saying is that he doesn’t know what other folks are doing with eu.org <http://eu.org/>, yet he’s sharing reputation with absolutely everyone who is using that registration service. And that there’s a very low barrier to entry to getting a .eu.org <http://eu.org/> domain. And given the domain registration runs off donations and volunteers there’s likely no one actively policing the use of the domain. .eu.org <http://eu.org/> is, essentially, a tld. And .tlds have their own reputation, too. Just this week a few of us were talking about ‘weird’ tlds. One of the participants works at a filtering company, checked their stats and said “this particular tld is 9x% spam.” So 9+ times in 10 when they see a domain registered in that tld, it’s spam. Would you really hold it against that company, given the data they have, if they blocked all mail with that tld in it? Given that it’s 90+% guaranteed that tld is spam? What if 90+% of the mail in the .eu.org <http://eu.org/> tld is also spam? Does it make more sense to block mail containing that domain? Or are we just refusing to consider any domain based blocking at all? Filters generally make sense, but they often have access to data that we, as senders, don’t. Of course, that doesn’t mean the filters are always right. I’ve certainly been able to demonstrate that filters are wrong and get ISPs to stop using them. One of the times that stands out was a major anti-spam vendor was following on every link in an email - including the closed loop confirmation link - and then listing the COI-only IPs that sent mail after the confirmation. They refused to change what they were doing and continued to insist the only fix was to send COI mail. (How? you’re confirming your addresses want the mail and then listing it). We collected enough evidence that this was happening and shared it with the appropriate decision makers. The filter didn’t stop being stupid, but at least one of the cable companies using that particular blocklist stopped. I am pretty sure, though, that yelling on mailop has never convinced a filtering company to change their approach. laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] $GOOG
> On 15 Apr 2022, at 17:24, Bill Cole via mailop wrote: > > On 2022-04-15 at 10:43:13 UTC-0400 (Fri, 15 Apr 2022 15:43:13 +0100) > Laura Atkins via mailop > is rumored to have said: > >> Recipients have agency here and can move elsewhere for mail. The fact that >> they don’t tells me that google understands their userbase really well and >> does what they need to do to keep them happy. > > FWIW, I have some visibility into that and have seen a few small businesses > move their mailboxes from a boutique outsourcer to Google only to move them > soon afterwards to MS365. None the other way. I’ve seen a lot of folks moving, too. In these cases, though, it’s often the companies that are doing “cold outreach” are moving to Microsoft because their outbound filtering isn’t as good and Google is actually shutting down their senders (only for 24 hours and only when they’ve send their 1000 emails). The service providers in that space are also recommending MS rather than Google as they can send more. > Those decisions had everything to do with cost and end-user experience, never > about precision and fairness in spam control or transparent collaboration > with the email community. In my experience, deliverability into MS is worse > than into Google from the standpoint of a strictly no-spam sender only using > IPv4 for email. Totally agree here. MS are more aggressive with their filters, more opaque with their filters and will happily toss mail on the floor. It’s also a much harder process to fix problems once you’ve gotten into trouble there. But I’ve had clients who’ve done it there after months and months of cleaning up and consistent sending. laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] $GOOG
> On 15 Apr 2022, at 16:39, Grant Taylor via mailop wrote: > > On 4/15/22 9:09 AM, Jaroslaw Rafa via mailop wrote: >> How is my own VPS, that I pay for, that only I control and only I use to >> send mail "a free service that doesn't police users for email" ??? > > Your VPS doesn't sound like "a free service". But there is a chance that > your VPS is with a VPS provider that has a ... questionable reputation. -- > I speaking in the hypothetical as I've not looked. -- Thus you may be > suffering from guilt by association (with your chosen VPS provider). "EU.org, free domain names since 1996” laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] $GOOG
> On 15 Apr 2022, at 15:24, Al Iverson via mailop wrote: > > On Fri, Apr 15, 2022 at 7:41 AM Jaroslaw Rafa via mailop > wrote: >> >> Dnia 14.04.2022 o godz. 12:40:52 Al Iverson via mailop pisze: >>>> Yes, it is unfixable. Once Google's AI decides (for no apparent reason) >>>> that >>>> it will reject e-mails from you, or put them to recipients' spam folder, >>>> there's pretty much nothing you can do about it. >>> >>> That is false. >> >> I can believe your claim that "that is false" if you can give me a WORKING >> advice of what can I do to make my e-mails get to the Google's inbox. Other >> than "change your ISP" or "change your domain", as this is NOT A SOLUTION, >> as I already stated. > > Okay. > > Cheers, > Al Iverson > PS- I already troubleshoot this stuff all day for pay, and then > already help kind people on the side for free, so then also helping > somebody who's already half grumpy about it to try to win an argument > that they don't want me to win, anyway, doesn't really give me a whole > heck of a lot of joy. > PPS- Don't send to Gmail over IPv6. He’s also been told, repeatedly, to stop using a free service that doesn’t police its users for email. Google doesn’t like services that let folks abuse them and don’t do anything about it. They’re also blocking mail with bit ly links in them, too. All of the complaints I’ve seen about google track back to: the person was either actively sending spam (possibly unknowingly, but that doesn’t exactly reflect well on the sender) or they’re using a free service that is regularly used to send spam and they refuse to actually move to a service that doesn’t allow abuse. No one is forced to use google as a recipient mail server and everyone who is using it made a choice to do so - either by moving their domain there or actively signing up for a gmail.com <http://gmail.com/> address. Recipients have agency here and can move elsewhere for mail. The fact that they don’t tells me that google understands their userbase really well and does what they need to do to keep them happy. laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone else experiencing a spike in Spamhaus CSS listings lately?
That sounds very strange for sure. I’ve not heard anything from others about problematic CSS listings (and the 9am thing is weird). Are they accompanied by DBL listings or are they just the sending IPs? The standard with CSS-style listings is there is a problem with your address collection process that’s causing it - you’re sending mail in sufficient volume to addresses feeding data to spamhaus that cause the CSS detectors to fire. Got an IP or two you’re willing to share (offlist even). Happy to take a look at things and see if there is something that leaps out and I can be helpful. laura > On 14 Mar 2022, at 21:24, admin admin via mailop wrote: > > Hello, > > Are there any other postmaster experiencing a spike in CSS listings lately? I > had some IPs get listed on the CSS yesterday, and I have some other friends > experiencing the same issue this morning at around 9am. > > Curious if anyone has any insight regarding this matter. > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
