Grant, Well put.
I was just going to link to Gilles Chehade’s post (https://poolp.org/posts/2019-12-15/decentralised-smtp-is-for-the-greater-good/) I don’t find running my own personal email server that hard or time consuming. The most time consuming element being “keep OpenBSD updated”. :-) Sean > On Jul 10, 2023, at 09:44, Grant Taylor via mailop <mailop@mailop.org> wrote: > > Dear ${FELLOW_EMAIL_ADMINIATRATOR}, > > I don't know how to preface this email other than to say -- I believe the > following needs to be said lest we loose even more control of our email > community. > > I'm sorry that both 1) I feel that the following needs to be said and 2) that > I'm the one that's saying it. > > ... > > I can't say that any of Richard's comments are technically wrong. But I will > say that the tone of what the email represents is both disappointing and > concerning to me. > > N.B. that Richard is one of many that have said similar things. My comments > are *NOT* directed at Richard. > > Rather many of us are culpable for allowing things to get into this state by > not actively fighting against it. -- The first step is admitting you have a > problem. > > ... > > I agree that email is not easy by any stretch of the imagination. But > comparatively I suspect it's easier to host your own email than starting a > company to build a car from scratch. Is this a good comparison, probably > not. But is it true? I really hop so. > > On 7/10/23 7:48 AM, Richard Clayton via mailop wrote: >> not that I know of -- arguably there should be one, but perhaps it will just >> encourage unwise activity. I am reminded of Usenet advice of not posting for >> the first six months and if you ask why that is good advice then add another >> six months... > > I agree with -- what I'll call -- auditing. I don't agree with asking > questions meaning that you need to extend the audit time. I've seen some > EXTREMELY intelligent questions asked by people very knew to the situation. > > Simply asking a question does not, in and of itself, mean that someone is > ignorant of the topic. Quite the opposite can be true. E.g. "Is there any > reason to ever run an open relay? There seem to be LOTS of negative points > to doing so; <insert subset of the list here>." type thing. > >> I recently reviewed an IETF draft on (de)centralisation which observed that >> running your own mail system, rather than using a centralised provider was >> far too hard. > > This disappoints me, greatly. Both the idea that running a decentralized > mail server is hard and more so that such recommendations would admit or > worse support such a stance. > >> In discussions with Eliot Lear we ended up with a list of things you had to >> do: >> * configure and manage the MTA > > This is obvious and not specific to email. You have to configure the service > for any and all services. Chances of defaults doing exactly what you want > are quite rare. > >> * arrange for a backup MTA > > I'll argue that requiring a backup MTA is not strictly required. > > I'll absolutely agree that a backup MTA is best practice. > > There is a really big delta between strict requirement and best practice. > >> * manage DNS MX, DKIM, DMARC and SPF records > > None of those are strictly required either. Business to business email can > function without any of them. > > I'll VERY STRONGLY ENCOURAGE at the very least MX record(s). > > SPF, DKIM, and DMARC are the order that I'd advise others be implemented. > > Chances are quite good that you will be able to exchange email with domains > that aren't hosted by the email oligarchs. > > Aside: Have enough email administrators given up the torch and now started > praying at the alter of the email oligarchs? > >> * manage reverse lookup records, including managing the uncertain chain of >> authority between the instance and the nearest SOA > > I didn't have a problem with reverse DNS being required 22 years ago and I > have even less of a problem with it today. > > Yes, this can make it harder for someone to run an email server at home. But > if they really want to do this, they can find ways to make it happen. I'm > happy to help people make it happen too. > > There is also the fact that unless the ISP is doing egress filtering -- > that's it's own independent discussion which the lack thereof helps me in > this discussion -- users can probably have acceptable success with all but > the email oligarchs if they simply have their MTA hello as the name that the > ISP assigns to the connection presuming that the ISP has forward and reverse > DNS configured therefor. > >> * manage certificates associated with TLS for SMTP and IMAP > > I'll argue that TLS is not strictly required. > > I'll absolutely agree that TLS is a best practice. > > I'll also posit that IMAP is not required for email. > >> * manage DKIM certificate > > I maintain that DKIM is not a strict requirement. > >> * manage one's upstream to address PBL issues > > Maybe, maybe not. > >> * keep the MTA secure and free from DOS attack > > I have problems with that statement. > > 1st: What is "secure" in this context? > > 2nd: Why is anything other than an MTA less susceptible to a DOS attack than > an MTA? > > Also, Michael W. Lucas's I Have A Dream comment about "goals" vs "dreams" > comes to mind. > > TL;DR: Focus on goals, things that you can influence, and don't worry about > dreams, things that you have no influence over. > > Link - I Have A Dream > - https://mwl.io/archives/22749 > >> ALSO back in 2011 (when the world was a little simpler perhaps) I worked on >> a M3AAWG BCP on this topic -- which eventually went nowhere > > I question why it went nowhere. > > I also question why a (satisfactory) recommendation for how to run an email > server doesn't exist. > > I question what a satisfactory recommendation would be because I've seen MANY > tutorials on how to run an email server. I've seen just about as many > different recipes for how to make a BLT sandwich. > > Aside: I personally want M3AAWG to be a thing but it is a non-starter for me > as an individual small operator. I'm too small to participate. So ... for me > M3AAWG is pie in the sky that doesn't amount to anything other than lip > service others pay. > > Further aside: I feel like the both the email oligarchs and M3AAWG are gate > keeping. I hope that it's is both only a perception on my part and that such > is antithetical to their goals. > >> the list then was (and I stress this was not sufficiently peer reviewed then >> to be authoritative, but it was written by some experts) > > I sort of have a problem with the concept of "sufficient peer review" in a > list of what needs to be / should be done to host an email server. > > Why has running email become such a formal thing? > > Have enough people abdicated control of email administration that general > consensus is that it can only successfully be done by the email oligarchs? > > I definitely disagree, as evident by this, and many other emails from me. > >> * Use a static IPv4 address for your email system > > I question the veracity of the requirement for a static IP(v4) address. > > I'm eliding v4 vs v6. > > If DNS is fully functional and IP addresses don't change too quickly and TTL > is configured properly on DNS records, ... then why is a static IP address > strictly required? > > I'm seriously asking. > > I'm being pedantic. > > I'm doing this on purpose. > > What about the SMTP protocol works any different with a static IP address vs > a dynamic IP address? > > Obviously both the static and dynamic address need to be unfiltered and not > block listed anywhere. > > But why do I need to have my MTA's IP address hard coded? > > Why can't I have a sticky reservation in my DHCP server for my MTA? > > Why does it need to be a sticky reservation? > > This is but one of many questions that I ask about most lists about how to do > something. > > I absolutely agree that a static IP address is best practice and makes a lot > of things ... smoother. -- I don't know if it makes things any easier. > >> * Do not share this IPv4 address with user machines > > I think that's a best practice and not a strict requirement. > >> * Do not host your email system 'in the cloud' > > That statement gives me heartburn. > > What defines "in the cloud"? > > What differentiates "in the cloud" from "on premise"? > > How can the remote MTA differentiate from "the cloud" from "on premise"? > > I absolutely agree that there are some networks that are less friendly to -- > what I'll call -- white hat email servers for a number of different reasons. > But I think referring to these networks as "the cloud" is a misnomer at best. > >> * Make sure that your IP address is not listed in the PBL >> * Provide an MX record > > (See prior comment about MX record, or lack thereof, above.) > >> * Provide meaningful and consistent reverse DNS > > N.B. meaningful and consistent reverse DNS can include what looks like > "client123.abc.isp.example". > >> * Your system should say HELO (or EHLO) with its hostname > > N.B. nothing prevents your MTA from helloing with "client123.abc.isp.example". > > I completely agree that it's much nicer to have your MTA hello with it's own > host name. > > I agree that it's possible to rename the entire system running the MTA so > that it's host name is "client123.abc.isp.example". > >> * Keep your software completely up-to-date > > I agree that this should be done. > > But, I also agree that SMTP stacks from 25 years ago can still speak basic > SMTP in agreement with today's most current SMTP RFCs, with the most likely > exception being lack of encryption / STARTTLS support. > > Aside: I recently saw a discussion about an AWS SES, seemingly system having > been configured to require STARTTLS, fail to play well with others in the > sandbox when the receiving system didn't support STARTTLS. > > I say "didn't play well with others" because the AWS SES system simply closed > the TCP connection after the EHLO reply that didn't contain STARTTLS. I > maintain that the AWS SES system should have issued a QUIT, waited (a > reasonable amount of time) for the system to acknowledge and the two systems > to gracefully close the TCP connection. > > I consider the AWS SES system (gracefully) terminating the TCP connection > (with proper FIN sequence) after not seeing STARTTLS as a protocol violation > and simply rude. > > This is yet another example where the email oligarchs can be / are wrong > about how email should be done. > > Don't trust the big players to be correct just because they are the big > players. -- E.g. IBM vs Compaq a.k.a. "Snow White and the Seven Dwarfs". > >> * Ensure that only authorised users can send email through your system. > > What constitutes "authorization"? > > I agree that controlling who relays through your server is important. But > that control, er authorization, can take many forms; user name & password, > Kerberos, client IP address, recipient email address / domain. > > N.B. backup email servers use recipient domain to authorize relay through > them as the email goes to the primary email server. > >> * Limit outgoing email volumes > > .... > > What constitutes an acceptable vs unacceptable volume? > > I strongly suspect that -- whatever the number is -- there are many email > servers that exceed that volume on a daily basis. > >> * Accept reports of problems with your systems > > LOL > > I agree. > > Yet it seems as if the email oligarchs are well known for being neigh > impossible to successfully report problems to. From the outside, anything > more than an automated response -- barely more than an automated MDN -- is > virtually unheard of. > > From the inside of one such email oligarch, reporting problems was difficult, > having them acknowledged as a problem was more difficult, and seeing the > problem get fixed was ... well don't hold your breath. > > Aside: Don't put email oligarchs on a pedestal. > > Further aside: Why do we allow email oligarchs to get away with not doing > things that many say that all email operators must do? > > Rant: Email oligarchs abuse their size and market position to coerce, ne, > force others to play by the email oligarchs rules. > > Conspiracy theory: Didn't the DoJ have something to say about an OS oligarch > doing things like this in the '90s? > >> * Review the mail system logs on a regular basis > > LOL > > I absolutely agree that's a best practice. > > I absolutely agree that this is not a strict requirement for email to > function. > >> * Be reliable (viz have at least 4 9s availability) > > I'll argue that's not a strict requirement. > > I maintain that someone / something really SHOULD be always available to > receive messages to your domain. But that can be a backup MX. > > You can also play fast and loose wherein you rely on the sending system to > queue messages and re-try delivery at some point in the future. This is what > I would consider to be a Bad Idea (TM). > > I'll argue that it's technically possible to still have your mailbox host > connected to the world via UUCP dial up to a remote backup MX that accepts > and queues messages for you. > > Yes, /something/ really SHOULD be available 24x7 to receive email. That > doesn't mean that it needs to be your mailbox server. -- There are plenty > of services that will be an MX to the world for your domain and pass the > messages on to you when convenient for you to receive them. > >> * Don't be an open relay > > I completely agree with this hands down. > >> * Don't create backscatter > > And yet so many people do. > > I absolutely agree that this is a best practice. > > I reluctantly agree that this is not a strict requirement. > >> * Maintain a good reputatio > I want to agree. However I'm not aware of any email oligarch that has what I > would consider to be a good reputation. Or said another way I know many > small mailbox providers that have what I would consider to be a much better > reputation for: > > - responding to complaints (with more than an automated "we received your > message") > - actioning complaints > - doing the best they can to adhere to industry standards > - contributing to the community > > > > Grant. . . . > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
