Feel free to tell me I'm naive/unrealistic/self-serving/whatever (granted I run a 98% B2B email hosting company), but I think we on this list bear a collective responsibility to educate users that:
1. Free email service providers have a level of customer service commensurate with their prices, and; 2. The terms of service for all of the free email providers (whose ToS's I have read, which is most of them) contain comparable clauses which grant them a perpetual, irrevocable license to email content, including republishing rights and the rights to create derivative works. Sure, there's a role for free email service providers, but not for really important emails IMHO. Especially not where the contents are sensitive/proprietary/regulated etc., and/or where delivery must be traceable and delivery fails rectifiable. What AT&T decides to do (or not do) is up to them. But, if we educate our customers that deliveries to free email service providers are neither guaranteed, nor is there a mechanism to sort out delivery issues with such free email service providers in a timely, interactive manner -- as well as that the contents of those emails are no longer private -- then, at least with my customers, I have seen my customers better manage their own customers' expectations when their customers are using a free email service provider. Hope that helps, Mark -- _________________________________________________________________ L. Mark Stone, Founder North America's Leading Zimbra VAR/BSP/Training Partner For Companies With Mission-Critical Email Needs ----- Original Message ----- | From: "Scott Mutter via mailop" <mailop@mailop.org> | To: "mailop" <mailop@mailop.org> | Sent: Tuesday, July 9, 2024 3:38:07 PM | Subject: Re: [mailop] [E] Re: AT&T Block | On Tue, Jul 9, 2024 at 12:53 PM Anne P. Mitchell, Esq. via mailop < [ | mailto:mailop@mailop.org | mailop@mailop.org ] > wrote: || Instead of grumbling, if you can give us information, perhaps someone here can || help you. | You are right - if an IP is blocked, it's likely blocked for a reason. The | question is whether that reason is stupid or not. | A lot of times I suspect that the IP address is blocked because of a larger | network block. Instead of blocking individual IPs, providers choose to block | entire Class-C's or Class-B's. | Now, as I've tried to explain - perhaps I did that poorly - that's not the way | IP addresses are used any more, at least in some industries. If, as a provider, | you are getting spam from 23.239.97.121, 23.239.97.63, and 23.239.97.24 - then | when you block the entire Class-C [ http://23.239.97.0/24 | 23.239.97.0/24 ] , | you're blocking a lot of IPs that have nothing to do with each other. I | understand that you, as a provider, can't really know that. But, as a teaching | moment, you - as a provider - should know that this is plausible. | I understand that people probably don't want to hear that because it goes | against what they've gotten ingrained as how server administration and IP | addressing works. There's a lot of "My way works, it's always worked, and | that's the way it's always going to be." | As I've said, we're on this list to learn, correct? | Having said that - I don't so much mind a provider blocking an entire Class-C, | BUT when a verified administrator of an IP address in that Class-C writes in | about the block and you can find zero/zilch/nada complaints of spam from that | IP address, then it should be excluded from the block. This process shouldn't | take days or weeks to complete, it should just take hours. | And if a too-big-to-fail email service provider is going to block IP addresses, | they should offer Feedback Loops and they should have to send something to that | Feedback Loop before the IP address can be blocked. Numerous times I've had IPs | blocked when the IPs were on Feedback Loops and I've gotten zero/zilch/nada | from the Feedback Loop prior to the block happening. I've never gotten a hint | of ANY activity on any of our servers with Google because apparently we fall | below the cutoff to register any type of feedback. If we register that low, | then what's the justification for blocking a server when we can't get any | feedback? | My gripe right now with AT&T is why do they even include [ | mailto:abuse_...@abuse-att.net | abuse_...@abuse-att.net ] in their rejection | notice if they're never going to respond to inquiries to that address? I wrote | that address on July 2 about an IP being blocked. It's now July 9th. I haven't | heard a peep from them. No I have written them again. I shouldn't have to. If | they're telling me to write to [ mailto:abuse_...@abuse-att.net | | abuse_...@abuse-att.net ] to get my issue addressed then they need to expect | email at [ mailto:abuse_...@abuse-att.net | abuse_...@abuse-att.net ] and | respond to those messages. They're not doing that. Before they shutdown their | community forums there was a HUGE thread there about the lack of response from | [ mailto:abuse_...@abuse-att.net | abuse_...@abuse-att.net ] . This has been | going on for years. | It's not necessarily the act of blocking IPs that gets stuck in my craw, it's | the lack of avenues for timely remediation. It's the lack of evidence to | support an IP specific block, whether that be a Feedback Loop or listing with | another publicly accessible RBL. It's the lack of avenues to notify beforehand | that a new IP address will be sending out mail. It's the lack of understanding | that an IP address owner isn't necessarily the administrator of the server | operating on that IP address. And there's a lack of caring to learn anything | new. | This will be the end of email when providers and administrators all around the | world stick to their "it's my way or the highway" motto and email | interoperability goes out the window. | _______________________________________________ | mailop mailing list | mailop@mailop.org | https://list.mailop.org/listinfo/mailop _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
