[mailop] Any Spectrum/Charter folks on here?
If so, please reach out to me off-list - I have a transactional sender running into issues with Charter specifically. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Force double opt in for marketing list companies per email address
Thanks for being a voice of reason, Matt. ESPs don't always get things right, but the ESPs who are participating in M3AAWG or joining forums like this one are trying to do the right thing. Bounce handling is difficult because bounce messages are like an episode of Whose Line Is It Anyway? - the status codes are made up and the text doesn't matter. Sure, there's RFCs, but once you've spent a few days going through your logs to try to improve your bounce handling and see some mail operators using 4XX bounces for what should really be a 5.1.1 invalid recipient, you lose hope in the system. If I knew what every ISP wanted me to do after a given bounce, I'd do my best to respect that, within the boundaries of the service that I am also obligated to provide my clients. This is what we're working with, though: 451 Invalid Recipient - https://community.mimecast.com/docs/DOC-1369#451 [Lzabfop9Nva0NP5E_GxwYg.uk119] 553 sorry, no mailbox here by that name. ulc: 65216002578, rcp: 0001. (#5.7.1) 554 5.7.1 : Recipient address rejected: user redac...@lycos.com does not exist 550 5.4.1 Recipient address rejected: Access denied. AS(201806281) [ SN1NAM01FT027.eop-nam01.prod.protection.outlook.com] 554 delivery error: dd Not a valid recipient - atlas215.aol.mail.bf1.yahoo.com We can all agree that a bad address should be a 550 5.1.1 error, yes? Surely we can agree on that much, since it's in the RFCs? https://www.greenend.org.uk/rjk/tech/smtpreplies.html https://tools.ietf.org/html/rfc3463#section-3.2 Mimecast, Microsoft and Verizon Media Group are not small companies. The only reason I even know the Microsoft bounce should be codified as a hard bounce is thanks to the kind folks at SparkPost for posting publicly about it: https://www.sparkpost.com/blog/bounce-classification-code-change/ I mean, if I was trying to figure out what to do with that bounce on my own, what would I do? Well, let's start with the RFC... X.4.1 No answer from host The outbound connection attempt was not answered, because either the remote system was busy, or was unable to take a call. This is useful only as a persistent transient error. Only useful as a persistent transient error? That's odd, because it was a 5xx error, not a 4xx error. Access denied? Access denied *to whom*? My IP address? My MAIL FROM domain? The sender in the friendly from? If I can't definitively tell my customer that the address is undeliverable and will never receive messages, then I have a duty to attempt subsequent deliveries until we hit our own internal threshold for converting soft bounces to hard bounces. The business logic for that determination is going to differ from ESP to ESP. I'm not saying this as an attempt to call anyone out, or start a fight, but my point is that those of us who are active in these industry mailing lists and conferences are the ones who care. We want to do better. We're up against forces internal and external. If we got it wrong, help us make it right. Maybe a C-level told us we had to do something a certain way and having an email from the ISP themselves saying "That's bad and wrong, don't do that" would tip the scales. Maybe things have changed since that legacy code was written 5 years ago and we need a nudge to refactor it. Maybe someone recently introduced a bug with the last deploy that our testing didn't catch. We're all up against the same challenges here, these are things that occur at ISPs as well. How many threads have we seen for "Is anyone else's GPT data missing/wrong" or "What the heck happened with valid emails bouncing at Yahoo yesterday"? These things happen, they happen despite our best intentions, and the sooner we learn to work together to fix them and move on instead of worrying about where to assign blame, the better the ecosystem will be for everyone. Best regards, David Carriger On Fri, Jun 5, 2020 at 8:52 AM Matt V via mailop wrote: > On 2020-06-05 10:09 a.m., Atro Tossavainen via mailop wrote: > > Furthermore, I explicitly indicated that it was the consensus that the > GDPR makes it effectively impossible for them to do what you believe I > said, which I did not. It has been discussed in so many M3AAWG meetings > and between meetings, and Simon McGarr's talk "So you want to be a data > controller" was more or less on this subject. > > I don't know how you have managed to read exactly the opposite of my > intentions into my words, I can only conclude that it must have to do > with my awkward non-native use of the language because all other > explanations seem so futile. Here is what I said, for a recap. > > Most ESPs want to remain as data processors under GDPR and do not want to > be put in a position of being a data controller. Utilizing data across > multiple accounts has some very interesting impacts in regards to the > responsibility of the controller/processor or controller/controller > relationships of data. > > As for ESPs and the emails that they process on
[mailop] Anyone have any luck delisting from Microsoft's Advanced Threat Protection (ATP)?
Hi everyone, Has anyone had any success in getting false positives removed from ATP? There isn't any public delisting endpoint available, and emails to various Microsoft email addresses, as well as open support cases, have not been met with much success. The support case is #19907517, for any interested Microsoft folks who might be on here. Best regards, David Carriger ActiveCampaign / Deliverability Engineer ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] Can someone from Microsoft reach out off-list?
We're seeing some false positive issues with Office 365 Advanced Threat Protection, and there doesn't seem to be any public-facing form where we can submit false positives for review. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Our customers e-mail constantly going to outlook.com junkmail (any Microsoft people around?)
This is a very difficult problem to solve, as evidenced by the fact that companies who claim to have solved it are worth billions of dollars. The crux of the issue is that there isn't effective two-way communication between senders and receivers. I work for an ESP. We try to keep bad senders off of our network - sometimes with varying degree of success, but we do our best to keep our mail stream clean. I know other reputable ESPs try to do the same - look at MailChimp's investment into Omnivore, for example. Every time I speak to someone at another ESP, the first question asked is "What are you doing about Microsoft? How are you getting to the inbox at Microsoft?" None of us have any answers. We subscribe to eDataSource and use their data to track our inbox placement as well as competitors. So, I can tell you when Microsoft changed their machine learning algorithms - we saw a huge jump for everyone a few months ago, 30%+ for many senders. However, there was nothing we did that caused that. Our mail stream didn't change. SNDS, JMRP, these tools are simply inadequate to diagnose issues because most of the decision-making happens when the email hits the machine learning model, and those decisions aren't served up in any meaningful way. Obviously we still use them because some data is better than no data, but the fact is that SNDS can report that everything is fine while email doesn't get delivered to the inbox. If you open tickets with tier 1 support, they reply with the same canned responses pre-approved by legal. "Follow best practices, read these help articles, sign up for SNDS and JMRP, etc." It's the same everywhere. I've done consulting for individual clients and it's the same story if I open a support ticket with Oath or anywhere else. None of them know what the machine learning model is doing, none of them can tell you why emails are being filtered, nobody knows. If you ask them to escalate, they don't. They respond with the same pre-approved answers and ignore the fact you asked for an escalation, or they stop responding to you entirely. The simple fact is that there is nowhere to escalate a request of "I think the machine learning got it wrong here" or "All of our data indicates this is a good sender, can you tell us why they're not?" I don't want to send spam. If I had better ways of proving which customers were spammers, they wouldn't be on our network anymore. For every customer our compliance team fires, we have to make a business case to someone at some level within the organization for justification why. That's easy to do when we can prove they're using a non opt-in list, or their bounce rates are high, or some other indicator that they aren't a good sender. But when their content looks legitimate, they're using SPF/DKIM/DMARC, their list is fully opt-in, they have a valid List-Unsubscribe, complaint rates reported by FBLs are low, IP reputation shows as normal, but emails don't make it to the inbox at Microsoft (but they do at Oath, or Gmail) - what am I supposed to say? I have to either say that Microsoft's machine learning knows something that Oath's and Gmail's doesn't, or that their machine learning got it wrong. ESPs are afraid to say this for good reason. If a company like Oath or Microsoft or Google decides to block our entire mail stream, we go out of business. It's as simple as that. If we don't say anything, then these problems continue for months or years and nothing is done about them. Then if you try to bring the issue up you get pushback - "It must be working, you're the only one who's said anything about it, if there were real problems then other people would have complained." I know it's broken when I can set up a brand new outlook.com email address and send an email to myself from inside Microsoft's own webmail client, and the message goes to spam. I know it's broken when clients attempt to hire me as a freelancer to diagnose why they're not getting emails inside Office 365 that they sent to themselves from an external mail system that they also control and whitelisted which only sends transactional emails. I don't know what to tell them except not to use Office 365, because I've never been able to escalate a problem beyond tier 1 support, where it goes nowhere. So I've become jaded into thinking that the only way to get eyes on the problem is if it impacts the bottom line. I'm not sure what the best way to solve the problem is in a reliable, repeatable, scalable issue. I fully understand why these companies have escalation processes in place and why you can't just bypass the normal ticketing process. However, it's exceptionally frustrating when you can never get escalated to someone who knows what they're talking about and who can help you identify or fix the issue. Fixing the issue may simply be giving me enough ammo to go to the CEO and say "We have to fire this customer if you don't want to tank
Re: [mailop] OutLook Feebback Systems, thoughts and suggestions
I can't speak for you, but working at an ESP, the data is relevant to me. If someone has reported an email as spam, I want to notify my customer and add that recipient to their suppression list. I don't want my customer damaging their reputation and my reputation by sending email to recipients that don't want it. If someone has reported their email as spam, they clearly don't want it. That's just as true whether the email was sent an hour ago or 10 days ago. From: mailop on behalf of Michael Peddemors Sent: Thursday, March 28, 2019 2:41 PM To: mailop@mailop.org Subject: Re: [mailop] OutLook Feebback Systems, thoughts and suggestions Not sure if I should rise to the 'flame bait', but frankly of course it is a choice.. non-essential logs first of all are not needed, and why would we put sensitive information on someone else's cloud if we don't need to? But the point was, is the information relevant? In this age of data overload, our people have better things to do. A truism is that if the information isn't relevant often enough, people simple stop looking at, or gloss over the data, and miss what is relevant. On 2019-03-28 2:25 p.m., David Carriger wrote: > Do you guys not have ElasticSearch or Splunk or Loggly or Scalyr or one > of the million other platforms out there? Hard drive space is cheap > enough these days that I have a hard time envisioning an > environment where getting logs from a mere 10 days ago is the problem. > > > *From:* mailop on behalf of Michael > Peddemors > *Sent:* Thursday, March 28, 2019 2:15:23 PM > *To:* mailop@mailop.org > *Subject:* [mailop] OutLook Feebback Systems, thoughts and suggestions > > About 6 months ago, we signed up for the Feedback loops for our own > email platform, and in that time probably had one legitimate report, and > several false positives, probably from user(s) clicking on the wrong > button on an email they really wanted > > However, a suggestion. > > If the date of the original message is more than 10 days in the past, > and a user clicks on the report as spam, don't bother sending a feedback > report.. > > Going 10 days back in logs is not always easily possible, and by that > time, if it really was a problem, it was probably taken care of. > > Thanks Staff - HotMail for your attention ;) > -- "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://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
