Dňa 10. júla 2023 16:44:55 UTC používateľ Grant Taylor via mailop <mailop@mailop.org> napísal:
>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. If something have to be said, then it have to be said and then doesn't matter who said it ;-) >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. Nowaydays (especially joung) people tends to feel as experts, when they setup something first time. Thus, when not used word by word, it is good reminder. On other side, i work with computers & networks for more than 30 years, and still have questions ;-) >> 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. I start to maintain my own mail after 20 years of experiences with other nerwork services (both, LAN & WAN). Before that i afraid, that my experiences are not enough to fight with SPAM (in both directions, incoming & outgoing). But finally i recently (some years) decided to start with it, thus my point of view is relative fresh. Setup and get it working is not different than other services, not more easy nor more hard, just different. It requires to learn how to setup particular SW as in other services. What i see as more hard with email is: + it is not one protocol (SMTP and IMAP/POP) + it is not one SMTP purpose (MTA/Submission) + terminology is not clear (how many terms eg. for return-path, relay, etc) + it is very flexible, choose proper topology is not easy without some experiences + many roles, which one MTA can do + too many RFCs describing email, and some of them are not well cooperative + outdated or incomplete/wrong guides + lack of (open source) tools to work with eg. MIME mails These things make email harder to start, than other services, but after one got them, it is as easy/hard as any other service. BTW, what i most afraid (before i start) was how i will fight with SPAM to (required) postmaster mailbox. But that simple doesn't happen and that address gots near to no SPAM. >> * 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. Yes, but will iname it as good practice, not as best. >> * manage DNS MX, DKIM, DMARC and SPF records >SPF, DKIM, and DMARC are the order that I'd advise others be implemented. I have mixed feel from these. While can be "good friends", it seems that they involved to "bad boss". I feel, that particular RFCs was done by people, who consider them as "must have" and thus they mention cases (eg. DMARCs none policy) in not clear way, and doesn't describe clearly what to do if not all are implemented (eg. SPF without DMARC) on receiver side... >Chances are quite good that you will be able to exchange email with domains >that aren't hosted by the email oligarchs. That oligarch's behaviour is IMO direct result of aforementioned "must have" approach. >> * manage reverse lookup records, including managing the uncertain chain of >> authority between the instance and the nearest SOA >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. I meet rejects due forward confirmed reverse DNS fails, then i setup it. But i agree, that mention it as requirements is wrong. I run own LANs MTAs and forwad to ISP's smarthost for years, no IP is involved, but it is still own email server (including IMAP via fetchmail). >> * manage certificates associated with TLS for SMTP and IMAP > >I'll argue that TLS is not strictly required. I do not agree here. Don't forget that both are used by clients (Submission), the plaintext for that is deprecated for years, recently even STARTTLS was marked as legacy (sorry, i don't remember RFC number). Running these over plain text is questionable even in LAN, especially with wireless connections. This makes TLS strict requirement for Submission, IMAP & POP3, in best with trusted certs. In SMTP (MTA-MTA) it is not as strongly required, but IMO after Snowden, using it without TLS must be only rare. Sure, one cannot know how mail will be relayed latter, but one have maintain/setup own services. >> * manage DKIM certificate Please, how this DKIM certificate looks as? Where its format is defined? >> * keep the MTA secure and free from DOS attack :-))) >> 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. IMO because here are missing some steps: + define/clarify terminology (someting as DNS has RFC for) + define/clarify MTA roles While i conider the first as doable (IMO really missing), the second will be hard, due email flexibility here are too many roles and try to describe them will be outdated/incomplete right after publishing. IMO here is only one way for that BCP -- do not try make it universal, but publish it per MTA role, eg. BCP for outgoing (to public net), BCP for for MX (from public), BCP for backup MX, etc, etc. And really first step have to be to define four letter abbreviation for Submission, because nobody will write Submission instead of SMTP. While both use the same protocol, its requirements differs and using SMTP word for both complicate it. >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. Untill all forms (big, small, personal, etc) of email operators will not be taken into account, it will not be usefull. >> * Use a static IPv4 address for your email system >I'm eliding v4 vs v6. Yes, mention only IPv4 decreases quality. And using IPv6 slighty complicates things -- is one host the ::/128 or the ::/64 ? >What about the SMTP protocol works any different with a static IP address vs a >dynamic IP address? Because people tends to simplify things, using induction (which mostly doesn't provide right result): compromised host are attacking, simplest hosts to compromise are end users and IoTs, they have dynamic IPs, thus all dynamic IPs are wrong. That whole is wrong. It is wrong, because not all end user's hosts nor all IoTs are compromited and because not only end user's hosts or IoT are compromited. On rise of VPS, i am not sure if they have to be considered as not end users's hosts, at least this cannot be generalized, especially not generalized by IP, but they often has static IP... >What defines "in the cloud"? Cloud is magic word, which will solve all your problems :-D >> * Your system should say HELO (or EHLO) with its hostname >I completely agree that it's much nicer to have your MTA hello with it's own >host name. Mutch nice will be, to use hello based on target domain, but that is near to impossible in environment sharing the same host (IP) for multiple domains. Partially solvable after STARTTLS with SNI, but that happens after initial hello... >> * Keep your software completely up-to-date >I agree that this should be done. I use debian's oldstable, even oldoldstable. Are they "completely up-to-date"? AFAIK they are... No known security holes... Do not forget, that any SW has bugs, thus software update comes with new bugs ;-) >> * Ensure that only authorised users can send email through your system. > >What constitutes "authorization"? And we are back on terms clarify... >Conspiracy theory: Didn't the DoJ have something to say about an OS oligarch >doing things like this in the '90s? "Conspiracy theory" -- is it term for things, for which someone is happy, that facts about it are not public (yet)? What eg. GDPR is trying to solve was named as "conspiracy theory" before it... >> * Be reliable (viz have at least 4 9s availability) >I maintain that someone / something really SHOULD be always available to >receive messages to your domain. But that can be a backup MX. No SMTP was designed with outages in mind. One have to try delivery repeat for at least 5 days. That this not allways happen? Sure, people are forgetting that things are not alwas smooth... >> * 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: What is OK for one target can be BAD for another. One cannot satisfy all, we know. "Good reputation" is bad wording into best practices. regards -- Slavko https://www.slavino.sk/ _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
