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

Attachment: OpenPGP_0xB288B55FFF9C22C1.asc
Description: application/pgp-keys

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to