On Wednesday, 07 September 2005 at 09:24, Thomas Roessler wrote: > On 2005-09-06 11:39:33 -0700, Brendan Cully wrote: > > > Attached is Michael Elkins' SMTP relay patch patch.me.smtp.3 > > ported to 1.5.10. I've replaced smtp_host with smtp_url so you > > can override the port, and because I intend to add AUTH and TLS > > support to it shortly. It's such a tiny patch that I have a hard > > time considering it to be bloat, and if it isn't very > > full-featured, nothing stops you from using the standard > > process-based interface. > > > Apologies in advance if this starts a flamefest. > > I'm not going to start a flamefest over this. However, I don't see > that the benefit of having SMTP support in mutt overrides the cost > of having to support yet another module in the future. > > Which is why I would prefer not to include it. Nowadays msmtp does a nice job as a submission-only client. And I almost feel sad about the effect that integrating this patch might have on the cottage industry of smtp clients that have sprung up to support mutt over the last few years. On the other hand: 1. SMTP is really not a hard protocol. I'm not proposing queuing or mail acceptance (those can be hard), just a couple of headers and a file write. I don't know if I still believe that we have to worry about dealing with all kinds of broken SMTP relays either. 2. Most of the infrastructure is already in mutt (networking, authentication, SSL, even IPv6), so the actual smtp module is very small. Considerably smaller than even msmtp. 3. You do get some added convenience from integrating it. For instance, mutt can get your SMTP password once (per account) per session and remember it. This makes it less necessary to store that password in a config file. > That said, if this one is included, it would probably be useful to > add an option that makes it possible to set the envelope sender on a > per message basis. This goes beyond the current envelope_from > option, as it would enable people to send their envelope from to be > different from the header from address. > > (With the current MTA interface, one does this adding a -f parameter > to the sendmail command line.) It'd be tempting to make $envelope_from an address (possibly renaming the current $envelope_from to $use_envelope_from). This is a simple thing to do, but why is it specific to the SMTP relay? ie why didn't/don't we do this for the regular old sendmail interface?
Attachment:
pgp2mdwNFQUOB.pgp
Description: PGP signature