On Tuesday, April 12, 2022 at 12:43:55 AM UTC-5, Grant Taylor wrote:
> On 4/9/22 5:46 AM, None wrote:
> > Yes. yes. Currently my reasons for using this are
> > - envelope should be route-able, from: idk (only skipped a bit through
> > these rfc's)
> I believe the envelope sender is an opportunity to encode debugging
> information. E.g. VERP.
>
> I believe that there are other SMTP options that are woefully under
> used; ORCPT, notify, etc.
> > - most 'normal' email have an envelope = from:
> Maybe. Don't rely on it.
> > - spf check results are already available
> > - automated systems (not made in India) are expecting errors there and
> > most likely have some sort of exception handling that tries to report
> > something back (on a web interface).
> I feel the need to state that there is a big difference in what happens
> during the SMTP transaction vs what happens after. Rejecting the
> message during the SMTP transaction leaves the responsibility with the
> sending system, thus putting it on the hook for undesirable behavior.
> Bouncing after accepting a message means that you are on the hook for
> the undesirable behavior. -- Focus on what you can influence. Reject
> at SMTP time if possible.
> > I will have to test between these two. I am more and more thinking about
> > dumping all the email traffic in something like prometheus/influx, so I
> > can compare and graph the results better over time.
> I'll take John's statement one step further. I prefer it when the
> sending system (CRM et al.) is actually the SMTP client so that it has
> /direct/ visibility into things. Sometimes it's possible to learn
> /more/ information /faster/ than having things loop through an
> intermediate SMTP relay. Especially if the receiving system uses proper
> or enhanced status codes.
> --
> Grant. . . .
> unix || die