On 10/14/20 4:01 PM, gil...@poolp.org wrote: > October 9, 2020 1:29 AM, "Demi M. Obenour" <demioben...@gmail.com> wrote: > >> I was looking at the EuroBSDCon 2017 presentation on OpenSMTPD, and I >> was wondering how it differs from the dedicated high-volume MTA that >> wound up being written for the ESP. What are the features that are >> needed for high volume, but otherwise don't make sense? >> > > Hi, > > I should probably write an article about that, I'll keep this mail short. > > When you enter the realm of high-volume MTA, the rules of SMTP change and > a general purpose MTA will no longer do the job: you're no longer below a > radar for big ISP and big mailer corps, you're now hogging their machines > and need to comply to a ton of SMTP-unrelated rules.
That makes sense, thanks! I was wondering if OpenSMTPD could not handle the load, and was not aware that there were other rules that had to be followed. I am looking forward to your article. > There are limits to enforce and they are not like the generic ones we use > in OpenSMTPD, they are faaaaaaar more fine-grained. For example, some are > tied to your domain/IP reputation and need to be adapted dynamically, and > others apply to a whole cluster of MX meaning that your MTA needs to know > that domain X and Y share the same limits because they both have an MX in > the same cluster and the limits apply to the whole cluster. A lot of this > is unrelated to SMTP and makes the SMTP engine much much more complex. It > is possible to tweak a general purpose MTA to kinda work, it just takes a > ton of work. > > Then another issue is that when you start going above radar, you start to > get feedback from ISP and big mailers ... encapsulated in SMTP responses. > You can no longer just handle SMTP responses like 421 or 550, because the > human message that follows will contain a destination-specific code which > will provide more info (or not) about why the error happened. If your MTA > is unable to handle these, then when you get a 550 from microsoft you are > going to permanently fail the message when you maybe should have waited a > bit to retry. With a general purpose MTA, some of your recipients are not > going to receive their mail, it's that simple. Are these documented anywhere? Just curious. > With a general purpose MTA and custom tuning you can send quite a lot but > there's still a limit to it. You can push that limit with good reputation > but at some point, unless you're part of the big ones you'll start having > issues. What factors made it better/simpler a new MTA from scratch, rather than incorporating those rules into OpenSMTPD? Right now, there are no open-source (or even self-hostable) high-volume mailers that I am aware of. From my (outsider) perspective, it appears that while those rules add significant complexity, they otherwise would not be harmful in a general-purpose MTA. The best current practice for high-volume business mail seems to be “pay a third-party service that specializes in this”, which is somewhat disappointing. Thank you, Demi
OpenPGP_0xB288B55FFF9C22C1.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature