Re: [mailop] Spamhaus and Vultr
Even if this wasn't happening, you should still go sign up for DQS. Cheers, Al Iverson On Sun, May 12, 2024 at 10:49 AM Lyle Giese via mailop wrote: > > Based on reading Spamhaus's page(referenced below), they will slowly > block ALL Vultr ip address space from using the Spamhaus public > mirrors. Doesn't matter what the reverse IP address is. > > But signing up for Spamhaus DQS free service, you merely change your > configuration after getting a free DQS key from Spamhaus. > > If you are querying their zen database, you have configured queries to > use 'zen.spamhaus.org'. You change that to > 'your_DQS_key.zen.dq.spamhaus.net' > > Lyle Giese > > On 5/12/24 09:44, J Doe via mailop wrote: > > Hi mailop, > > > > I noticed that Spamhaus has posted a notice that after May 22nd, > > people and/or businesses making use of Vultr for their infrastructure > > will need to transition to a different way of querying the > > blocklists[1]. The post mentions that Vultr’s default reverse IP > > assignment masks who is querying the blocklists. > > > > In my scenario, I have my own recursive, validating resolver running > > on my mail server on a Vultr instance and it has a reverse DNS name > > that is not the default one that Vultr assigns and I query: > > zen.spamhaus.org. > > > > Do I still need to make changes ? > > > > I am uncertain from the blog posting if this refers to people making > > use of the resolver that Vultr provides or if it extends to all of > > Vultr’s IP space (ie. all cloud instances). > > > > Thanks, > > > > - J > > > > Links > > > > > > [1] See: > > https://www.spamhaus.org/resource-hub/email-security/if-you-query-the-legacy-dnsbls-via-vultr-move-to-spamhaus-technologys-free-data-query-service/#why-can't-vultr-users-query-the-public-blocklists > > > > ___ > > mailop mailing list > > mailop@mailop.org > > https://list.mailop.org/listinfo/mailop > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson // 312-725-0130 // Chicago http://www.spamresource.com // Deliverability http://www.aliverson.com // All about me https://xnnd.com/calendar // Book my calendar ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Someone at Google (GSuite) with a clue?
Aaron, I suggest doing three things. 1. Filling out the Gmail sender contact form (details: https://www.spamresource.com/2022/01/gmails-sender-contact-form-what-and-why.html ) 2. Share the example bounce message here. Maybe somebody will be able to provide some feedback on that. 3. Share aboutmy.email results here if you're able, or offlist if you'd like somebody to review and confirm no configuration issue. Google folks have been known to read this list, but it's not really intended to be an escalation point for Gmail issues, so no guarantees that somebody's just waiting to go to bat for you. But the more details you share here, the more you empower anyone reading (including those from Google) to be able to assist. An example of this would be that if you're sharing the error message, maybe some Google person forwards it to a coworker to have them check a filter rule for bugs, and it could perhaps end up addressed, even if nobody engaged you directly. Regards, Al Iverson On Fri, May 10, 2024 at 6:18 PM Graeme Fowler via mailop wrote: > > You said: > > then there's a bounce > > and then: >> >> GMail is accepting our messages, then silently junking them. > > > So... Which of these is correct? They can't both be. > > Graeme > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson // 312-725-0130 // Chicago http://www.spamresource.com // Deliverability http://www.aliverson.com // All about me https://xnnd.com/calendar // Book my calendar ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Cannot send messages to Google Mail users
Is disabling IPv6 an option here? A prior poster suggested as such, but I don't know if that was just a general suggestion or if that's actually possible in O365 settings. But if you can yes, try sending outbound mail only via IPv4. A "well known secret" is that Gmail filters mail from IPv6 connections more harshly than IPv4. Maybe less than they once did, and certainly you could question if it's fair or not, but I saw clear evidence of it in the past. I personally have IPv6 disabled on my MTA because of it. Also make sure your DKIM is set up as YOU and not just as the default *.onmicrosoft.com that Microsoft sticks on there for those who aren't fully configured. If you want folks to look at headers and offer up additional suggestions, run a test using https://aboutmy.email and share the results link here. I'll take a look and advise, and I imagine others will, too. Cheers, Al Iverson -- Al Iverson // 312-725-0130 // Chicago http://www.spamresource.com // Deliverability http://www.aliverson.com // All about me https://xnnd.com/calendar // Book my calendar ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Outlook Asynchronous Bounces
I'm seeing it as well. I've blogged about it here: https://www.spamresource.com/2024/04/microsoft-intermittent-storedrvdeliver.html Somebody theorized to me that it could be some sort of new "mailbox full" type error. But that doesn't seem to fit with what I'm seeing. Cheers, Al Iverson On Tue, Apr 9, 2024 at 4:35 PM Mark Fletcher via mailop wrote: > > On Tue, Apr 9, 2024 at 5:09 PM David Landers via mailop > wrote: >> >> Beginning today, we've observed a spike in asynchronous bounces -- messages >> initially accepted for delivery but then returned as a non-conversational >> bounce -- at Outlook domains (e.g. outlook.com, hotmail.com, etc.) with the >> following rejection syntax: >> >> 532 5.3.2 STOREDRV.Deliver; Missing or bad mailbox Database property >> > A quick spot check of our logs shows that we started getting that specific > error message yesterday afternoon and have gotten a lot of them today. > > Cheers, > Mark > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson // 312-725-0130 // Chicago http://www.spamresource.com // Deliverability http://www.aliverson.com // All about me https://xnnd.com/calendar // Book my calendar ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] is warming IPs still necessary?
On Wed, Mar 27, 2024 at 11:19 PM Gerald Oskoboiny via mailop wrote: > > * Gerald Oskoboiny via mailop [2024-03-25 15:58-0700] > >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. > > > >Is it still necessary to warm up new IP addresses gradually > >instead of going directly to this volume of deliveries? > > We did this migration last night and it generally went much > better than I expected. A tiny bit of greylisting from some hosts > but no serious issues. Good deal. In this case, I am happy to be proven wrong and I'm glad that you didn't run into any serious issues. Cheers, Al Iverson -- Al Iverson // 312-725-0130 // Chicago http://www.spamresource.com // Deliverability http://www.aliverson.com // All about me https://xnnd.com/calendar // Book my calendar ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] is warming IPs still necessary?
On Tue, Mar 26, 2024 at 12:40 PM Gerald Oskoboiny via mailop wrote: > > * Laura Atkins via mailop [2024-03-26 09:21+] > >> 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. > > Even for something like email discussion lists? 0.00% of this > email is marketing/transactional. It's just a bunch of nerds > talking about web standards. If it's just low/medium volume W3 nerd stuff and you have trouble, feel free to reach out and I'll be happy to let you smart host relay through my MTA, like I'm doing with my own EC2 (and GC) hosts. Cheers, Al -- Al Iverson // 312-725-0130 // Chicago http://www.spamresource.com // Deliverability http://www.aliverson.com // All about me https://xnnd.com/calendar // Book my calendar ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] is warming IPs still necessary?
+1 to what Laura says. I run a couple of EC2-hosted mail servers but I smarthost their mail out through another server, because, if you can get Amazon to unblock port 25 for you, people are still probably going to reject your mail far and wide. The EC2 IP ranges are likely to be treated unkindly both based on the presumption that it's not really a mail hosting neighborhood PLUS anybody who has run a spamtrap network and watched for connections coming from there tends to figure out quick that it's mostly weird stuff like random SMTP tickling for unclear reasons and security testing/threat research. I would not and do not want my legit mail to be part of that neighborhood. Either don't run this in EC2, use SES to handle outbound, or do it my convoluted way and smarthost the mail out through a whole other dedicated server at a completely unrelated ISP that has a good reputation. I'm not even sure I'd recommend it, but I've been doing it for years and years, so it's really more a question of inertia at this point. I might have had this server as a mail server going back to before Amazon SES launched. Cheers, Al Iverson On Tue, Mar 26, 2024 at 5:09 AM Niels Dettenbach via mailop wrote: > > Am Dienstag, 26. März 2024, 10:21:23 CET schrieb Laura Atkins via mailop: > > Don’t use EC2 for mail. Use SES. > yes, > but by my experience, AWS today has a overall poor reputation within the > internet email sphere. > > just my .02$ > > > niels. > > -- > --- > Niels Dettenbach > Syndicat IT & Internet > https://www.syndicat.com > PGP: https://syndicat.com/pub_key.asc > --- > > > > > > > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson // 312-725-0130 // Chicago http://www.spamresource.com // Deliverability http://www.aliverson.com // All about me https://xnnd.com/calendar // Book my calendar ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone from Microsoft?
Mark, the path here is the normal contact channel for Microsoft OLC issues - http://go.microsoft.com/fwlink/?LinkID=614866 - and requesting pre-emptive accommodation: More on that here: https://www.spamresource.com/2021/05/requesting-pre-emptive-accommodation.html That magic phrase tells them that you're trying to do IP warming. They'll usually respond with a blank grid, asking you to fill in dates and volumes, to demonstrate projected volume. They will then adjust rate limiting accordingly. Like everything else related to Microsoft deliverability support, success here will vary based on how good or bad the support rep is who happens to answer your ticket. You might have to respond forcefully one or more times, or you might need to try multiple ticket submissions, if the first one gets lost or results in a nonsensical response. Good luck, Al Iverson On Tue, Mar 5, 2024 at 5:03 PM Mark Fletcher via mailop wrote: > > Hi All, > > As we continue to warm up some new mail servers, we're getting rate limited > on one of them, with the following error: > > 451 4.7.650 The mail server [45.79.224.9] has been temporarily rate limited > due to IP reputation. For e-mail delivery information, see > https://postmaster.live.com (S775) > [AM7EUR06FT056.eop-eur06.prod.protection.outlook.com 2024-03-05T22:51:22.952Z > 08DC3CCF8A0C7716] > > I have checked https://sendersupport.olc.protection.outlook.com/pm/ (which is > a very flaky website; it doesn't seem to be working at the moment, but has in > the past), and there are no blocks on this particular mail server, and there > haven't been for days. > > Is there somewhere else I should be looking? > > Thanks, > Mark > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson // 312-725-0130 // Chicago http://www.spamresource.com // Deliverability http://www.aliverson.com // All about me https://xnnd.com/calendar // Book my calendar ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] One click unsubscribe in mailing list messages
On Fri, Feb 23, 2024 at 3:44 PM Mark Fletcher via mailop wrote: > > My question to you all is, do you think that the List-Unsubscribe=One-Click > header is supported well enough these days such that I can replace the > one-click unsub link in the message bodies with a link that requires > authentication? Also, do you think doing so would adversely affect our > distribution? I think it's fine to make any in-body link a two step to unsub - click to confirm - to avoid bot clicks and false positive unsubs. I'd not go crazy beyond that. CAN-SPAM disallows putting a login in front of the unsub process. Does that apply to your mailing list/groups mail? Not clear to me, but I wouldn't want to find out. You'll definitely get people complaining that it violates the law. Will moving to "two click" on any in-body unsub link affect you negatively? No, not really. You'll be fine. And it's compliant with Yahoo/Google. They're only mandating one-click as in "one click post" via the list-unsub headers as you've already suggested that you comply with. It is not uncommon to use the same URL in both the list-iunsub header and the body of the email. If somebody visits the URL (not post), show a confirm step. If somebody POSTS to the URL, then it's a list-unsub from a mailbox provider, and unsub without a confirm step. Here's more detail on list-unsub/list-unsub post if you need it: https://www.spamresource.com/2023/12/bonus-webinar-crash-course-on-list.html But I rather suspect you've pretty much got it covered. Cheers, Al Iverson -- Al Iverson // 312-725-0130 // Chicago http://www.spamresource.com // Deliverability http://www.aliverson.com // All about me https://xnnd.com/calendar // Book my calendar ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anybody having trouble with gmail not recognizing valid SPF records?
I saw you've since cleaned up the SPF record a bit to remove the IPv6 a/mx entries. Did that fix it? If not, this might actually be worth submitting to them to point out that they may be parsing it wrong: https://support.google.com/mail/contact/gmail_bulk_sender_escalation Regards, Al Iverson On Thu, Feb 15, 2024 at 12:21 PM Eric J Esslinger via mailop wrote: > > My SPF records have been valid for... oh 10 years or so, and haven't changed, > but the last two days I'm getting intermittent bounces sending to gmail.com > addresses from our customer domain. > I've sent a couple of emails to postmas...@gmail.com but I'm not sure it's > monitored. Anyone else seeing such issues? > > Hi. This is the qmail-send program at mail.fpunet.com. > I'm afraid I wasn't able to deliver your message to the following addresses. > This is a permanent error; I've given up. Sorry it didn't work out. > > : > 142.250.105.27 failed after I sent the message. > Remote host said: 550-5.7.26 This mail has been blocked because the sender is > unauthenticated. > 550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM. > 550-5.7.26 > 550-5.7.26 Authentication results: > 550-5.7.26 DKIM = did not pass > 550-5.7.26 SPF [fpunet.com] with ip: [104.171.208.42] = did not pass > 550-5.7.26 > 550-5.7.26 For instructions on setting up authentication, go to > 550 5.7.26 https://support.google.com/mail/answer/81126#authentication > t8-20020a25f60800b00dcbcc921879si776036ybd.61 - gsmtp > > > dig @8.8.8.8 txt fpunet.com > > ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-25.P1.el5_11.10 <<>> @8.8.8.8 txt fpunet.com > ; (1 server found) > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43644 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;fpunet.com.IN TXT > > ;; ANSWER SECTION: > fpunet.com. 900 IN TXT "v=spf1 +mx a:mail.fpunet.com > ip4:104.171.208.42 ip6:2602:FD43:0:2::42 -all" > > ;; Query time: 38 msec > ;; SERVER: 8.8.8.8#53(8.8.8.8) > ;; WHEN: Thu Feb 15 11:59:10 2024 > ;; MSG SIZE rcvd: 115 > > > Eric Esslinger (eesslin...@fpu-tn.com) > Information Services Manager > Fayetteville Public Utilities (http://www.fpu-tn.com/) > 408 College St W > Fayetteville, TN 37334-2914 > 1-931-433-1522 x 165 > 1-800-379-2534 x 165 > Fax: 1-931-433-0646 > > This message may contain confidential and/or proprietary information and is > intended for the person/entity to whom it was originally addressed. Any use > by others is strictly prohibited. > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at https://www.spamresource.com Subscribe to the weekly newsletter at https://ml.spamresource.com DNS Tools: https://wombatmail.com / (312) 725-0130 / Chicago ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail blocking
My suggestion is make sure you've got your ducks in a row then reach out to Google via the bulk sender form. 1. Implement DKIM and SPF. Must have both. Don't let clients send using any domain but a fully authenticated one. 2. Make sure you're not blindly sending, allowing to send, or forwarding spam. Generic old school forwarding is bad news. It tends to suck up spam, even at small levels, and screw up YOUR reputation as the forwarder. A longer discussion is likely merited if you really want to do email forwarding. 3. Implement DMARC and monitoring, make sure your poor rep isn't due to somebody else's spoofing. 4. Review Yahoo/Gmail's recent sender requirement additions and make sure you're generally able to comply. Nobody's going to expect you to add an unsub to 1:1 mail, so you'll have to apply a little logic to figure out what should apply to you and what should not, since some of the guidance is oriented to bulk/broadcast/newsletter senders. 5. Request remediation/reconsideration here: https://support.google.com/mail/contact/gmail_bulk_sender_escalation It is not impossible for small sites to deliver mail to Gmail. I've got my own personal MTA, run my own mailing lists, send my email newsletter, etc., from it, and I don't really ever have Gmail issues. But I've perhaps got an advantage of working in the deliverability space and being on top of this sort of thing for a number of years. Bonus points, don't send over IPv6 to Gmail (it's doable, but it's even more "expert level" than IPv4, historically), and make sure you've got TLS in place. That error message, though, makes it sounds like IP reputation which is a rare error. Really makes me wonder if you've got clients with custom domains potentially doing low levels of cold emailing or just unauthenticated mail that isn't getting much response from Gmail users. Read more about the Yahoo/Google changes here: https://blog.google/products/gmail/gmail-security-authentication-spam-protection/ https://blog.postmaster.yahooinc.com/post/730172167494483968/more-secure-less-spam Good luck! Cheers, Al Iverson On Thu, Feb 8, 2024 at 5:53 PM Trey Nolen via mailop wrote: > > I work with a small regional ISP and our main domain has been getting > blocked by Gmail since February 6. Our logs indicate we haven't sent a > huge volume of data to Google or anything. Our reputation has been > really good in Postmaster Tools until the 6th when it went straight to > the bottom. We never saw any indication of compromised accounts or > anything. > > We've been watching and waiting for it to clear up, but it hasn't. Other > domains can send through our system, but internetpro.net cannot. I was > hoping someone here might be from Google and could take a look. Even > the reports under Postmaster Tools look wrong as we have a 100% delivery > error rate, but all of the "Error Types" show 0.0%. > > Here is a sample of what we're seeing: > > > ---BEGIN > > 74.125.138.26 failed after I sent the message. > Remote host said: 550-5.7.1 [74.252.14.252 7] Gmail has detected > that this message is likely > 550-5.7.1 unsolicited mail. To reduce the amount of spam sent to Gmail, this > 550-5.7.1 message has been blocked. For more information, go to > 550 5.7.1 https://support.google.com/mail/?p=UnsolicitedMessageError > o20-20020a81de5400b006041f08d2dfsi1515206ywl.160 - gsmt > > ---END > > This seems to indicate that it is content filtering, but no matter what > content the messages hold, we get the same. > > > > Even if someone wanted to reach out off list, that would be great. > > > -- > Trey Nolen > supp...@internetpro.net > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at https://www.spamresource.com Subscribe to the weekly newsletter at https://ml.spamresource.com DNS Tools: https://xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] zen.spamhaus.org
Doesn't matter how small your server is, or isn't. Spamhaus blocks public queries, but does it a bit imperfectly, so it's the kind of thing where you can get away with it for a while, then something changes, and they find a new way to lock it down a bit better. Look at the response code. Sign up for Spamhaus DQS and implement the proper DNS zone query with your DQS key embedded, as one does. That'll fix this. Full stop. That's the problem, that's the solution. Learn: https://www.spamresource.com/2021/11/howto-query-spamhaus-safely.html "Spamhaus is even blocking Gmail" is a dead giveaway: https://www.spamresource.com/2022/11/spamhaus-is-not-blocking-gmail.html Spamhaus closing loopholes for public/unfettered DNS querying: https://www.spamresource.com/2022/10/spamhaus-to-block-queries-from-aws.html https://www.spamresource.com/2024/02/spamhaus-blocking-queries-from-digital.html https://www.spamresource.com/2022/01/querying-spamhaus-via-cloudflare-dns.html Bad news: https://www.spamresource.com/2021/10/be-careful-using-spamhaus-with-open.html They've been warning us for three years now: https://www.spamresource.com/2021/02/spamhaus-warns-watch-for-new-error.html No, almost five years! https://www.spamresource.com/2019/10/spamhaus-blacklist-changes.html Cheers, Al Iverson -- Al Iverson / Deliverability blogging at https://www.spamresource.com Subscribe to the weekly newsletter at https://ml.spamresource.com DNS Tools: https://xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Looking for feedback on the Certified Senders Alliance (CSA)
I have worked with people from the CSA over the past few years, mostly on webinar training sessions, and they seem kind and seem to care about email. I also observed them ejecting a company from their organization for not following their rules. I can't really go into specifics on that one. I don't have hard data regarding CSA participation improving your deliverability results, but I do like them as people and I believe them to be legitimate. Cheers, Al Iverson On Tue, Feb 6, 2024 at 10:57 AM Anael MOBILIA via mailop wrote: > > Hello, > > > I'm looking for feedback on the Certified Senders Alliance (CSA). > > > My current reasoning : at job, we provide a SaaS solution for cash > collection & credit management. > > This implies to send emails to end customers in order to exchange about > incoming invoices. We sent emails to servers all around the globe, > actually mostly in Europe. > > Email volume is not so big as today (~350k per month) but is still > increasing. > > > I'm looking to maintain high quality reputation / deliverability and > equally to ensure we provide state-of-the-art technical service. > > Best-practices (SPF, DKIM, DMARC, user consent, Unsubscribe, email > quality, RBL, Google / Microsoft tools registration, ...) are already > implemented, but I'm still searching to go further. > > > I was recently told about the CSA / Certified Senders Alliance which is > a paid service which is warranting that members apply a set of legal and > technical criteria (best practices in fact) and could help to improve > email deliverability on some "too big to fail" (looking for example to > O365). This could be an additional asset for email companies which don't > take only technical statement for ensuring email deliverability. > > > I'm looking for any feedback on the Certified Senders Alliance and any > experience regarding deliverability change when becoming a member. > > I have looked on the archive of the list, some exchanges occurred years > ago, but I didn't find (recent) feedback on this. > > > Bests regards, > > Anael MOBILIA > > > -- > IT Team My DSO Manager > > 22 chemin du Vieux Chêne, Bât. D, 38240 Meylan FRANCE > www.mydsomanager.com > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at https://www.spamresource.com Subscribe to the weekly newsletter at https://ml.spamresource.com DNS Tools: https://xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM signed with parent domain
> Independent of this I wouldn’t use r...@hostname.example.org as a sender
> address to external recipients. This doesn’t look professional, makes
> replying to those emails impossible and in case hostname.example.org doesn’t
> have a public IP address it might also increase the risk that those messages
> are treated as spam or rejected, because they are coming from an unresolvable
> domain.
> Many MTAs provide ways to rewrite sender addresses, so you could rewrite both
> MAIL FROM and header From to someth...@example.org before delivering the
> messages. This will resolve all questions about subdomains once and for all
> and doesn’t even require any changes to the applications which create the
> messages.
Agreed. Example: Depending on your unix config, you can do like I did
and create /etc/mailutils.conf with this in it:
address {
email-domain xnnd.com;
};
So that any `echo "notification" | mail aiver...@wombatmail.com` will
come from u...@xnnd.com, not u...@server32.xnnd.com.
Cheers,
Al Iverson
--
Al Iverson / Deliverability blogging at https://www.spamresource.com
Subscribe to the weekly newsletter at https://ml.spamresource.com
DNS Tools: https://xnnd.com / (312) 725-0130 / Chicago (Central Time)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: [mailop] Contact Google Postmaster
How to contact Google to beg for Gmail spam folder forgiveness: https://www.spamresource.com/2022/01/gmails-sender-contact-form-what-and-why.html Cheers, Al Iverson On Fri, Jan 26, 2024 at 12:34 PM Scott Mutter via mailop wrote: > > It seems messages being sent from 173.225.104.91 are being delivered into > Gmail user's spam boxes. > > These messages are DKIM signed, pass SPF and DMARC. > > I'm not seeing where 173.225.104.91 is on any public blacklist. > > Anyone from Google able to shed any light on this? > > Thanks > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at https://www.spamresource.com Subscribe to the weekly newsletter at https://ml.spamresource.com DNS Tools: https://xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Malformed To: header
> > recently i see messages from this ML rejected by my MTA, due > > malformed To: header (from postmas...@inter-corporate.com): > > > >To: mailop@mailop.org Unrelated to the question of whether or not @ merits escaping or quoting... I personally wouldn't put an email address in the "friendly to" (the bit between the To: and <). You will find some providers and spam filters will consider that a sign of badness. I ran into this personally back on November 30th, though apparently I didn't save the NDR so I can't tell you which filter it was. I ended up modifying my own mailing list manager to strip email addresses out of the "friendly" bit of email headers. Cheers, Al Iverson -- Al Iverson / Deliverability: https://www.spamresource.com Tools: https://www.wombatmail.com / (312) 725-0130 (Chicago) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail classifying message as spam based on the sending IP
Submit a sample message from the affected IP here: https://support.google.com/mail/contact/gmail_bulk_sender_escalation They rarely respond, but they do sometimes address issues based on submissions. Cheers, Al Iverson On Fri, Oct 13, 2023 at 7:25 AM Fernando MM via mailop wrote: > > Hi, > > I'm debugging an issue with gmail classifying a simple confirmation email as > spam. > > At my gmail account it displays "Why is this message in spam? It is similar > to messages that were identified as spam in the past.". And at a coworker's > account it's displaying the "This message seems dangerous" phishing warning. > > If I send this message from another IP at the same /24 range, it works fine > and it's delivered to the inbox. No spam/phishing warnings. Also no > differences in SPF, DKIM etc. > > The issue is that when I check Gmail's Postmaster panel, both IPs have a HIGH > reputation. > > We also have the historical reputation ( since 2021 ) for these IPs saved > locally and they never had a single Medium/Bad day. > > Did anyone here had similar issues in the past? Were you able to fix it > somehow? > > Thanks. > > > > _______ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at https://www.spamresource.com Subscribe to the weekly newsletter at https://ml.spamresource.com DNS Tools: https://xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] New Gmail sender guidelines
I've blogged about it here, if you're looking for a link to show people when they ask what to do: https://www.spamresource.com/2023/09/gmail-now-rejecting-unauthenticated-mail.html Cheers, Al Iverson -- Al Iverson / Deliverability blogging at https://www.spamresource.com Subscribe to the weekly newsletter at https://ml.spamresource.com DNS Tools: https://xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] hotmail.com SPF forgot IPv6
Yeah, blocking on SPF -all is scary, really people shouldn't. But I'm guilty of implementing it that way myself, so who am I to talk? Maybe it's more that it's fine if you want to do it as a crazy hobbyist, but if you're one of the biggest mailbox providers on the earth...it's not a great idea. The problem is that even if you have DMARC in place, it is VERY easy to configure SPF checking so that SPF-failing mail is blocked at the edge...you never get far enough to denote DKIM passing. Having accidentally configured OpenDKIM and Python-PolicyD-SPF this way myself in the past, I imagine others likely have to, and not everybody's smart enough to notice when the edge cases are getting weird. It also depends on whether or not you want to really rely on DMARC or not. If so, ~all would stop SPF alone causing a bounce, but still leave things up to DMARC as far as rejecting or not ... so DKIM would be considered. Assuming it's all configured correctly on the receiving side. So, ~all is the way to go given that if done in conjunction with DMARC, you're still telling the world to reject faked mail, but in a slightly more safe manner. Cheers, Al Iverson -- Al Iverson / Deliverability blogging at https://www.spamresource.com Subscribe to the weekly newsletter at https://ml.spamresource.com DNS Tools: https://xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Delivery Reports, requested by Microsoft 'Outlook' customer, reported as Spam by same Microsoft 'Outlook' customer?
Doesn't seem like a new problem, really. Any user can report spam on anything they want, and I'm not aware of any mechanism to suppress stupid reports from the sending side. On Thu, Aug 10, 2023 at 10:35 AM Benoit Panizzon via mailop wrote: > > Hi Team > > I would be very happy, if anymone at microsoft could get > in touch with me, we probably get more than 90% false positives from > the microsoft spam report robot. > > Newest crazy addition! > > exam...@outlook.com is sending an email indicating request for a > delivery report. > > Our server AFTER delivering the email, obliges: > > From:(Mail Delivery System) > To: exam...@outlook.com > Successful Mail Delivery Report > > This is the mail system at host idefix.imp.ch. > > Your message was successfully delivered to the destination(s) > listed below. If the message was delivered to mailbox you will > receive no further notifications. Otherwise you may still receive > notifications of mail delivery errors from other systems. > >The mail system > === snip === > > exam...@outlook.com is reporting this as spam. We get a complaint from > microsoft asking for us to suspend 'mailer daemon' for sending > unsolicited emails. Doh! > > Microsoft, could you please just block customers like this one who > repeatedly abuse your spam complaint machinery? > > Or build some simple rules to redirect 'dubious' spam reports to be > reviewed by a human before clogging abuse desks of fellow ISP with such > reports? > > Dubious could be: > > * from a 'mailer daemon'. > * containing other signs that it is some sort of bounce. > * Quoted text matching an email recently sent by your customer. > > etc > > I also wonder if you told your customers, confirming to GDPR, that you > are disclosing their mail content to the abuse desk of any ISP around > the world. We repeatedly get all sort of emails reported as spam, which > I would consider to contain very sensitive information like salary > information etc. > > Mit freundlichen Grüssen > > -Benoît Panizzon- > -- > 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 -- Al Iverson / Deliverability blogging at https://www.spamresource.com Subscribe to the weekly newsletter at https://ml.spamresource.com DNS Tools: https://xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Send emails over O365 to Google with a specific domain are rejected
Domain reputation blocks at Gmail are more common nowadays than in years past. Suggestions: Make sure all mail passes SPF and DKIM, especially DKIM. Has to be a DKIM signature for dnn.de, not the default "onmicrosoft.com" domain that O365 will use by default. Submit a request for reconsideration here: https://support.google.com/mail/contact/gmail_bulk_sender_escalation?visit_id=638269633865177067-1793378121=1 Learn more about that form here: https://www.spamresource.com/2022/01/gmails-sender-contact-form-what-and-why.html If MS is using IPv6 to send the mail to Google, you might be in an extra difficult spot. Not everybody agrees/believes this, but in my experience Gmail is more quick to block IPv6-sent mail; they're more stringent about what they might let through versus IPv4. I can't imagine that's something you can control, but, hey, if I'm wrong and it is, it's worth checking. You're on the right path with GPT. Might also want to make sure you've got a DMARC policy in place with p=quarantine or reject. If you really have no bad history with this domain, it could just be that Gmail is suspicious given a lack of history. If you REALLY get nowhere, it might be time to consider moving off of O365 and onto some other infrastructure for corporate mail. Just because you don't really have enough control over the infrastructure levers here. Cheers, Al Iverson On Sun, Aug 6, 2023 at 12:02 PM Oliver Kirchel via mailop wrote: > > Hello, > > I am a postmaster for a German media company and for the last three weeks I > have had the problem that emails from a certain domain (dnn.de - hosted at > O365) are being rejected by Google (suspects your message is spam and > rejected it). Emails from the domain that are not sent via the O365 > infrastructure arrive. I then configured the domain at > https://postmaster.google.com/ and the statistics I see there actually look > quite good. Has anyone else had such an experience or is there someone from > Google reading this who I can talk/write to? > > Thanks Olli > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at https://www.spamresource.com Subscribe to the weekly newsletter at https://ml.spamresource.com DNS Tools: https://xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Guide for setting up a mail server ?
I covered that here: https://www.spamresource.com/2020/07/small-mailserver-best-current-practices.html Anybody who would like to write up a guide, I'd be happy to publish it on Spam Resource (or link to it if you publish it elsewhere). Feel free to reach out. Cheers, Al Iverson -- Al Iverson / Deliverability blogging at https://www.spamresource.com Subscribe to the weekly newsletter at https://ml.spamresource.com DNS Tools: https://xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] greylisting
On Sun, Jun 25, 2023 at 3:33 AM ml+mailop--- via mailop wrote: > > On Sun, Jun 25, 2023, Carsten Schiefner via mailop wrote: > > > The question, however, is: will it ble..., erm, can one do without > > greylisting? > > It would mean more spam is coming through - so for my case greylisting > is not useless -- which was the unsubstantiated claim to which I > replied. Sounds a bit more like YMMV. My typical spam problems at my personal domains didn't seem fazed by greylisting. But I guess my personal experience is "unsubstantiated." I think John also said he's auto-whitelisting a bunch of stuff based on an initial pass, which is an automation step I surely wish I had. Cheers, Al Iverson -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SendGrid is deleting your mail
What if we just got to the heart of the matter and admitted that greylisting is useless 2023? It was meant to annoy botnet spammers etc. who, once upon a time, did not have big iron and big disks to be able to queue and retry. That reality basically no longer exists. I tested greylisting myself this year in my own mail-in-a-box setup and found it was just a pain in the ass that delayed password reset emails while I spent too much time trying to whitelist stuff I cared about receiving in a timely fashion. It's a 1990s style configuration option that makes little sense in 2023 and I don't really see any data proving that it actually does anything that inhibits modern spam. The botnets can retry, too. Cheers, Al Iverson -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Port 25 Pingback?
On Fri, Jun 16, 2023 at 12:41 PM John Possidente via mailop wrote: > > A sender of legally mandated bulk mail who are very conscious of making sure > they're dotting every i and crossing every t (because they're required to) > asked me today whether port 25 pingback is still necessary. I immediately > thought, "Of course not," but on second thought (before speaking, yay) > realized that maybe I'm wrong. > > Does anyplace still reject mail from sources that don't answer on port 25? No place that matters. Most ESPs have separate infra for outbound SMTP and inbound reply handling, and it's not the same servers, not the same IPs. Thus, the servers connecting outbound to deliver mail do not answer on port 25. This is how it was where I used to work and it was no impediment to billions of messages delivered monthly. And I never saw an instance where delivery was held up by waiting to see if the inbound infra could be reached on port 25 separately. Cheers, Al Iverson -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] When Will Outlook Rollout SRS for All of Their Email Servers? (For the sake of bimi)
How long until Google, Yahoo, others stop accepting that forwarded mail from Microsoft, is another way to frame that. Good to see it getting some attention. I'll be curious to see who addresses it and how. Cheers, Al Iverson On Mon, Jun 5, 2023 at 3:01 PM Alex Liu via mailop wrote: > > Looks like the bad guys are exploiting Outlook's forwarding feature to bypass > BIMI. > > https://twitter.com/chrisplummer/status/1664075886545575941 > > We reported this issue in April: > https://www.sysnet.ucsd.edu/~voelker/pubs/forwarding-eurosp23.pdf > > -- > Regards, > Enze "Alex" Liu > PhD Student > Department of Computer Science and Engineering > e7...@eng.ucsd.edu > University of California, San Diego > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Forwarding mail originating from gmail via 3rd party to gmail
Try rewriting the message ID. I think Gmail is believing the message to be a duplicate and in some cases it will silently eat duplicates. I have a forwarding feature for my own domains that in addition to using SRS and re-signing DKIM with my domain, it rewrites the message ID. Good point about ARC; I don't have proof that it would fix things but it would potentially be something to try. Cheers, Al On Wed, May 17, 2023 at 4:23 AM Taavi Eomäe via mailop wrote: > > Do those forwarded letters without SRS have intact DKIM? > > A second thing you can try is ARC (without the SRS), I've gotten the > impression that Gmail "likes" original letters (and ARC) more than it > likes any kind of mangling, including SRS. > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Any Postmasters or abuse team from Amazon AWS on here?
Seems like sending as yahoo.com from SES is going to have very poor deliverability given yahoo.com has a DMARC policy of reject. It'd be good to nudge Amazon to block certain domains, sure, but even if they don't, I don't see how somebody's going to have much spam success via that path. TL;DR who cares, honestly. On Mon, May 8, 2023 at 8:11 PM L. Mark Stone via mailop wrote: > > I also have an issue with an AWS sender using AWS IPs to send email From > @yahoo.com. > > AWS Support (I’m an AWS customer) says this is OK. > > ___ > L. Mark Stone > > > > On May 8, 2023, at 8:24 PM, Michael Peddemors via mailop > > wrote: > > > > Wouldn't mind a quick off list dialogue about a prolific spammer team > > abusing AmazonSES, will share the fingerprints on this actor.. > > > > Amazon SES is always tougher to filter the good and the bad, but this > > guy is well known affiliate marketer to suspect sites, and occasionally > > the odd bit of malware advertisements as well. > > > > While we manage to filter this guy to some extent, the footprint is > > smaller via SES, so be nice to work together on this one. > > > > Subject: Adult Film Star Gives New Meaning to Crotch Shot During Video > > > > > > -- > > "Catch the Magic of Linux..." > > > > Michael Peddemors, President/CEO LinuxMagic Inc. > > Visit us at http://www.linuxmagic.com @linuxmagic > > A Wizard IT Company - For More Info http://www.wizard.ca > > "MagicSpam" is a Registered TradeMark of Wizard Tower TechnoServices Ltd. > > > > 604-682-0300 Beautiful British Columbia, Canada > > > > This email and any electronic data contained are confidential and intended > > solely for the use of the individual or entity to which they are addressed. > > Please note that any views or opinions presented in this email are solely > > those of the author and are not intended to represent those of the company. > > > > > > -- > > "Catch the Magic of Linux..." > > > > Michael Peddemors, President/CEO LinuxMagic Inc. > > Visit us at http://www.linuxmagic.com @linuxmagic > > A Wizard IT Company - For More Info http://www.wizard.ca > > "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. > > > > 604-682-0300 Beautiful British Columbia, Canada > > > > This email and any electronic data contained are confidential and intended > > solely for the use of the individual or entity to which they are addressed. > > Please note that any views or opinions presented in this email are solely > > those of the author and are not intended to represent those of the company. > > ___ > > mailop mailing list > > mailop@mailop.org > > https://list.mailop.org/listinfo/mailop > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] New to mass mailings
Here's my Microsoft Deliverability Guide, recently updated: https://www.spamresource.com/2023/04/isp-deliverability-guide-microsoft-olc.html The company I work for, we provide deliverability monitoring software and consulting services. Feel free to reach out if either interest you. Work email: al AT kickbox.com You can probably figure out the website from that, if you want to check it out yourself. :) Cheers, Al Iversion -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] How to address Microsoft if spaming Office365 customers cause collateral damage for other Office365 customers sharing the same IP?
> On 3/30/23 07:37, Benoit Panizzon via mailop wrote: > > > What would be the best way to address such issues for Office365 > > customers? My recommendation is to recognize that 1-bit binary blocklistings aren't granular enough to account for shared environments without causing false positives. Some call that a feature, some call it a bug. That is probably why some reputation engines (Gmail) don't stop there and look at the domain and other markers, too. Even SpamAssassin helps me block some of that kind of stuff based on Spamhaus DBL listings and content matching. -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Tightening of delivery rules for Exchange Online
On Tue, Mar 28, 2023 at 11:44 AM Grant Taylor via mailop wrote: > > On 3/28/23 10:19 AM, Al Iverson via mailop wrote: > > Eventually we have to stop allowing connections from misconfigured > > servers that are being exploited to do bad things. > > But what is "misconfigured"? How do you define that from a technical > level? How do you identify that? > > I agree that "servers that are being exploited" is something that can be > identified and evidence of bad behavior. > > I don't agree that simple mis-configuration without any exploit is a threat. > > E.g. what grounds do you have to block an Exchange 5.5 system someone is > running in their home lab protected from the internet and sending three > pieces of legitimate email a week? > > This seems tantamount to states saying that you can no longer drive cars > that are more than X years old. Even if they are in pristine condition. > > This is borderline oppression to me. > > Conversely "being exploited" is demonstrable and justifiable. > > We have an analogy in the legal system; the police can't act until > /after/ a crime has been committed. There are different and longer > processes that must be gone through to take action before a crime has > been committed to revoke people's rights. > > > This seems like a good thing to help both reduce the exploitable > > damage that can be done by these servers and also nudge their admins > > to wake up and patch up or shut down. > > Each admin has the right to run their email server the way that they > want to. -- This includes both running ancient software. This also > includes the right to refuse to allow a system to connect to send email. > > But how do you identify the aforementioned Exchange 5.5 from > contemporary Sendmail, both of whom are speaking perfectly valid RFC > compliant SMTP by all contemporary rules? > > And what grounds do you have to object to the Exchange 5.5 if it's doing > nothing wrong while allowing spam from a breached account behind the > contemporary Sendmail system? > > > Reminds me a bit of blocking open relaying mail servers back in the > > day. > > Not really. > > Blocking open relays was a binary test of openness and blocking if it > was open. Any MTA, new, old, beta code, or ancient bits must all adhere > to the test the same way. > > Simply deciding that something's too old to play is a very bad thing in > my opinion. You're sort of trying to argue me out of agreeing with you. Here's the parallels I see. A Sendmail server so old that it can only be an open relay. Block it proactively? Or block it only after it has been exploited? An Exchange server so old that it HAS to be vulnerable to XYZ spam relay exploit. Block it proactively? Or block it only after it has been exploited? I find it a "grey area" because it feels wrong at some level to block without evidence of being exploited. Which is what I thought your point was. But we're all debating for debate club's sake. Who gives a shit what we think? It's not our call. Their server, their rules. I'm going to spend only the TINIEST amount of time shaking my fist at the sky. Regards, Al Iverson -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Tightening of delivery rules for Exchange Online
> On Tue, 2023-03-28 at 17:04 +0200, Tobias Fiebig via mailop wrote: > > > > Are there any other thoughts on this? Eventually we have to stop allowing connections from misconfigured servers that are being exploited to do bad things. This seems like a good thing to help both reduce the exploitable damage that can be done by these servers and also nudge their admins to wake up and patch up or shut down. Reminds me a bit of blocking open relaying mail servers back in the day. Like back then, I do worry about blocking servers that may not have been used for badness. If it's only that they COULD be abused, it's a little more grey area to reject mail from them versus they HAVE been abused. But also, their server, their rules. Meaning I think Microsoft has the right to do this, regardless of how we might feel about it. Cheers, Al Iverson -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Hotmail will start rejecting messages that fail DMARC
This is great to hear. Thanks very much for sharing! Cheers, Al Iverson On Wed, Mar 22, 2023 at 9:31 AM Jeff Dellapina via mailop wrote: > Hey Mailop, > > > > Microsoft is proud to announce our Consumer email service > (Outlook/Hotmail/MSN/Live) *will now honor the DMARC record of > “p=reject” by rejecting the message if the domain fails DMARC*. > Previously, messages that failed DMARC were sent to the junk folder > (Quarantine). Over the next 30 days these DMARC-failing messages will be > rejected. > > > > If you see any problems with our Consumer platform, please create a > support ticket here https://olcsupport.office.com/ > > > > Thanks, > > Jeff Dellapina > > > > > > Thanks, > > Jeff Dellapina > > > > Sr. Email Delivery Manager > > SAGE Team > > > ___________ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail blocking of good customer
> This appears to be a specially built MTA, and with the (probable) > consent of its users, has policy in place to not resend after 4xx under > specific conditions. I.e. the sending MTA is interpreting specific 4xx > responses (and more likely the text) to mean a permanent failure. > > I do not see a problem with elevating a 4xx to mean 5xx where the users > of the system understand the policy as it does not appear to impact the > receiving system. In fact one could take section 4.5.4.1 of RFC5321 to > opening the door for just that; "[...] however, more sophisticated and > variable strategies will be beneficial when the SMTP client can > determine the reason for non-delivery." Agree. Also, I think it's unreasonable to assume that people will never try new things when it comes to bounce processing or MTA queue management. RFCs could never evolve if folks were prohibited from ever trying anything different than what's written in the RFCs today. Many large sending email platforms have had unique MTA handling rules in place for years. And there are a lot of reasons smart platforms HAVE to, going all the way back to (pulls note out of greybeard, checks) stuff like Cisco PIX firewalls causing email bombing -- not a 4xx/5xx handling issue, but an example of how going back for 20+ years, weird shit has sometimes happened that required workarounds. Those workarounds are not always based on a sender's intent to get away with something. Often the intent is to do better, be better-- not to be sneaky. -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Cyren
This is a good hypothesis but so far I have not seen any absolute confirmation that they are "listing the world." I guess we will see... Cheers, Al Iverson On Mon, Feb 13, 2023 at 2:53 AM Benoit Panizzon via mailop wrote: > > Hi All > > I have started seeing a lot of emails sent via one Swiss ISP flagged as > spam by the SpamAssassin CTASD, which according to Google, is Cyren's > anti spam service. > > Have they started flagging all emails as spam to tell their customer to > stop using their service? > > Mit freundlichen Grüssen > > -Benoît Panizzon- > -- > 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 -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM record IONOS
The DKIM public key is technically a TXT record. Some people do use a CNAME version, but then yeah, you put in the hostname of the real server (real DNS entry) that has the TXT entry. So in your case, you’re probably looking to paste that key value into the TXT record. Your selector is “k1” in this example. That sounds right based on Googling the iONOS instructions, I think. Cheers, Al Iverson > On Feb 9, 2023, at 6:41 PM, H via mailop wrote: > > Having successfully created a SPF record for my domain hosted by Ionos, I now > wanted to create a DKIM record but have received two completely different > answers from Ionos. > > The first instruction I received was to create a CNAME record, enter > k1._domainkey in the Host field, and then a key the Value field. Well, there > is no Value field, only a Points To field and that seems to accept another > domain name, not a key. > > I then called the helpline and was told to create a TXT record, keep the Host > Name field unchanged from the default suggested by Ionos and then enter the > public DKIM key in the Value field. IOW, no particular selector to be > entered. Upon inquiring how to use the private DKIM key they told me I do not > need it for anything... > > By the way, I used easyDmarc.com to create the public/private key pair. > > Clearly at most one of the above can be correct - or possibly none of the > two... > > If anyone could set me straight, it would be greatly appreciated. > > Thanks. > > ___ > 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] Feedback Loops and Sub-Domains
Good advice from Luca. As far as reporting address, he’s saying, have an FBL-specific one that feeds into automation if possible. That being said, it can be ONE address for ALL domains/clients, if your automation can parse the messages to denote the client and recipient info. So you could set it up to be fblrepo...@fbl.talent.com <mailto:fblrep...@fbl.talent.com> for ALL of your clients - no need to worry about different domains for different clients. Thus, you’d register this address for every single FBL for Validity, MSFT, Yahoo, etc. (There is no Gmail FBL.) You might want to do a subdomain like I’ve shown here - “fbl.talent.com <http://fbl.talent.com/>” so you can bypass any spam filtering that your corporate top level domain may enforce. Cheers, Al Iverson > On Feb 8, 2023, at 11:36 AM, Support 3Hound via mailop > wrote: > > Hi Jeff, > as the FBL bring back to you (usually in ARF format) every reporting > user/mail, I suggest you to "link" the FBL address to an automatic ARF parser > that permanently unsubscribe users (maybe following the "one click > unsubscribe" header) and give back you a feedback report in order to prevent > abuse from customer/user/form-injectors etc... > > Note that especially on some providers, most user "feel" the reporting as a > sort of "fast unsubscribe"... (I don't want to scroll the whole mail; I don't > want to "investigate" the sender is really who is expected to b; I just trust > on my own mailbox provider and click Junk/Spam without loose a second more). > > Based on your mailing practice/amount FBL may send you a lot more daily > messages than the expected so, mixing it with the abuse mailbox (typically > manually managed to reply to other postmasters) may became an hard work to be > handled manually. > > Hope it may help you, > Luca > > > Il 08/02/2023 18:01, Jeff Ginsberg via mailop ha scritto: >> Hello Mailops!!! >> >> New to the list so any help would be appreciated. >> >> When setting up feedback loops is it best practice to use abuse@domain as >> the reporting address? >> >> If we use the main domain and a series of sub-domains do I need to setup >> abuse@sub-domains as the reporting address too for each sub or can they all >> forward to the parent abuse@domain? >> >> Besides the obvious are there any other FBLs I should register for if we are >> mailing globally? >> >> Validity FBL >> Microsoft >> Google >> Yahoo >> >> >> Any insights welcome. >> >> Thanks, >> >> Jeff Ginsberg >> Email Deliverability Manager >> jeff.ginsb...@talent.com <mailto:jeff.ginsb...@talent.com%0d> >> www.talent.com <https://www.talent.com/> >> 416-706-7711 >> >> <https://www.talent.com/> >> >> >> >> ___ >> mailop mailing list >> mailop@mailop.org <mailto:mailop@mailop.org> >> https://list.mailop.org/listinfo/mailop > > ___ > 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
Re: [mailop] Forged Yahoo/Gmail etc. Senders - Recommendations for Blocking
DMARC would have blocked that, for starters. Yahoo has a p=reject policy. If you want to get customized and aggressive it might be useful to manually build a list of known freemail addresses - or at least the top MAGY ones (Microsoft/Apple/Gmail/Yahoo) and reject them if they don't pass SPF. I have a list of all the MAGY domains on my blog, if you need one. Cheers, Al On Thu, Jan 26, 2023 at 8:06 AM L. Mark Stone via mailop wrote: > Looking for input from the hive mind on this list as the best way to > handle this challenge please... > > By way of background we are a niche B2B email hosting company. > > Essentially, we have started to see what we think are either email address > verification firms and/or bad actors trying many variations of a supposed > username. These username don't exist, so the emails are blocked. But > eventually, we expect some will get through (if some haven't already and > been blocked as spam further down the chain...). > > Question: What is the best way to block senders that look like this: > > Jan 25 16:42:46 my postfix/smtpd[14370]: NOQUEUE: filter: RCPT from > ec2-54-174-191-201.compute-1.amazonaws.com[54.174.191.201]: < > jl860vv...@yahoo.com>: Sender address triggers FILTER > smtp-amavis:[127.0.0.1]:10024; from= > to= proto=SMTP > helo=<[127.0.0.1]> > > Thanks in advance, > Mark > _ > *L. Mark Stone, Founder* > > *North America's Leading Zimbra VAR/BSP/Training Partner* > *For Companies With Mission-Critical Email Needs* > > > _______ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Using cloud hosts for MX (not SMTP)
Alberto, I do exactly as you are suggesting — I host inbound email on a Google Cloud instance (and I did so previously on an AWS EC2 instance). Neither allows port 25 outbound. I relay outbound SMTP through an existing VPS I’ve had at another ISP for years. It works fine. Cheers, Al Iverson > On Jan 17, 2023, at 8:57 PM, Jarland Donnell via mailop > wrote: > > Though it's possible that you may see this more with governments and such, > I've not noticed that anyone significant blocks their own traffic outbound to > OVH, except for a couple of military contractors (which isn't my definition > of significant to any average person). If they block anything it's usually > blocking their own inbound email which came from an OVH IP, rather than their > own outbound email headed toward an OVH IP. > > On 2023-01-17 20:34, Alberto Abrao via mailop wrote: >> Hello, >> first message to this list. I have been lurking for a while, and I learned a >> lot here. Thank you. >> I operate a personal e-mail server, and, as soon as I started self-hosting, >> I requested a static IP from my ISP, moving records as I changed to a >> different provider. >> During the move, I was relying on the "retry" period of the SMTP protocol, >> which worked just fine. >> Still, it generates an error message to the sender. I was looking to "split" >> my server, having the MX (inbound) at a cloud provider (OVH), and keeping >> outbound SMTP on the IP provided by my ISP. >> I see many posts saying that e-mails from cloud providers such as OVH are >> blocked outright by many. That had me wondering if it's a good idea to >> proceed with this plan, as I may not be able to receive messages from >> senders under these operators. >> That'd assume the block is inbound and outbound, instead of inbound-only. Is >> that the case? >> One more thing, would a set up like this interfere with my "score", so to >> speak? >> Once again, thank you. >> Kind regards, >> Alberto Abrao >> ___ >> mailop mailing list >> mailop@mailop.org >> https://list.mailop.org/listinfo/mailop > ___ > 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] gmail putting most messages into Spam
A (wanted) notification from Google's Blogger service to me went to spam this morning, which is new and unique. But it talks about email auth, and spam, so I'm not 100% sure it's related. I'd love to see an example of this -- anybody affected, feel free to email me off list? This address (aiver...@wombatmail.com) is Gmail. Thanks, Al On Tue, Jan 17, 2023 at 8:32 AM Mark Alley via mailop wrote: > > Just to clarify - Do you mean from Proofpoint enterprise (PoD) customers or > Proofpoint essentials? I could definitely see essentials having this problem > as their IP space is shared amongst customers, but PoD clusters each > individually have their own IPs that are separate from any other customer. > > On 1/17/2023 8:15 AM, Jeff via mailop wrote: > > We too have been seeing this in the last 48 hours > > Only from clients sending out from Proofpoint though and Google is > marking them as Spam for the reason "Blatant Spam"... when they are clearly > not > > We have tickets open with all relevant providers (Proofpoint and Google) to > see if we can figure this out > > On Tue, Jan 17, 2023 at 9:10 AM Jaroslaw Rafa via mailop > wrote: >> >> Dnia 17.01.2023 o godz. 13:16:03 Paul Gregg via mailop pisze: >> > Heads up in case anyone else is experiencing this. >> > >> > We are aware of a recent change in behaviour of gmail.com where >> > most email is placed directly into Spam folder. >> > >> > So far we have dozens of customers reporting this. >> > Tested myself with full SPF, DKIM and DMARC with p=reject - which gmail >> > itself marks as passing all tests. The mail was also delivered over TLS. >> > Mails go to Spam. >> > >> > We're trying to reach out to google, but so far have no response. >> > >> > We don't think it is just 'us', as reddit r/msp has others reporting >> > same from O365 direct to gmail. >> >> Welcome to the club :( >> >> I'm experiencing this for over 2 years. Have written about this on this very >> list a few times. Google just suddenly stopped to "like" my domain. I had >> no SPF, DKIM nor DMARC at that time (despite this I didn't have any >> deliverability problem, including Google). After Google changed something >> and started to spam-mark my mail I implemented SPF/DKIM/DMARC (outgoing >> only, I don't want to bother with checking this crap on incoming mail). >> Everything passes at Google, but it doesn't help. >> >> However, when I send from exactly the same server, using exactly the same >> mail client, only with diferent sender domain, the mails go through. So I >> know it's the domain Google doesn't like. >> >> Nothing helps - even when the recipient at Gmail flags my mail as non-spam, >> it can happen that next messages from me still go to spam. Even when I REPLY >> (!) to a mail I got from a Gmail user, my reply goes to spam, which is >> completely illogical. It should be obvious for Google to detect that this is >> a reply to a message that was previously sent from Gmail. >> >> I have filled in the "sender troubleshooting form" on Google website >> multiple times (you need to provide headers from receiving side of the mail >> that was misclassified as spam, so I made myself a test account at Gmail >> that I am sending messages to) - however they state in advance that they >> won't contact you and inform you whether they did anything or not to your >> complaint. Looks like they didn't do anything. I managed to reach Brandon >> from Google via this very list, but he said that it just works so and from >> their point of view they don't see any reason to change anything. I just >> happen to have a domain whose parent domain has a "poor reputation" and I >> have to accept it. >> >> I even made a blog post about it some time ago, but it's in my language (ie. >> Polish). After that post I was contacted by some other people who are >> unlucky to be in the same situation. >> >> Shame on you Google. >> -- >> Regards, >>Jaroslaw Rafa >>r...@rafa.eu.org >> -- >> "In a million years, when kids go to school, they're gonna know: once there >> was a Hushpuppy, and she lived with her daddy in the Bathtub." >> ___ >> mailop mailing list >> mailop@mailop.org >> https://list.mailop.org/listinfo/mailop > > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Simple mailing list expander program for aliases files?
I've been doing something similar for a good long time. Blogged about it here: https://www.spamresource.com/2015/12/mail-forwarding-in-dmarc-world.html The current version of my forwarding script rewrites the from address, disables the authentication headers (re-authenticating the message anew upon sending), rewrites the message ID (which I found to be very handy if you want to re-forward the same message more than once, either in testing or in real life) and I usually drop the original sender's address both into a hidden x-header and the reply-to header. Cheers, Al Iverson On Wed, Jan 11, 2023 at 2:53 AM Hans-Martin Mosner via mailop wrote: > > I've written something like that a while ago. It's in Rust, it's probably too > specialized and restricted for general use, but it does mostly what you > describe (in addition, it keeps sender addresses secret becaue I've > encountered too many cases of hacked e-mail accounts where address books have > been exfiltated). > I chose Rust because, well, I'm doing much of my side project hacking in Rust > nowadays, and it creates stand-alone binaries which simplifies deployment on > arbitrary Linux servers. The data is held in a simple sqlite database, and > the binary serves both as the actual forwarding filter as well as database > management tool, so it's somewhat scriptable. > I could clean it up a bit and put int into my github account, but as I said, > it's probably not general enough and would need some polishing before being > ready for public consumption. > > Cheers, > Hans-Martin > > 10. Januar 2023 22:59, "Dan Mahoney via mailop" schrieb: > > > All, > > > > Sometimes a problem comes across your desk that you say “wait, how is this > > not solved yet?”. > > > > At the day job, we have a contact list for our customers that comes from > > our ticket system, and > > it’s stuffed into an alias file with :include:. > > > > The way postfix handles these aliases, is that it preserves the original > > envelope sender and > > recipient (which we don’t want anyway), and o365 is rejecting on that > > envelope sender/recipient > > (that it’s not allowed to deliver to our internal envelope recipient, which > > is not unreasonable, > > but still surprising we haven’t hit it before. > > > > The obvious answer is: “Don’t use the :include: mechanism, just use a > > mailing list manager.” Which, > > for one alias in a system, feels like overkill. I don’t need membership > > management. I don’t need > > archiving. I don’t need bounce detection. > > > > So I’ve gone down the rabbit hole, looking for various combinations of > > remailer scripts, forwarder > > scripts, group forwarder scripts, mailing list expanders, etc. And I’m > > coming up surprisingly > > short. > > > > Could I knock something together myself in perl in a half hour? Sure. > > > > Would it likely have its own untested edge cases for us to discover? > > Absolutely. > > > > In a world of DKIM/DMarc compliance, especially, where “blow away the > > original headers and forward > > anew” is the best answer, I’m shocked to not find something like this as > > well. > > > > Our needs are simple: a unix program we can pipe a message to that will > > preserve the original > > message mime portions and subject, but discard most of the previous other > > headers. How in 30 years > > of email, something that I can’t just pkg install isn’t easily findable > > baffles me. > > > > If someone knows of something, let me know. > > > > -Dan > > ___ > > mailop mailing list > > mailop@mailop.org > > https://list.mailop.org/listinfo/mailop > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamhaus DNS issues causing all incoming mail to drop for me
I'm glad you were able to get it figured out. I'm using Spamhaus to block mail to my Postfix server via the DQS process and it's working perfectly. Cheers, Al Iverson On Fri, Nov 4, 2022 at 1:23 PM Brian Knight via mailop wrote: > > I've got a Postfix server (it's a flurdy build) that hasn't had > smtpd_recipient_restrictions set properly, hence the drops. I'm > currently waiting to get my DQS key before making the config change. > > (Ivar, if you're reading, this would be a great thing to put in the > guide!) > > Thanks! > > -Brian > > > On 2022-11-04 12:28, Jarland Donnell via mailop wrote: > > Indeed they shouldn't. The most noteworthy implementation that seems > > to treat these as false positives is cPanel, I believe. Every single > > day we run into no less than 3-5 servers which reject emails from us, > > claiming that we're listed on SH. They seem to almost always be cPanel > > boxes. > > > > On 2022-11-04 08:11, Jaroslaw Rafa via mailop wrote: > >> Dnia 4.11.2022 o godz. 12:52:44 L. Mark Stone via mailop pisze: > >>> > >>> Queries to spamhaus.org from the public DNS resolvers fail, leading > >>> to > >>> false positives. > >> > >> They should not lead to false positives, because one should not treat > >> the > >> results Spamhaus returns in this case (127.255.255.254 or > >> 127.255.255.255) > >> as positives at all. Positive replies from Spamhaus (in case of IP > >> address > >> checks) are in range 127.0.0.0/24 ONLY, which is clearly explained > >> here: > >> https://www.spamhaus.org/faq/section/DNSBL%20Usage#200 > > _______ > > mailop mailing list > > mailop@mailop.org > > https://list.mailop.org/listinfo/mailop > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Recommendations for host with good IP reputation or use external SMTP?
I mentioned this to Ian offline, but I'll mention it here, too. I would be happy to try relaying for small hobbyist senders; feel free to reach out if you're interested. (And if you asked before, but I demurred because I wasn't ready, now I think I'm ready.) I've got my own SMTP server handling 1:1 mail for my domains and some newsletter and discussion mail, and I rarely have any deliverability issues. So, relaying through a server like mine could help in a scenario like this. Cheers, Al On Mon, Oct 31, 2022 at 7:53 PM Ian Evans via mailop wrote: > > > > On Mon, Oct 31, 2022, 7:33 PM John Levine via mailop, > wrote: >> >> It appears that Grant Taylor via mailop said: >> >-=-=-=-=-=- >> >-=-=-=-=-=- >> > >> >On 10/30/22 5:35 PM, Ian Evans via mailop wrote: >> >> DO admits their IP reputation sucks and so won't intervene with >> >> vadesecure on behalf of my IP. >> > >> >I'm surprised and disappointed that Digital Ocean won't do anything to >> >vouch for "yes, this customer is using this IP, and has been for $TIME". >> >> I get so much spam from DO that I've blocked all of their ranges, with >> no user complaints so far. I would not dream of putting a mail server there. >> >> There are plenty of smaller places with a clue. I like Tektonix, small, >> good customer services. >> > > Thanks for the suggestion. I'll give them a look. >> >> > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Only Yahoo deferring mail
Go submit a ticket here - https://senders.yahooinc.com/contact I assume there's a TS04 code in that error message. It is indeed likely due to user complaints, but they have something of a hair trigger for IPs not known to them. They ought to be able to get you sorted out. Assuming you have a limited number of DKIM domains in play, register them all with the Yahoo feedback loop. Find info on that same website. The Yahoo FBL is DKIM-based. It's meant for big bulk senders, but I suspect it may give you a modest boost when it comes to reputation. More importantly, you'll be able to see which goober is complaining about legit mail. Assuming you're very low volume and not an ESP/CRM platform, you're probably wondering where should FBL complaints go? In my case, I just have them sent to an alias at my domain that for now comes to me for manual review. With the intent that if it grows too big to handle, I can redirect the alias to automation later. It works fine; I get the occasional complaint about a jazz newsletter I send out and I just manually unsubscribe anyone who complains. Is this new? Yahoo does adjust filters regularly but overall this kind of issue/process is not really anything new. This isn't futile; it's easily fixable. It can just feel a bit overwhelming or unfair for smaller or hobby senders. Regards, Al Iverson On Sat, Oct 29, 2022 at 10:39 AM Nate Burke via mailop wrote: > > I know it may be futile, but I thought I'd ask. Starting late Tuesday > afternoon, Yahoo has started deferring all email from my server. All > other internet domains are fine except for yahoo properties. There was > no increase of mail from my server that I can find. The only messages > in the outbound queue are waiting to be delivered to Yahoo, and are all > legitimate messages. And there's only about 160 of them. The Yahoo > error is just 'Messages from 66.151.xx.xx temporarily deferred due to > unexpected volume or user complaints' There was no increase in mail > volume on Tuesday before this error started. > > All IPv4 traffic > > SPF/DKIM seem to be functioning properly. I get the daily report from > Yahoo DMARC and it reports that the Server IP Address passes SPF/DKIM > > Did Yahoo institute a new policy this week that I've missed setting up? > > Thanks, > > Nate Burke > > Blast Communications > > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Bounce Address Tag Validation (BATV) versus Spam Filtering
I don't know that non-matching return path/from are something you truly have to solve for. At the domain level, it's addressed by DMARC. At the exact email address level, any mailing list software, ESP or CRM tool that uses VERP to help with bounce processing is going to have a mismatched return-path/envelope sender. IMHO, hasn't really been a good spam sign for a good long time. Cheers, Al On Thu, Oct 13, 2022 at 9:22 AM Matthew Richardson via mailop wrote: > > I have an issue with email from one domain being repeatedly mis-classified > as spam by assorted receivers, including Messagelabs. > > Looking at their outgoing email, I notice that it uses BATV, the Internet > Draft https://datatracker.ietf.org/doc/html/draft-levine-smtp-batv having > been written by folks who frequent these part. > > Whereas the "From:" header would read:- > From: First Last > > the envelope address would read:- > btv1==278381d6d8b==first.l...@example.com > > My understanding is that this BATVing is being undertaken by a Barracuda > appliance through which outgoing email is routed. > > Would folks anticipate that doing this would somehow make outgoing email > look more spammy than with a matching envelope address. > > -- > Best wishes, > Matthew > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Email Cloud Providers
I'd look at Fastmail. That's where I'd go if I wanted to avoid Google, and if I didn't want to set up my own server. Cheers, Al On Tue, Sep 20, 2022 at 2:59 PM 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? > > > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Discover bank billpay from NXDOMAIN
Abuse.net suggests ab...@fidelity.com for Fidelity.com and techad...@discoverfinancial.com for Discover.com, so those would be worth trying, even though this isn't really an issue of abuse. I'd probably also add in nssd@fisglobal.com from the contact info for that Fidelity IP block, found via ARIN. Cheers, Al Iverson On Fri, Sep 16, 2022 at 4:24 PM Daniel J. Luke via mailop wrote: > > I run a smal mail server for friends/family (with a couple of tiny mail lists > for local clubs). I noticed that I was rejecting discover.com bank's billpay > messages as they MAIL FROM billpay.discover.com, which doesn't appear in DNS. > I've worked around this locally, but it would be nice if they sent email from > a domain that existed (they also set Reply-To to > disco...@billpay.discover.com). > > I tried contacting them (through their customer 'secure mail') - where they > told me that it was not email from them (I'm sure that it actually is). I > followed up and they claimed to have raised the issue internally, but I > haven't seen any change in behavior. Mail to > postmaster@(discover.com|messageprovider.com) also yielded no response. > > Does anyone have a way to get a message to discover.com and/or Fidelity (who > appears to be running their billpay)? > > example headers follow: > > Return-Path: > Delivered-To: dl...@geeklair.net > Received: from vroomfondel.geeklair.net > by vroomfondel.geeklair.net with LMTP > id eBc9BliGJGOKgQEA37bTsg > (envelope-from ) > for ; Fri, 16 Sep 2022 10:21:12 -0400 > Received: from mx4.messageprovider.com (mx4.messageprovider.com > [156.55.193.213]) > by vroomfondel.geeklair.net (Postfix) with ESMTP id E85F16279B5E > for ; Fri, 16 Sep 2022 10:21:11 -0400 (EDT) > Received: from pps.filterd (PDC1LLPIP1AAP12.prod.local [127.0.0.1]) > by PDC1LLPIP1AAP12.prod.local (8.17.1.5/8.17.1.5) with ESMTP id > 28G9wAtW063819 > for ; Fri, 16 Sep 2022 06:22:11 -0700 > Received: from pdc2rmmsbrws07.localdomain (pdc2rmmsbrws07.prod.local > [10.236.79.68]) > by PDC1LLPIP1AAP12.prod.local (PPS) with ESMTP id 3jm9a3vr43-671 > for ; Fri, 16 Sep 2022 06:22:11 -0700 > Received: from pdc2rmmsbrws07 (localhost [127.0.0.1]) > by pdc2rmmsbrws07.localdomain (Postfix) with ESMTP id C6D26404740 > for ; Fri, 16 Sep 2022 08:22:11 -0500 (CDT) > Date: Fri, 16 Sep 2022 08:22:11 -0500 (CDT) > From: disco...@billpay.discover.com > Reply-To: disco...@billpay.discover.com > To: dl...@geeklair.net > Message-ID: > <1290698337.1048672.1663334531811.JavaMail.wasadmin@pdc2rmmsbrws07> > Subject: Notification - Discover Bank Bill Payment account activity > MIME-Version: 1.0 > Content-Type: multipart/mixed; > boundary="=_Part_1048670_-727044986.1663334531811" > X-Proofpoint-Virus-Version: vendor=baseguard > engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.528,FMLib:17.11.122.1 > definitions=2022-09-16_08,2022-09-16_01,2022-06-22_01 > > -- > Daniel J. Luke > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] The oligopoly has won.
I've got strong feelings about this one. I recently moved some of my domains off of Gmail and it's been great to add more granular filtering directly and watch mail bounce. So I'm hosting inbound mail. And I forward a bunch of mail. And I host a handful of mailing lists, so I've got a server with great IP reputation that has few deliverability issues and it dawns on me that I'm already running all the pieces of a mailbox provider, so I ought to just pull the trigger and make my own full one. Because I disagree with the whole premise that self hosting mail is impossible today and I have enough proof from my own experience that it works fine if you follow best practices and don't grow crustry and stop evolving your knowledge while best practices keep on evolving. So I'm going to go deeper into it, not run away from it. Wish me luck. Cheers, Al Iverson -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] mailbox.org down?
It's all responding for me; their website, IMAP endpoint, and SMTP injection endpoint. Regards, Al Iverson On Wed, Sep 7, 2022 at 6:06 PM John Von Essen via mailop wrote: > > For the last 15 mins or so. Website is down, and smtp/imap endpoints are > down, MX is down, etc.,. Like their network just dropped off completely… > > -John > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail spam scoring via IPv6 different than IPv4?
Hey Jesse, This is sort of controversial and you'll get some people saying very vehemently that you should never do this ever, for various reasons of interoperability or strong opinions about how the internet works. But instead, here's my take from an operational perspective... I personally would keep forcing mail to Gmail over IPv4, and I do indeed do this on my own hobbyist systems. Every time I spin up a new VPS and forget this, I notice it rather quickly because of bouncing mail. Not only are they quicker to block IPv6 mail overall (IMHO), they also are more likely to block IPv6 mail from IPs without rDNS, and mail that lacks either SPF or DKIM authentication. Their filters are evolving and it feels as though their IPv4 blocking is catching up a bit -- more likely to block unauthenticated IPv4 mail today versus a year or two ago, but that doesn't really mean it suddenly became easier to send over IPv6. I blogged about this a couple year ago - nothing you don't already know, really - https://www.spamresource.com/2020/11/honestly-dont-send-to-gmail-over-ipv6.html - but recently that article got linked to on Reddit and a bunch of nerds made noise that I don't know what I'm talking about and that they can get mail to Gmail over IPv6 just fine. So, YMMV. (My point is that it's not impossible, but it is annoying and that it has exacting, but unclear requirements.) Cheers, Al Iverson On Fri, Aug 12, 2022 at 11:26 AM Jesse Hathaway via mailop wrote: > > Back in 2013[1] we changed our mail config to force MX lookups for gmail > to only use IPv4 addresses. We made these change after hearing reports > of higher spam scoring when sending mail via IPv6. Would anyone from > Google be able to comment as to whether forcing IPv4 is still needed? > Yours kindly, Jesse Hathaway > > > [1]: https://gerrit.wikimedia.org/r/c/operations/puppet/+/79753 > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Microsoft Sending DMARC Reports From IP In SBL
On Mon, Jul 25, 2022 at 3:25 PM Matt Corallo wrote: > On 7/25/22 3:58 PM, Al Iverson via mailop wrote: > > On Mon, Jul 25, 2022 at 2:37 PM Matt Corallo via mailop > > wrote: > > > >> I don't believe SA does authentication checks on all Received: lines, no, > >> it only runs them through > >> the various DNSBLs. I don't see why "you relayed mail from something in a > >> DNSBL" should be avoided > >> as one of the many signals in spam classification. Just because some other > >> server decided it wasn't > >> spam doesn't mean I should accept their classification, and more signals > >> doesn't generally hurt, at > >> least properly tuned. > > > > The signal in question is not properly tuned. > > Given the general signal:noise ratio of the SBL lists, and that looking up > relays in SBL does catch > some nontrivl amount of spam, I'd argue its the other rules that triggered on > this mail that are not > properly tuned, not the lookup relays in the SBL. I hear you, but I counter with the argument that 5.7-3.3=2.4. I also note that the SBL listing is actually an XBL listing, and the reason for the listing is because the server is helo'ing as microsoft.com. Which doesn't strike me as abusive behavior for a Microsoft server that does in fact relay mail. So, it's not only a DNSBL check being done in a way that is out of spec, but it's essentially a false positive listing to begin with. Cheers, Al Iverson -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Microsoft Sending DMARC Reports From IP In SBL
On Mon, Jul 25, 2022 at 2:37 PM Matt Corallo via mailop wrote: > I don't believe SA does authentication checks on all Received: lines, no, it > only runs them through > the various DNSBLs. I don't see why "you relayed mail from something in a > DNSBL" should be avoided > as one of the many signals in spam classification. Just because some other > server decided it wasn't > spam doesn't mean I should accept their classification, and more signals > doesn't generally hurt, at > least properly tuned. The signal in question is not properly tuned. -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Did Google become stricter about RFC 5322?
Yeah, I'm not seeing Google be "hostile" to mailing lists if the mail fully authenticates properly. I've felt mailing lists and authentication and Gmail were a solved problem, at least from my perspective, for a number of years now. What bit me recently was a bug, not some pushback against my business model. Cheers, Al On Wed, Jul 13, 2022 at 10:47 AM Mark Fletcher via mailop wrote: > > On Wed, Jul 13, 2022 at 8:29 AM Miles Fidelman via mailop > wrote: >> >> It's been over a month now, since Google became hostile to email lists. >> I'm still dealing with the aftermath. >> > How so? We haven't seen any issues. > > Mark > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Did Google become stricter about RFC 5322?
I've gotten bitten by this too, as I had my homebrew mailing list manager intermittently generating messages with two message ID headers -- but not in the past few days -- more like a couple of months ago. So it could be new-ish, I guess. Cheers, Al On Wed, Jul 13, 2022 at 5:34 AM Philip Paeps via mailop wrote: > > On 2022-07-13 17:52:33 (+0800), Laura Atkins wrote: > > 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. > > For fans of anecdata... :-) > > The duplicate Date: header was introduced on 2021-06-05 at 11:00:56 UTC. > > As far as I can tell, we saw our first reject on 2022-07-08 at 23:15:18 > UTC. > > We only keep 7 days of outbound logs and this this particular script > only sends a handful to a few dozen messages daily. A slow enough > trickle for patterns to take a while before becoming obvious. > > Philip > > -- > Philip Paeps > Senior Reality Engineer > Alternative Enterprises > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Moving email server to new IP
IP rep is a big deal, still. You might want to keep the existing IP. Or if you do plan to keep it, relay mail from your new server through it. SMB/low volume mail is the trickiest to sort of IP warm correctly, so I honestly expect you'll have some pain. Here and elsewhere you'll find people complaining that Gmail is completely unfair to the small volume sender. Sounds like you're smarter than most, but it's still tricky, both with Gmail and Microsoft. I'm having similar concerns myself, as I move a lot of what I do into AWS, I don't want to lose the sending reputation of my legacy hosted server that I've had for years, so I'm going to keep it, basically just as a mail relay. Cheers, Al Iverson On Thu, Jul 7, 2022 at 12:48 PM Nate Burke via mailop wrote: > > I've had a small multi-domain business mail server running on the same > IP for the last 20 years, I need to change the IP from an address in a > reassigned IP block, to my own ARIN block. Is IP reputation still a big > deal, or are anti-spam measures now content/quantity based and the IP > address isn't as important anymore. Can I just flip the IP and update > my DNS/SPFs and be good. > > Thanks, > Nate > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Microsoft Announces Tenant Trusted ARC Seal
On Mon, Jun 20, 2022 at 11:41 AM Paulo Pinto via mailop wrote: > > >ARC is motivated by the cases where DKIM/SPF/DMARC information about the > >author/originator get broken. > > I'm truly trying to find a justification to break DKIM/SPF on a message after > it is sent. I don't know why people do it, but what I see is people want to run multiple email spam filters or security services or tools. Like, their domain's MX points to Proofpoint, then Proofpoint forwards that mail on to Google for Business. That second step results in Google checking SPF results (as it would typically do) but those fail because it is not the edge server any longer. A use case that this potentially helps solve. <- My prior employer was configured this way and it was very annoying to see SPF fail in header results and have to explain this to people constantly that it was an inbound configuration choice, not an indication of failure. > SPF -> You should be aware of all the servers that can be involved in the > message transaction so no excuse to not have them reflected in the SPF record SPF is a last hop methodology. Forwarding adds hops that are outside of your control. It'd be bad to just add random forwarding IPs to your SPF record. > DKIM -> The message should only be signed after it is complete and leaving > your controlled environment. Any modification to the message afterwards is > tampering and should not happen. But it does happen, sometimes intentionally, sometimes not. 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. ARC for enterprise email security chaining, though, I think that use case makes sense to me. I personally wouldn't configure things this way, but people do it, so it is good that there is a way to handle "passing authentication results forward," if you wish to trust the prior hop's ARC results. Cheers, Al Iverson ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] digilabsvc.com?
Google was giving me results for another company in India with a very similar name. Yay, autocorrect. Digging into yours again, I find these related entities: rdcom.com and klsvc.net RDCOM appears to be some sort of Italian email marketing provider. Perhaps they're your spammer or perhaps your spammer is their client. Cheers, Al Iverson On Sun, Jun 19, 2022 at 9:20 AM Daniele Nicolodi via mailop < mailop@mailop.org> wrote: > On 19/06/2022 00:16, Al Iverson via mailop wrote: > > Data points: > > - Supposedly a digital marketing company based in India > > India? It looks like they are based in Italy to me. And even then, I > don't think geographical location is much of an indicator, considering > that the companies most often associated to bad behavior on this list > are US based. > > Cheers, > Dan > > > - Their website has an SSL issue > > - I see no other mentions of them in 20 years of email discussion > > history talking about spam or email marketing. Which I guess means > > they're not necessarily well known spammers in my universe, but also, > > they're not coming up as a known "legitimate" business in any way that I > > can see. > > > > Verdict? Recycle bin, IMHO. > > > > Cheers, > > Al > > ___________ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] digilabsvc.com?
Data points: - Supposedly a digital marketing company based in India - Their website has an SSL issue - I see no other mentions of them in 20 years of email discussion history talking about spam or email marketing. Which I guess means they're not necessarily well known spammers in my universe, but also, they're not coming up as a known "legitimate" business in any way that I can see. Verdict? Recycle bin, IMHO. Cheers, Al On Sat, Jun 18, 2022 at 5:23 AM Daniele Nicolodi via mailop < mailop@mailop.org> wrote: > Hello, > > I am getting quite a few spam messages from the domain in the subject, > all in Italian and all with the same content structure. Does this sender > have some legit busyness or can I send the bytes coming from them > directly to the recycle bin? > > Thank you. > > Cheers, > Dan > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Microsoft Announces Tenant Trusted ARC Seal
Jeff, this is really interesting. Thanks for sharing. This answers a lingering question for me as far as what practical applications there can be for ARC in a context other than a mailing list. Am I getting this right -- the way this would work is that another email platform would sign/"seal" a current state of the message authentication into the ARC header and then Microsoft, if it trusts that ARC signer, reads the ARC results to pass messages that would have perhaps otherwise failed authentication checks due to forwarding etc. past that point? Regards, Al Iverson On Thu, Jun 16, 2022 at 10:05 AM Jeff Dellapina via mailop < mailop@mailop.org> wrote: > Folks, > > > > As email passes thru our network, we make changes to the message. We may > add items to the header/footer or change links into “protected mode”. > Doing so breaks Authentication. > > > > Authenticated Received Chain (ARC). ARC helps preserve authentication > results *across* intermediaries. > > > > Learn more about ARC and how we make it work here: > > Improving “Defense in Depth” with Trusted ARC Sealers for Microsoft > Defender for Office 365 - Microsoft Tech Community > <https://techcommunity.microsoft.com/t5/microsoft-defender-for-office/improving-defense-in-depth-with-trusted-arc-sealers-for/ba-p/3440707> > > > > > > We have used ARC for a while, but this is the first time we rolled it out > to our 0365 customers. That said… there are some email filtering vendors > that are not using ARC which breaks authentication. In those cases, we are > forced to bulk or reject legitimate email sometimes from our own customers > who use email filtering services. > > > > > > Thanks, > > Jeff Dellapina > > > > Sr. Email Delivery Manager > > SAGE Team > > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Best practice for mailing list servers
On Wed, Jun 15, 2022 at 4:22 PM John Levine via mailop wrote: > > It appears that Ken O'Driscoll via mailop said: > >Hi Slavo, > > > >p=none is not always harmless. Some message filters treat p=none differently > >to not having DMARC. I've observed this as well. > Really? I'm not sure how much I care about recipient systems that are that > broken. That's a choice, for sure. Like rewriting headers to ".invalid" as a protest about DMARC and mailing lists. Your server, your rules, of course. My choice would be more about trying to keep the mail flowing. Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] outlook/hotmail (silently!) putting legit msgs into "Junk Email" folder
Rob, the geek guidance here is to do some tests of similar/same content sent from two places, webmail and Thunderbird, and then "diff" the results to see what's different. Particular things to look at: - MIME headers - Character encoding And basically just try to find what Thunderbird or Outlook client is doing that webmail isn't doing, then add it to webmail. You possibly might be in a better place here if you built the webmail thingy yourself and can modify it. Otherwise you might want to try some other webmail application (a realm I know little about). Can't hurt to see if Microsoft can do anything on their end, of course. Though I don't think the chances of success there are super high. But you're still right to try. Good luck. Cheers, Al Iverson On Wed, Jun 1, 2022 at 4:29 PM Rob McEwen via mailop wrote: > > RE: outlook/hotmail (silently!) putting legit msgs into "Junk Email" folder > > All of a sudden - my users are having either all or most of their > webmail-sent legit hand-typed messages going to outlook/hotmail - placed into > outlook/hotmail's "Junk Email" folder - specifically, when logged into the > outlook/hotmail webmail site. But if the same message is instead sent by the > user from their Outlook Desktop app or Thunderbird, it works. Fwiw, the > accounts I tested had SFP and DMARK setup and working correctly. (fwiw, I'm > using the same webmail setup that I've used for a long time - no recent > changes there.) > > I've reached out to some of my contacts at Microsoft - so I'm waiting to hear > back from them - but in the meantime - is anyone else seeing this? Any > suggestions? > > The kind of messages getting blocked - would be the kind that I would be > embarrassed by if my system were blocking such hand-typed not-spam business > emails - this must be overzealous spam filtering - but if, in the meantime, I > could find a workaround to get past this, that would be great! > > Also, I think this is appropriate for Mail Op because (1) others could be > having this issue too, but not even be aware of this yet? These message are > getting "250 OK" responses, so this won't get noticed as quickly! and (2) > messages going to outlook/hotmail are a statistically significant percentage > of all email, so this might be a new issue impacting many many people. > > -- > Rob McEwen, invaluement > > ___________ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] aol email help
As Lyle says, AOL and Yahoo are the same entity nowadays. So you'll want to go here - https://senders.yahooinc.com/ - click on contact, and click on the first button (problems). Lyle -- they are no longer Verizon Media, FYI: https://www.spamresource.com/2021/09/yahoo-is-yahoo-again.html Cheers, Al Iverson On Tue, May 17, 2022 at 6:02 PM sam via mailop wrote: > > Hello, > > > > I am trying to track down a contact for aol.com as we have a couple users who > are emailing into aol.com but there mail is landing in spam > > I confirmed that SPF and DKIM are enabled and dmarc is enabled as well on the > domain > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] The world lost another spamfighter
Alan Murphy was one of a kind; I'm very sad that he is no longer with us but I'm very happy and lucky to have known him and to have known him to be a force for good both online and in real life, for so many years. He made the world better and was a kind person to boot. Cheers, Al Iverson On Sun, May 8, 2022 at 11:40 AM Tara Natanson via mailop wrote: > > Many here have already heard but on May 6th Alan Murphy passed away after > complications from surgery last week. > > Alan was the first person I ever met from Spamhaus and over the years went > from spamfighter to friend. He was a genuinely good and fair human being and > he will be greatly missed. > > Annalivia Ford is collecting stories, anecdotes, well wishes and most > importantly photos to be combined together into a book to be presented to his > wife. The M3AAWG community will also be doing some sort of memorial in > London in June. > > If you have stories or well wishes you'd like to send along, please send to: > > annalivi...@spamhaus.org > > She is especially hoping for pictures as Alan was very camera shy and we > don't have many. > > Tara > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] What do these Gmail headers do?
Anybody familiar with the Gmail headers X-Gm-Message-State and X-Google-Smtp-Source? A coworker asked about them, but I am not really familiar. Figured I'd see here if anybody knows anything about them. Thanks in advance for your thoughts or feedback! Cheers, Al -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Does anyone know, how operates h-email.net email service?
On Fri, Apr 29, 2022 at 8:21 AM 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. You are the third person I have seen raise the issue in the past week. All the same M.O.: Netcraft sending bogus complaints about mail sent to a domain hosted by h-email.net. In one or both of the other cases, the email was COI and the questionable address had indeed been confirmed. Netcraft needs to knock it off. Cheers, Al -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] is caniuseapurchasedemaillist.com down?
Try https://www.shouldiuseapurchasedemaillist.com (I tried to keep it brand free, not trying to sell anything there, other than best practices.) Cheers, Al On Wed, Apr 27, 2022 at 10:58 AM Anne Mitchell via mailop wrote: > > > i need this page from time to time. > > > > caniuseapurchasedemaillist.com > > I know it's not as succinct as caniuseapurchasedemaillist.com ;~), but until > that site is back up feel free to use: > > https://www.isipp.com/blog/can-i-use-this-list/ > > Anne > > --- > Outsource your email deliverability headaches to us, and get to the inbox, > guaranteed! > www.GetToTheInbox.com > > Anne P. Mitchell, Esq. > CEO Get to the Inbox by SuretyMail > Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal email marketing > law) > Author: The Email Deliverability Handbook > Board of Directors, Denver Internet Exchange > Dean Emeritus, Cyberlaw & Cybersecurity, Lincoln Law School > Prof. Emeritus, Lincoln Law School > Chair Emeritus, Asilomar Microcomputer Workshop > Counsel Emeritus, MAPS: Mail Abuse Prevention System (now the anti-spam > division of TrendMicro) > > > > ___________ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] WTaF? I just got spammed BY Active Campaign
On Tue, Apr 26, 2022 at 5:54 PM Matt Vernhout via mailop wrote: > > One rogue sales person sending cold email doesn’t mean the whole company is > bad either. Things that really grind my gears: - Business practices or industries that engender abuse (looking at you, payday loans) - Sheer volume of abuse - Ongoing abuse - Ignoring reports of abuse Things that don't really grind my gears: - One email that is clearly irritating, not yet definitively bulk, not clearly reported, and where it feels like the originating or responsible entity hasn't been given a chance to investigate or respond. My spamtraps are full of lots of things, and none of them are ActiveCampaign salespeople gone wild. Sales people sending cold emails irritate me. I get way too much of it at my new job. But it pretty much just about all lands in the spam folder, because their model of B2B trickle sending from Gmail or Outlook365 (or one of those crappy "cold email" sending platforms), trying to drum up leads and getting few responses results in low engagement and solid spam folder placement, that is darn near unfixable because of its flawed design as a practicel. It is, in short, not really an OPERATIONAL mail issue, and is darn near already addressed from the ISP/MBP filer/reputation perspective, from my view, so I typically wouldn't even wax poetic about it here on Mailop, personally. Cheers, Al Iverson -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] $GOOG - IPv6 aside
lem wrote: > > You're not wrong. Depends on email volume level and server config. > > They're just so sensitive to reputation for IPv6 sends, though. Don't > > even try without SPF and DKIM, and even then, get ready for some > > possible pain. > > For well managed mail servers, supporting well managed mailing lists I see no > practical difference between address families. I have visibility over a few > boxes sending a few hundred thousand messages per day. I see no reason to disagree with you. :) The difference between your scenario and mine (and the scenarios of people struggling) is that you're sending much more mail than me (and the people struggling), I think. You might be at the low end compared to how much mail Gmail sends, but you're in rather a good spot as having enough email to send to build up a good sending reputation. (Of course, it's not ONLY about volume...but that is indeed part of it.) Cheers, Al -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] $GOOG - IPv6 aside
On Fri, Apr 15, 2022 at 10:36 AM Grant Taylor via mailop wrote: > > On 4/15/22 8:24 AM, Al Iverson via mailop wrote: > > Don't send to Gmail over IPv6. > > Drive by comment. > > It is possible to send to Google via IPv6. My personal / small / > bespoke server sends to my Google hosted work address all the time over > IPv6. You're not wrong. Depends on email volume level and server config. They're just so sensitive to reputation for IPv6 sends, though. Don't even try without SPF and DKIM, and even then, get ready for some possible pain. I think Gmail could be worried that with IPv6 being so broad that somebody could do a spam run targeted at them with each individual message coming from a different IPv6 IP. So I think they are way quicker to drop the hammer and block an IPv6 IP at very low volumes versus an IPv4 IP. (That's a bit of a generalization there, of course.) When I set up a new VPS at a provider, I immediately disable the IPv6 interface and IP. I have never had any sort of broad blocking issues at Gmail with my newest servers. Occasionally I get a content block or trigger something weird-- I accidentally stumbled across a bug in my mailing list manager a couple of weeks ago that would sometimes result in having two message-ID headers and that caused Gmail blocking. But I was able to troubleshoot and fix it. Cheers, Al -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] $GOOG
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. -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] $GOOG
On Thu, Apr 14, 2022 at 12:00 PM Jaroslaw Rafa via mailop wrote: > > Dnia 13.04.2022 o godz. 19:44:52 Al Iverson via mailop pisze: > > > > Seconded. Google does not do things the way I would, and I find them > > frustrating, yes, but no, it is not true about there being some > > conspiracy to keep you out, and no, it's not unfixable, unless you > > stick your head in the sand or put your fingers in your ears and don't > > do things the right way for 2022 because you don't want to or can't. > > 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. Cheers, Al Iverson -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Best mailbox provider for personal domain?
IMAP download is indeed a lot slower than Google Takeout -- I learned that the hard way. I tried to download it all via IMAP then gave up and switched to Google Takeout. FYI, Apple Mail will read the Google Takeout MBOX file, so that gives you a place to open and browse your archive, if you like. On Thu, Apr 14, 2022 at 4:47 AM Duncan Turnbull via mailop wrote: > > > > On 14/04/2022, at 7:08 PM, Tara Natanson via mailop wrote: > > > > > On Sun, Apr 10, 2022 at 2:26 PM Alexander Huynh via mailop > wrote: >> >> > On Apr 10, 2022, at 10:40, Byron Lunz via mailop wrote: >> > >> > I don't recall seeing any discussion in this thread about how to migrate >> > old email messages from a Google Workspace account to a different host. >> > Anyone have advice or suggestions on how to do that? >> >> You could use https://takeout.google.com/ to download an mbox format. >> > > My husband did this with his google mailbox and it took well over 24 hours. > but it's done. Apparently, googles free offering to those in my same > position will be to output their mail for them to a new or different @gmail > address but no longer accept incoming mail for the personal domain. So I'm > going to wait and let them move my mail for me, and will likely use that > mailbox to imap whatever new service I end up going with. > > I have tried migrating domains using Googles takeout and imap and the imap is > longer than the takeout. They have some limits that you hit. Or at least I > hit enough that it wasn’t really as useable as you would hope. Your mileage > may vary though > > Tara > > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] $GOOG
I've seen it happen perhaps twice in twenty years, from what I can non-scientifically recall. 99.9% of the time we've had somebody complain they can't find the mail in their Gmail account, it is because it's in their spam folder. I'm not particularly worried that there's some new outbreak of this. Even back in the day, unexpected internal delays inside of Gmail were more common, and even those were relatively rare. To your point, yeah, Microsoft used to be the big bad who would discard mail after accepting it and that was a super huge pain to deal with. That seems to be a thing of the past, thankfully. Cheers, Al Iverson On Wed, Apr 13, 2022 at 7:59 PM Jarland Donnell via mailop wrote: > > I've seen Microsoft do that very thing many times over the years, > accepting an email but never delivering it. I have to admit, I have not > once witnessed this with Gmail. Given how much volume we do where > customers bring their own domains, I would find it strange to have not > run into it, if it is an actual issue that occurs. > > Filtering to the spam folder of course happens with email that received > a 2xx, but I've not yet seen a blackhole. I would be interested in > hearing more about it if anyone has collected any data around it. > > On 2022-04-13 19:28, Rob McEwen via mailop wrote: > > On 4/13/2022 6:58 PM, Jarland Donnell via mailop wrote: > > > >> Out of the 140,244 emails delivered to Google by my customers today, > >> not a single one has complained of issues with Google rejecting > >> legitimate email. > > > > Even so, keep in mind the following: > > > > (1) Their most egregious false positives - ARE delivered - they return > > a "250 OK" response - but then Google's spam filter does a 2nd round > > of spam filtering - AFTER the SMTP connection has completed - and > > that's where MOST of their most egregious false positives occur - > > partly because the sender THINKS that their message was delivered. > > > > (2) These are OFTEN the types of mistakes that are most often unknown > > to the sender - since the sender then never gets back a non-delivery > > notification. (and unfortunately not everyone is savvy and consistent > > with requesting and monitoring for "read receipts" for important > > hand-typed emails!) So then they don't "complain" to their mail hoster > > about a problem they don't even know exists! (so their lack of > > "complaints" is an inadequate/flawed measurement of success in this > > case!) > > > > For example, I have a close relative who was the CFO of a company a > > couple of years ago (with hundreds of millions in annual sales) - > > before he switched to another company - and what I'm about to describe > > occurred AFTER Google's huge move to going "all in" on A.I. for email > > processing - and so this company almost lost the renewal of a > > multi-million dollar deal because their client's hand-typed messages > > were getting 250 OK answers, but were spam-filtered after-the-fact by > > Google. The client thought that they were getting dissed by their > > vendor - since they didn't get non-delivered notifications for those > > emails - and so this client was already in the process of looking for > > a new vendor when someone at my relative's (former) company spotted > > the false positives from this client in the spam folder at the last > > "final hour" and just barely saved the deal. > > > > Of course, that's anecdotal and ALL spam filters have occasional > > egregious false positives. But it's just that your "delivered to > > Google" might not mean as much as you thought that it meant! It's > > possible that a few of those 140,244 emails might not have made it to > > the inbox! > > > > -- > > Rob McEwen, invaluement > > ___ > > mailop mailing list > > mailop@mailop.org > > https://list.mailop.org/listinfo/mailop > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] $GOOG
>> that google is provably wrong and provably non-transarent in how they >> decide what inbound e-mail to reject. > > Unless you have a solution which ensures that only good senders are able to > send email, then yes, you will find that receivers will be mostly > non-transparent on how they decide what to reject. Any receiver protecting > their users will be. > >> know better than to cooperate with your oppressor. > > This was stressed before (even by the list admin): But if you want people to > collaborate and be more transparent, maybe refrain from sentences like the > one above. Seconded. Google does not do things the way I would, and I find them frustrating, yes, but no, it is not true about there being some conspiracy to keep you out, and no, it's not unfixable, unless you stick your head in the sand or put your fingers in your ears and don't do things the right way for 2022 because you don't want to or can't. Cheers, Al Iverson -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Exact Target (Pardot) unsubscribe link is insecure..
This isn't Pardot or Salesforce support so I don't know what good it does to post about it here, to be honest. Pardot clients can/should implement SSL on their tracker domain (which includes the list-unsub domain): https://help.salesforce.com/s/articleView?id=000318025=1 I just read a blog post that implies that the default go.pardot.com domain is getting SSL added, too? Maybe? https://www.salesforceben.com/the-drip/go-pardot-com/ I don't work in Salesforce land any more, so I have no detail beyond that... Cheers, Al On Wed, Apr 13, 2022 at 12:39 PM Atro Tossavainen via mailop wrote: > > On Wed, Apr 13, 2022 at 10:21:18AM -0700, Michael Peddemors via mailop wrote: > > Return-Path: > > > > > > Click on the unsubscribe link, and it goes to an insecure pardot page. > > Envelope-senders are not links, though. > > -- > Atro Tossavainen, Chairman of the Board > Infinite Mho Oy, Helsinki, Finland > tel. +358-44-5000 600, http://www.infinitemho.fi/ > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Can someone from google/gmail contact me offlist?
On Wed, Mar 30, 2022 at 2:53 AM Dan Mahoney via mailop wrote: > > Day Job (ISC.org) is having delivery issues to gmail due to our “very low” > reputation. I call shenanigans. > > Mar 30 07:21:58 post postfix/smtp[75122]: D7B673AB008: > to=, > relay=gmail-smtp-in.l.google.com[2607:f8b0:400c:c14::1b]:25, delay=1.7, > delays=0.31/0/0.85/0.52, dsn=5.7.1, status=bounced (host > gmail-smtp-in.l.google.com[2607:f8b0:400c:c14::1b] said: 550-5.7.1 > [2001:4f8:0:2::2b 19] Our system has detected that this message > 550-5.7.1 is likely suspicious due to the very low reputation of the sending > 550-5.7.1 domain. To best protect our users from spam, the message has been > 550-5.7.1 blocked. Please visit 550 5.7.1 > https://support.google.com/mail/answer/188131 for more information. > c8-20020a056102318800b003255333019bsi4904938vsh.501 - gsmtp (in reply to end > of DATA command)) I would suggest a submission here as well: https://support.google.com/mail/contact/bulk_send_new Since this specifically refers to domain reputation I'd make sure all mail is properly signing with DKIM. Domain rep can also fall back to the return-path domain, so if that's different from your visible from domain, that could be the domain with a poor rep. And domain in this context can also mean subdomain. Cheers, Al Iverson -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] After years of accepting messages, yahoo suddenly stops
https://www.google.com/search?client=safari=en=554+5.7.9+Message+not+accepted+for+policy+reasons=UTF-8=UTF-8 "If your emails are being rejected by Yahoo recipients with the error "554 5.7. 9: Message not accepted for policy reasons", it means that your email failed one or more authentication checks that Yahoo uses to verify that emails are truly sent from the domains they claim to originate from" Either your DNS is broken, or you've got DKIM, SPF or DMARC misconfigured. Or the DNS brokenness is looking to the ISP like a DMARC failure. My free little checker thingy called KBXSCORE likely would be able to tell you which one it is - try sending a message to it as instructed on https://kbxscore.com . Cheers, Al Iverson -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] Yahoo CFL signup?
Hello world! Since there do seem to be a few outdated links out there, and even if there weren't, it can be confusing for folks to understand how they would sign up for the Yahoo CFL (and where to do it), so I've put together guidance here: https://www.spamresource.com/2022/03/what-is-yahoo-complaint-feedback-loop.html Hopefully that'll pick up some Google fu over time and help others. I went back and updated old links on my blog to point to the new Yahoo Senders Hub website, and I know Laura Atkins has similarly updated an older post on Word to the Wise that shows up in Google results. Hopefully that'll help confused folks in the future. Cheers, Al Iverson -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] Yahoo CFL signup?
On Fri, Mar 18, 2022 at 7:20 PM Marcel Becker via mailop wrote: > That "URL" is our postmaster / sender support site. > Everything you are looking for is right there. So not sure why you did not > click on "Contact". Or at least "FAQs". Click it and you'll see it actually dumps the user at a sort of a more general help page. Nothing postmaster specific. Might be good to ask for a redirect to the new senders site. The other problem is that when people google "Yahoo CFL signup" one finds a bunch of old blog posts from 2015ish linking to old pages like "feedbackloop.yahoo.net" -- yet another deprecated URL that doesn't redirect to the new senders site. Matthew: What you want to do is go here - https://senders.yahooinc.com - and click on "Contact" and then click on "Complaint Feedback Loop" and there you are. Those of us out in the blogosphere should do better about updating old links for Yahoo CFL signup as well. I'll nudge a few folks and make sure all of my links are updated. Cheers, Al Iverson -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Auto Unsubscribing Behavior
Yes -- this is security software following links in email messages,
looking for malware. Microsoft, Barracuda and many others do it.
Microsoft can provide a bit of guidance on certain types of URLs that
they will not follow; but that's only them, and it's a bit of an arms
race type scenario.
What you really need is to go from a one-click unsub to a two-click unsub.
https://www.spamresource.com/2022/02/lets-talk-all-about-unsubscribes.html
Cheers,
Al Iverson
On Tue, Mar 8, 2022 at 2:23 PM Brian Toresdahl via mailop
wrote:
>
> We've been experiencing cases of apparent automatic unsubscribes, but I'm not
> familiar with the source of this, and am hoping someone here can recognize
> the reason for the behavior.
>
> We're an email service provider, used primarily in corporate settings, for
> sending e-gifts (e.g. Starbucks gift cards). Consent and a prior email
> relationship does exist between sender/recipient.
>
> What we've seen, corroborated with cases across different sender domains, and
> different recipient domains, is that emails, as soon as they're delivered,
> are being immediately unsubscribed. We've had enough independent reports from
> recipients that they didn't unsubscribe themselves to make me believe them.
> We've had cases where senders and recipients are on the phone, together, with
> the recipient actively trying to resubscribe, but each retry is again
> unsubscribed. So it's like some automated system is unsubscribing recipients
> against their consent.
>
> The one pattern we've noticed is that the recipient domains have a common MX,
> something like {recipient.domain}.mail.protection.outlook.com. But it's not
> across all such recipient domains, just a handful.
>
> This leads me to believe there is some local admin setting available for
> mail.protection.outlook.com, allowing admins to enable some sort of
> "auto-unsubscribe" rule for emails matching some pattern.
>
> If this is the case, then that sounds like a corporate policy, and I would be
> unable to affect a different outcome from the sender side, or individual
> recipient side. I can respect this -- their server, their rules, etc -- I
> just want to accurately communicate what's happening to my users.
>
> Am I understanding the issue correctly here?
>
> I did raise a ticket with Microsoft's Postmaster support, SR1536619994, but
> have not received any useful communication.
>
> --
>
> Brian
> _______
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
--
Al Iverson / Deliverability blogging at www.spamresource.com
Subscribe to the weekly newsletter at wombatmail.com/sr.cgi
DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: [mailop] Who Do You Recommend for Small Business Regular (Non-Bulk) Email?
Fastmail looks good. I think I'm going to give it a try. Al On Wed, Mar 2, 2022 at 9:54 AM Anne Mitchell via mailop wrote: > > All, > > For some reason we have recently had a spate of small businesses coming to us > asking us for our recommendations for a service to host their regular > one-to-one business communications. Google and MS seem to have the business > email hosting thing locked up tight, but surely there must be email providers > out there that are friendlier, easier to set up, and maybe even with some > decent support (or is that a pipe dream?) > > If a small business (say less than 10 people, hosts their website at their > registrar's free hosting service, or Square or Wix) were to come to you and > ask you from where they should send their one-to-one regular business > correspondence email, who would you recommend? > > Anne > > --- > Outsource your email deliverability headaches to us, and get to the inbox, > guaranteed! > www.GetToTheInbox.com > > Anne P. Mitchell, Esq. > CEO Get to the Inbox by SuretyMail > Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal email marketing > law) > Author: The Email Deliverability Handbook > Board of Directors, Denver Internet Exchange > Dean Emeritus, Cyberlaw & Cybersecurity, Lincoln Law School > Prof. Emeritus, Lincoln Law School > Chair Emeritus, Asilomar Microcomputer Workshop > In-house Counsel: Mail Abuse Prevention System (MAPS) (Closed in 2004) > > _______ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Info on deluxe.com
https://xnnd.com/dns.cgi?t=mx=info.deluxe.com= info.deluxe.com mail is handled by 10 reply.s11.exacttarget.com. exacttarget.com = Salesforce Marketing Cloud https://www.abuse.net/lookup.phtml?domain=exacttarget.com ab...@abuse.salesforce.com (for exacttarget.com) On Fri, Feb 25, 2022 at 10:05 AM Luis E. Muñoz via mailop wrote: > > Hi there, > > I just received my first ever spam from info.deluxe.com, sent to a tagged > address used exclusively for online banking. Does anyone have a contact at > deluxe so that inquiries can be sent? > > Thanks! > > -lem > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail does not validate DKIM for forwarded messages?
> What will that do to legitimate messages that pass through > a mailing list that changes the subject line but does not > use DKIM ? > In this scenario, my mailing list manager strips the original DKIM signature and applies its own, as I am now the party responsible for the message. (I also rewrite the from address.) This has worked fine for me, but not everyone is a fan of this methodology. Regards, Al Iverson -- *Al Iverson /* Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone from Vade
The person I knew at Vade seems to have left, but the process described here should still work: https://www.spamresource.com/2020/06/what-is-vade-threat-list-how-do-i.html Cheers, Al Iverson On Sun, Jan 30, 2022 at 9:23 AM Ken Robinson via mailop wrote: > My IP address has somehow gotten on the Vade Blocklist. It is not on any > other blocklist as far as I can tell. > > How do I get it off the Vade list? > > My IP address is 172.110.191.18 > > Thanks, > Ken Robinson > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > -- *Al Iverson /* Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Ethics Complaint to Princeton (was: Privacy research spam apparently from a grad student at Princeton)
Okay, I have to admit, this was very well handled on your part. It's really good guidance. Cheers, Al Iverson On Fri, Dec 17, 2021 at 8:49 AM yuv via mailop wrote: > UPDATE: > > * I had waited for the answer to my direct note to Jonathan Mayer and > fell asleep. It arrived at 01:44 EST. This morning I replied to him. > With a direct line of communication open, the letter higher up is on > hold. > > * They are currently not sending emails and will be publishing an FAQ > soon. The issue that is relevant for mailop is, at least temporarily, > defused. The feedback I have given them with regard to the spam issue > is that: > > The study abused the mechanism created by the laws to deliver its > questionnaire to an email address whose purpose is only to receive > legal GDPR/CCPA requests. Maybe, on balance, such minor abuse could be > tolerated as an efficient, low-cost shortcut to reach the person better > placed to answer the study's questionnaire. However, the obfuscation > of the sender; the use of fraudulent identities; the covert and > indirect questions; all void any possible justification, whether the > study does or does not constitute human subjects research. > > [...] > > (a) put your questions in a direct plain view survey form on the web > instead of covering them up with hypothetical facts scenarios; > > (b) identify yourself as the sender instead of using covert domains and > false identities; > > (c) use a strict opt-in logic: the first email is the last one unless > the subject responds; and the first email has all the elements for the > subject to make an informed consent decision. > > > * On the big issue, the ENROLLMENT OF HUMAN SUBJECTS WITHOUT CONSENT > into the study, I have been told that "[t]he IRB determined that our > study does not constitute human subjects research." I do not have the > reasons for such determination, but this is the fault line at the > moment. I have offered to Jonathan my opinion that: > > The IRB's determination stands corrected (of course without admitting > fault, given the litigious contest of the land). Behind every website > there is an operator and in most cases, the end-operator is a human > subject, or an organization within which a human subject bears ultimate > responsibility for processing the study's emails. That human deserves > respect [Belmont Report]. > > In the context of GDPR/CCPA, the mechanism they create and the > obligations and sanctions they impose, the study as designed resulted > in the ENROLLMENT OF HUMAN SUBJECTS WITHOUT CONSENT. > > It is work in progress. I am trying to identify who at Princeton would > be the optimal recipient of my letter. A Researcher Misconduct > Complaint to the DoF would only deal with the individual researcher's > integrity and would not prevent the IRB from making further misguided > decisions on the coerced enrollment of humans. At this time I am not > seeking to punish the researchers. I wait to see how the dialog with > Jonathan unfolds. > > > On Thu, 2021-12-16 at 22:10 -0700, Grant Taylor via mailop wrote: > > I don't buy the silly mistake. Not the second time around. > [...] > > But the fact that the student repeated the action and apparent lack > > of caring completely negates both "silly" and "mistake" in my head. > > https://en.wikipedia.org/wiki/Three-strikes_law > > > -- > Yuval Levy, JD, MBA, CFA > Ontario-licensed lawyer > > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > -- *Al Iverson /* Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Ethics Complaint to Princeton (was: Privacy research spam apparently from a grad student at Princeton)
On Thu, Dec 16, 2021 at 9:48 AM Larry M. Smith via mailop wrote: > > On 12/15/2021, Anne P. Mitchell, Esq. via mailop wrote: > > FYI, I have sent my own letter, with my full signature (same one as below), > > to Princeton, including cc:ing the dept. chair, the abuse department, and > > the legal department. I do hope you send yours, and soon, as it would be a > > good 1-2 punch. > > > > It would appear that other punches are being thrown elsewhere; > > https://www.spamhaus.org/sbl/query/SBL538721 Well, I'm sure this'll be a popular opinion, but I'm giving it anyway. Maybe let's try not to do something that'll screw up that college kid's life forever over their bit of stupidity. It's wrong, they shouldn't be doing it, but it's not for commercial gain, and the amount of bad mail being sent here in comparison to the amount of bad mail being sent by others is .1%. If I had a top ten list of spam problems I cared about, this would be #14, barely. Not every annoying gnat needs a nuclear missile response. (Quite possibly, few-to-none of them do.) I'm getting a deja vu feeling from when somebody tried to get my friend thrown out of college 25 years ago for doing open relay testing after being told to stop. In both cases, what the person was doing was stupid, but the response was way over the top. That was dumb then and this is dumb now. Regards, Al Iverson -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Privacy research spam apparently from a grad student at Princeton
I wonder if this guy would teach me his secret to get AWS to unblock port 25 for him. They turned me down, as I'm sort of a security risk, being an elite hax0r with xnnd.com and all that, haxing port 25s all over town. (And maybe I don't WANT to use SES, yuck.) Al On Wed, Dec 15, 2021 at 7:31 AM Larry M. Smith via mailop wrote: > > On 12/15/2021, Raymond Dijkxhoorn via mailop wrote: > (snip) > > If people received ones not originating from the below list (and the new > > reported org version) please let me know. > > > > yosemitemail[.]com > > potomacmail[.]com > > envoiemail[.]fr > > novatormail[.]ru > > > > The list of domains being used appears to be here; > https://measurement.cs.princeton.edu/privacystudy/ > > -- > SgtChains > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] comcast.net MX
On Sat, Dec 4, 2021 at 6:16 AM Alessandro Vesely via mailop wrote: > > On Thu 02/Dec/2021 19:55:37 +0100 Brotman, Alex via mailop wrote: > > Folks, > > > > You may or may not have noticed we've been moving some things around. > > We've published new MX records, and have moved traffic over. The old MX > > records will cease to exist shortly. If you're somehow fixated on those > > old MX records or associated IPs, your traffic to comcast.net recipients > > may not work much longer. > > > > Please let us know if you have any questions or concerns. Thanks > > > I get > ;; ANSWER SECTION: > comcast.net.300 IN MX 5 mx1h1.comcast.net. > comcast.net.300 IN MX 5 mx2h1.comcast.net. > comcast.net.300 IN MX 5 mx1a1.comcast.net. > comcast.net.300 IN MX 5 mx1c1.comcast.net. > comcast.net.300 IN MX 5 mx2c1.comcast.net. > comcast.net.300 IN MX 5 mx2a1.comcast.net. > > Are those new or old ones? > > I'm unable to send mail to comcast.net since a couple of days. The server > fails > saying "Did not find a suitable MX for a connection". When I tried manually > mx1h1.comcast.net, the connection was closed before I could type "mail from". To which IP, and was it over IPv4 or IPv6? Telnet test works fine from here: $ host mx1h1.comcast.net. mx1h1.comcast.net has address 96.102.157.178 mx1h1.comcast.net has IPv6 address 2001:558:fd02:243f::2 aiverson@s1:~$ nc 96.102.157.178 25 220 resimta-h1p-037526.sys.comcast.net resimta-h1p-037526.sys.comcast.net ESMTP server ready (Didn't hang up on me; I did a quick and dirty send test and it worked fine.) I'm assuming the IP is a new/current one based on every public DNS I test showing that as a current IP. If we were waiting out TTLs or if somebody was caching beyond best practices, we'd be getting varying results. https://xnnd.com/dns.cgi?t=mx=comcast.net=yes I don't use IPv6, so I don't have an easy way to test it today. So if you're coming in on IPv6 and having issues that I'm not having, maybe they have an IPv6 issue or can't resolve your DNS. Or if IPv4, are you sure you're not connecting from an IP considered to be dynamic and/or on lists of IPs that "shouldn't be running mail servers" like the Spamhaus PBL? Cheers, Al -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Speaking of Linode (thread topic changed)
Is "hey bad ISP please come here and defend yourself against my accusation" really on topic for this mailing list? Isn't there some other list like SPAM-L or something that might be more suited to that type of conversation? On Fri, Nov 26, 2021 at 1:05 PM Michael Peddemors via mailop < mailop@mailop.org> wrote: > Maybe someone from Linode can comment on this.. > > Here is a typical spam outbreak from Linode.. > > Usually these are trapped/tagged because the default PTR is still in > place, so doesn't cause enough problems to report, but they do happen > occasionally in spurts. > > Since several times it has been mentioned on the list that Linode blocks > port 25 by default (I have no evidence to support those claims though) > > .. it does make one question how these cases appear. > > (Some headers removed for clarity) > > Return-Path: > Received: from li1548-40.members.linode.com (HELO fit.clinic) > (139.162.68.40) > Received: (qmail 23890 invoked by uid 2); 26 Nov 2021 17:25:01 - > Message-ID: <20211126172501.23889.qmail@fit.clinic> > From: contact.yoyogi@fit.clinic > > (this was an interesting catfish lure in Japanese, returning a 503 now) > > Now, either this was a compromised server, or someone stood up a Linode > Instance for the sole purpose of phishing.. > > It would be interesting to hear how/why this was not blocked by default > (port 25), how long the instance was up and running before it started > its spam/phishing run, and was this a malicous customer, or a compromise. > > Inquiring minds would like to know.. > > -- Michael -- > > PS, this one.. > > Return-Path: > Received: from 66-228-37-15.ip.linodeusercontent.com (HELO > 693809.cloudwaysapps.com) (66.228.37.15) > Received: by 693809.cloudwaysapps.com (Postfix, from userid 1004) > > > > > > > > -- > "Catch the Magic of Linux..." > > Michael Peddemors, President/CEO LinuxMagic Inc. > Visit us at http://www.linuxmagic.com @linuxmagic > A Wizard IT Company - For More Info http://www.wizard.ca > "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. > > 604-682-0300 Beautiful British Columbia, Canada > > This email and any electronic data contained are confidential and intended > solely for the use of the individual or entity to which they are addressed. > Please note that any views or opinions presented in this email are solely > those of the author and are not intended to represent those of the company. > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > -- *Al Iverson /* Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Google DNS Quad 8 Outage tonight
I never thought to monitor for it but Twitter suggests yes, there was an outage, both on 11/19 and maybe back on 11/12 too. Cheers, Al Iverson On Fri, Nov 19, 2021 at 8:52 PM Kevin A. McGrail via mailop < mailop@mailop.org> wrote: > Anyone out there see any Quad 8 outages from about 20:25PM Eastern to > 21:16PM Eastern? > > Regards, > > KAM > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > -- *Al Iverson /* Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] BIMI status and interoperation possibilities
CNN has implemented VMC: https://www.digicert.com/news/pr/digicert-issues-certificate-to-cnn-for-bimi-email-standard/ https://xnnd.com/dns.cgi?t=bimi=cnn.com Their newsletters would be good emails to sign up for, for testing your BIMI implementation: https://www.cnn.com/newsletters If you want mail from a non-VMC using sender that publishes a BIMI record, perhaps wish.com? https://xnnd.com/dns.cgi?t=bimi=wish.com= https://www.wish.com/ Hope that helps! Cheers, Al Iverson On Mon, Nov 1, 2021 at 10:08 AM Vsevolod Stakhov via mailop wrote: > > Hello, > > I'm currently building a prototype of BIMI agent in Rspamd as per this > Github issue: https://github.com/rspamd/rspamd/issues/3935 > > However, this technology seems to be very immature and only fragmentary > documented in some aspects. I was able to find just one (!) valid VMC > for `valimail.com` domain in the wild. Other participants of the BIMI WG > either do not publish BIMI records (e.g. Google), provide just an image > without VMC (e.g. Proofpoint) or even publish an expired VMC (e.g. > Paypal)... > > Furthermore, even a valid VMC from Valimail does not include any > system-wide trusted CA apart of the specific VMC CA that is not trusted > by system nor cross-signed by other DigiCert CAs (so I had to implement > my own PKI based on trusted fingerprints which is acceptable but not > pleasant). > > For now, I'm looking for some other options to test BIMI and one thing > I'm missing critically is an example of an email that could be validated > by DMARC for the domain that have a valid BIMI record (either normal but > preferably with VMC). So I would appreciate any help in getting such > messages, e.g. if anyone who can send email on behalf of Valimail.com > domain could send me a message with any content to my personal email. > > I would also appreciate any information about where to get further > details without signing any sort of bogus agreements which I personally > will never ever sign (as I have a strong belief that all Internet > standards must be open for the general public). > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Microsoft site with bad SPF record
BTW, friends tell me that this is being fixed. :) Cheers, Al Iverson On Thu, Oct 28, 2021 at 9:13 AM Al Iverson wrote: > > That sending IP is actually Salesforce as a vendor for Microsoft, > sending through "Salesforce Marketing Cloud" aka ExactTarget. I've > forwarded your email on to somebody there to ask them to find the > right client contact and nudge them. (It's Microsoft-hosted DNS so > Salesforce can't itself fix it.) > > Based on how Salesforce recommends clients implement SPF records for > Marketing Cloud, this would be "-all" if configured per usual. > > Cheers, > Al Iverson > > On Thu, Oct 28, 2021 at 8:54 AM Johann Klasek via mailop > wrote: > > > > Has anyone else seen this from Microsoft sites? > > > > Recently, I stumbled over a rejection in our logs that came from a > > Microsoft site with the source mta48.email.microsoftemail.com > > [13.111.32.222]. The SPF entry of the from domain contains an "all" > > which includes the entire Internet as permitted sender for such messages > > ... probably not the actual intention of the SPF entry shown below: > > > > bounce.experience.microsoft.com. 3600 IN TXT"v=spf1 mx ip4:72.32.45.226 > > ip4:72.32.45.228 ip4:72.32.45.235 ip4:72.32.45.240 ip4:72.32.45.234 > > ip4:72.32.177.41 include:ksrinc.com include:cust-spf.exacttarget.com > > include:confirmit.com all" > > > > I would expect to see something like "-all" or "~all" ... > > > > Perhaps Michael could forward this to the appropriate team in house. :) > > > > > > Johann > > > > ___ > > mailop mailing list > > mailop@mailop.org > > https://list.mailop.org/listinfo/mailop > > > > -- > Al Iverson / Deliverability blogging at www.spamresource.com > Subscribe to the weekly newsletter at wombatmail.com/sr.cgi > DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Microsoft site with bad SPF record
That sending IP is actually Salesforce as a vendor for Microsoft, sending through "Salesforce Marketing Cloud" aka ExactTarget. I've forwarded your email on to somebody there to ask them to find the right client contact and nudge them. (It's Microsoft-hosted DNS so Salesforce can't itself fix it.) Based on how Salesforce recommends clients implement SPF records for Marketing Cloud, this would be "-all" if configured per usual. Cheers, Al Iverson On Thu, Oct 28, 2021 at 8:54 AM Johann Klasek via mailop wrote: > > Has anyone else seen this from Microsoft sites? > > Recently, I stumbled over a rejection in our logs that came from a > Microsoft site with the source mta48.email.microsoftemail.com > [13.111.32.222]. The SPF entry of the from domain contains an "all" > which includes the entire Internet as permitted sender for such messages > ... probably not the actual intention of the SPF entry shown below: > > bounce.experience.microsoft.com. 3600 IN TXT"v=spf1 mx ip4:72.32.45.226 > ip4:72.32.45.228 ip4:72.32.45.235 ip4:72.32.45.240 ip4:72.32.45.234 > ip4:72.32.177.41 include:ksrinc.com include:cust-spf.exacttarget.com > include:confirmit.com all" > > I would expect to see something like "-all" or "~all" ... > > Perhaps Michael could forward this to the appropriate team in house. :) > > > Johann > > _______ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] WhatCounts/Costco silliness
On Sun, Oct 24, 2021 at 4:58 PM John Levine via mailop
wrote:
>
> It appears that Larry M. Smith via mailop said:
> >Ya know, I'm not a deliverability guy; So there's a good chance that I
> >don't understand how these 'List-Unsubscribe' headers work.
>
> Ah, you should ask the people who wrote RFC 8058.
Nah, those guys are jerks. :P You should really go hang out with the
people who wrote RFC 2369, that's where the real prestige came from.
Remember how that one guy used to have a website at
list-unsubscribe.com bragging about it? I was bummed to find out
recently that it's gone; I wanted to link to it in an upcoming blog
post about list-unsub functionality.
> >List-Unsubscribe: <https://www.example.com/unsub/{token}>
> >List-Unsubscribe-Post: List-Unsubscribe=One-Click
> >
> >I don't know which fools to blame; The client Costco, or their ESP
> >WhatCounts. Perhaps both.
>
> Definitely both.
I don't work for or with WhatCounts, but I know who does, so I nudged them.
Checking my traps, I don't see any other mail like that; it does seem
to be specific to Costco alone, at least in my own little slice of
spamtrap heaven.
Cheers,
Al Iverson
--
Al Iverson / Deliverability blogging at www.spamresource.com
Subscribe to the weekly newsletter at wombatmail.com/sr.cgi
DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: [mailop] Google Postmaster Tools - No data since October 4th
GPT is back but data is still backfilling for some folks (including me). I'm a tiny sender, so I assume I'm way down their priority list. Cheers, Al Iverson On Mon, Oct 18, 2021 at 7:04 AM Yitzhak Cohen via mailop wrote: > Can back partially last week, sometime on Friday I think. When I looked > again today it was fully back-filled. > > > > > -- > *From:* mailop on behalf of Ewald Kessler | > Tripolis via mailop > *Sent:* Monday, October 18, 2021 13:19 > *To:* Antonie Popovic > *Cc:* mailop@mailop.org > *Subject:* Re: [mailop] Google Postmaster Tools - No data since October > 4th > > Caution: This email is from an external sender. Please do not click links > or open attachments unless you recognize the sender and know the content is > safe. Forward suspicious emails to isitbad@. > > > > Must have been between Friday afternoon (CET) and this morning. > > > > *From:* Antonie Popovic > *Sent:* Monday, 18 October 2021 12:17 > *To:* Ewald Kessler | Tripolis > *Cc:* mailop@mailop.org > *Subject:* Re: [mailop] Google Postmaster Tools - No data since October > 4th > > > > Thank you for the info Ewald. > > Could you or anyone else please confirm when you got the reports for the > missing week ? > > > > Much appreciated, > > Toni > > > > On Mon, Oct 18, 2021 at 11:33 AM Ewald Kessler | Tripolis via mailop < > mailop@mailop.org> wrote: > > Data is back. And backfilled! > > > > *From:* mailop *On Behalf Of *Danny Steinhoff > via mailop > *Sent:* Thursday, 14 October 2021 09:35 > *To:* Maarten Oelering > *Cc:* mailop > *Subject:* Re: [mailop] Google Postmaster Tools - No data since October > 4th > > > > We do not get any data since 4 October > > > > On Thu, Oct 14, 2021 at 10:32 AM Maarten Oelering via mailop < > mailop@mailop.org> wrote: > > We are monitoring hundreds of domains in GPT. Some of these domains never > showed any data. > But since October 8 all domains are returning 404 errors on the GPT API. > So something is wrong at Google. > > Maarten > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist.mailop.org%2Flistinfo%2Fmailop=04%7C01%7Cjcohen%40godaddy.com%7Cc2dd8dceab3440547fdb08d992214267%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637701493832937541%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=o232f0aEojp14L5R32USzrmzTs8X%2BZl%2FmplMPhqrui0%3D=0> > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist.mailop.org%2Flistinfo%2Fmailop=04%7C01%7Cjcohen%40godaddy.com%7Cc2dd8dceab3440547fdb08d992214267%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637701493832937541%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=o232f0aEojp14L5R32USzrmzTs8X%2BZl%2FmplMPhqrui0%3D=0> > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > -- Al Iverson // Wombatmail // Chicago Deliverability: https://spamresource.com DNS Tools: https://xnnd.com ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Firefox Phishing Protection says 413: Your client issued a request that was too large.
Otto! Long time no talk. Hope you're doing well. :) If it's any consolation, Gmail thinks that your post to Mailop is a phish, so perhaps the bad domain made it to the Google Safe Browsing blacklist, at least. :) Cheers, Al Iverson On Thu, Oct 14, 2021 at 9:12 AM Otto J. Makela via mailop wrote: > > We received some phising emails, and when you access the phishing > site redirector > x > > you will be redirected to a website using such a long URL (about 15k) > that when you try to report it to Firefox Phishing Protection it fails > with 413: Your client issued a request that was too large. This URL > contains a base64-encoded html file, and without it trying to access > the site just produces a "this account has been suspended" message. > > I don't doubt this is the reason why they chose to do it like this. > > -- >/* * * Otto J. Makela * * * * * * * * * */ > /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */ > /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */ > /* * * Computers Rule 0100 01001011 * * * * * * */ > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson // Wombatmail // Chicago Deliverability: https://spamresource.com DNS Tools: https://xnnd.com ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Google not sending DMARC Aggregate Reports
You're not alone. Both Google's DMARC reports and Google Postmaster Tools updates stopped, last update / last notification sent seems to be around October 3rd. I blogged about this just a few hours ago: https://www.spamresource.com/2021/10/google-postmaster-tools-and-dmarc.html I'm hearing second hand that it's a known issue and being worked on; if that applies to both DMARC and GPT, or just GPT, I'm not 100% sure, but I suspect both. Cheers, Al Iverson On Fri, Oct 8, 2021 at 3:41 PM Omar, Ali via mailop wrote: > > Hello Everyone, > > > > Google abruptly stopped sending DMARC Aggregate reports. No RUA reports have > been sent since Oct. 3rd. Seems strange that not much has been said about > this issue. Can someone offer any information on why this is happening? > > I would appreciate any insight. > > > > Thank you, > > > > Ali > > > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson // Wombatmail // Chicago Deliverability: https://spamresource.com DNS Tools: https://xnnd.com ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [External] Help with listing on Invaluement
I saw your "answered off list" post. Cheers, Al On Thu, Oct 7, 2021 at 11:34 AM Rob McEwen via mailop wrote: > > On 10/7/2021 12:02 PM, Kevin A. McGrail via mailop wrote: > > Lyle, I gave Rob a heads-up on your email. > > > Soon after Lyle's message - about the same time Kevin was kitting "send" > on the message above - I sent mailop an "answered offlist" message - but > it looks like that never made it to the mailop list? > > -- > Rob McEwen > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson // Wombatmail // Chicago Deliverability: https://spamresource.com DNS Tools: https://xnnd.com ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] IPv6? (was: Google should be burnt or blown up (was: Gmail putting messages to spam)
On Mon, Oct 4, 2021 at 5:27 PM Alexey Shpakovsky via mailop wrote: > > On Mon, October 4, 2021 23:17, Michael Peddemors via mailop wrote: > > > > Turn off IPv6 ;) > > May I hop on the bandwagon and ask everyone on this list what was your > experience with spam WRT IPv6? My admittedly US-centric and Gmail-centric experience with IPv6 is that an IPv6 IP starts out with a much lower reputation as far as Gmail is concerned and it takes a lot of work and prep to deal with that. And Gmail blocks mail from IPv6 hosts lacking rDNS, and not everybody implements rDNS in IPv6. I always turn off IPv6 on my VPSs and cloud services, since I'm always email-focused in one way or another. A few times a year, somebody will come here to Mailop or elsewhere complaining that they can't get mail delivered from their hobbyist site to Google over IPv6. Literally the quickest fix for most of them would be to simply send mail over IPv4 only. https://www.spamresource.com/2020/11/honestly-dont-send-to-gmail-over-ipv6.html > From my small server, I see over 99% of abuse coming from IPv4 servers. You're not wrong... but it's also a case of you're seeing most mail at any scale come from IPv4 servers, spam or not. There are a billion tons of email infrastructure out in the world all doing the work over IPv4 and that actually doesn't seem to be going away anytime soon. If there is any sort of consensus about it, it might be that while the end user infrastructure moves on to IPv6, that leaves enough IPv4 space available to probably host every email service forever. Cheers, Al Iverson -- Al Iverson // Wombatmail // Chicago Deliverability: https://spamresource.com DNS Tools: https://xnnd.com ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] USGOabuse.net?
USGO used to be called USFamily.net and most of those reports used to be initiated by a guy named Ron Cleven, not sure if he's still there. He has strong opinions and the verbiage in the reports is likely aggressive because of that. Treat them as FBL reports; unsub the complainer, make sure you're not infected in some way, then beyond that, don't worry about it. There is no broad scale blocking that is going to come from that report, in spite of the aggressive wording, based on my many years of receiving those. :) Cheers, Al Iverson -- Al Iverson // Wombatmail // Chicago Deliverability: https://spamresource.com DNS Tools: https://xnnd.com ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
