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
