On May 10, 2018 11:10 AM, Gilles Chehade <gil...@poolp.org> wrote: > > On Thu, May 10, 2018 at 10:18:32AM -0400, Predrag Punosevac wrote: > > > > I was wondering if somebody could give me some insight into how is the > > new SMTP client related to OpenSMTPD? > > > > Eric wrote code to simplify the SMTP client engine in OpenSMTPD and help > with the cleanup I mentionned at EuroBSDCon'17. > > His code happens to be standalone enough that he wrote an SMTP client on > top of it so we have a proper tool to perform SMTP sessions because that > is a recurring need and we kept using shitty scripts or manual sessions. > I'm not only talking as a developer here but as a mail admin too. > > The SMTP client code he wrote is going to be what OpenSMTPD uses in some > months to replace our ageing SMTP client layer. > > He did not write a tool, he wrote an SMTP engine THEN he wrote a tool on > top of it and committed both the engine and the tool. > > > > I would think one could create a > > "new" SMTP client by a straight forward surgery on OpenSMTPD. > > > > Yes, that's doable. > > Except that the code he would have surgically extracted is the code that > will soon get replaced with the code he committed. > > > > How does the new SMTP client compare to DragonFly Mail Agent (dma)? > > > > The new SMTP client is a simple tool to perform an SMTP session and does > nothing more than that. If a use-case involves doing an SMTP session AND > something else, the tool became the wrong tool at AND. > > I'm not familiar at all with dma but I assume it does a bit more.
It is basically femail with a few extras. > > > > As most > > machines these days just need to send an e-mail to the relaying SMTP > > server are there plans to make new SMTP client default instead of full > > blown OpenSMTPD. > > > > That is doubtful. > > I do not think most machines just need to send an e-mail to the relaying > SMTP server, most machines would also need the mail to be retried if the > server is unreachable, sender to be notified if the mail ttl is reached, > handle local aliases, .forward, etc... it goes FAR beyond that tool. > > Now I may be biased but I think a "full blown" OpenSMTPD does not have a > huge overhead given how we fought feature creep. I don't think you would > have a much simpler code path if you used OpenSMTPD or added server code > in front of this new SMTP client to allow enqueuing. > > > -- > Gilles Chehade > > https://www.poolp.org @poolpOrg >
