> "We should send all email as '[email protected]', no matter who the real sender is, makes it harder to blacklist any one sender".
I wish I could make a hard case to change that. I still have to battle with some big international customers that are so 'corporate' that they cannot change their DNS. Google and Microsoft are very cautiously indicating that it will give it a spam rating if you don't. But I need simple and firm words to sway customers into strong authentication. My customers think I am nagging them for no good reason. It would also be nice if the 'p=none' policy would be called 'testing phase' in DMARC. I see too many corporates staying there. Met vriendelijke groet, David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) ----- Oorspronkelijk bericht ----- Van: "Michael Peddemors" <[email protected]> Aan: [email protected] Verzonden: Maandag 13 februari 2017 18:49:01 Onderwerp: Re: [mailop] Enforcement of RFCs [was: GoDaddy Email admins' in the house?] On 17-02-12 04:52 AM, Rich Kulawiec wrote: > On Wed, Jan 11, 2017 at 12:33:47PM -0800, Michael Peddemors wrote: >> More and more, if you want to deliver email in today's environments, you >> have to ensure your email servers are correctly configured. > > I think there's considerable value in slowly enforcing this in stepwise, > announced fashion. This is what we have been doing the last 15 years :) > I'm not suggesting we all start being RFC compliance fascists tomorrow. > (Especially since some of the newer standards are topics of well-grounded > disagreement and some are still evolving.) Granted, however we are talking about things that have been 'agreed' apon for many years, part of most anti-spam recommendations (was just re-reading the recommendations that industry worked out in 2005) > That's why I said "stepwise, announced" above. I'm suggesting that > we enumerate a rough list of the things we see that are REALLY wrong, > prioritize it, make a schedule for it, announce it, and do it. E.g., > "HELO as localhost.localdomain will not be accepted as of X/Y/Z". We have done that (as well as many others) as a 'policy' for many years now.. What we did is take 'Best Practices' rules, slowly use them for marking messages as likely spam, then as the statistics show the volume gets low enough, make it a policy, and reject with a clear rejection notice telling senders why the message was blocked. It actually helps the non-informed. They wonder why messages don't always get through, but by sending the rejection notice, responsible operators quickly 'fix' their systems, and the world is a better place. > I'll argue that we should deal with the easy, obvious stuff first: the > stuff that should have been done right 25 years ago. (Like that example.) > Some of this has already been done in piecemeal fashion over the past > decade-plus, but (a) much of it hasn't been coordinated and (b) much of > it hasn't been announced. Yes, let's get the 'easy' stuff done now. If operators don't do the easy things, the 'advanced' things will never get done. Of course, there are always those out there that don't want to change.. "We run white label services, so we don't want to use valid PTR records" <sic> There have been many different channels, industry groups, best practices, RFC's and legislation out there, the problem always lies when a 'business case' insisted on by management, trumps doing things the right way.. and we all know many cases where that is true.. "We have to send all messages, even though we know it is spam, we will just 'mark' it as spam, and send it along" "We should send all email as '[email protected]', no matter who the real sender is, makes it harder to blacklist any one sender". "We don't monitor activity, because that might make us culpable" "We don't want to require TLS/SSL by our customers" "We don't want to force the use of the submission port" "We don't want to implement per user outbound rate limiters" "Business XXX makes us too much money, to force best practices on them" "I know, but the CEO couldn't send an email from his 14 year old fax machine if we enforce SMTP AUTH, so we just allow full relaying from all our network(s)" In the end, the only way to trump those kinds of 'business cases', is to create a stronger 'business case', eg by not accepting email from those that conduct themselves in that way. > And it would be better to do this as community than to do it separately, > because it will avoid the "you're doing this because you're huge" and > "nobody else is doing this" and "why are you suddenly doing this?" and > "it worked yesterday" and the other zillion reasons why people want to > keep running really, really broken mail systems. Again, we 'have' done this as a community.. However, as a community, while we agree on how things 'should' be done, we can't get the community to actually enforce those things.. when even the largest providers in the industry won't enforce them, it is really hard to get the rest of the world to do so. You know how frustrating it is, when you tell a customer, "Sorry, but you have to follow Best Practices" and they come back with, "Well, Gmail/Hotmail/Name your 'Too Big to Block' allows this..." But, experience has shown, that the companies that do move towards enforcing best practices, in the end have much lower support problems, than those that don't. It is when you have a policy, that will make a thousand people happier, but one person unhappy.. that business decisions to appease the one person are always crippling the efforts.. Especially when that one voice is very loud.. > ---rsk > > > _______________________________________________ > mailop mailing list > [email protected] > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > -- "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 [email protected] https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop _______________________________________________ mailop mailing list [email protected] https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
