On Thursday, 08 September 2005 at 16:59, Alain Bench wrote: > Hi Brendan, > > On Wednesday, September 7, 2005 at 8:02:36 AM -0700, Brendan Cully wrote: > > > to make $envelope_from an address (possibly renaming the current > > $envelope_from to $use_envelope_from). > > My humble: > > · Renaming vars should be avoided, unless tremendous benefit. I don't like it either. I just couldn't think of good variable names that wouldn't cause confusion. Maybe symlink envelope_from to use_envelope_from and add envelope_from_address? > · Changing semantics... loads of MAIL FROM:<yes> to be expected. that's true. > · A way to set arbitrary envelope sender is needed... > · ...but it needs to be difficult. A special variable just for that may > lead users to easely use it uselessly and thus harmfully. I don't think it needs to be too difficult. There are enough obscure config variables already that we'd get a little "security through obscurity" for free :) > · Consistency across sending methods and apps is desirable. > > The explicit -f in $sendmail way *was* OK: A not too tempting > possibility. But not applicable for SMTP. I am not in favour of a > variable, too easely misused. Especially not if named $envelope_from. > > What do users possibly need as envelope sender? In the vast majority > of cases, the same address as in "From:" field ($envelope_from=yes). In > more rare cases, username@localhost or such, to be later masqueraded by > MTA ($envelope_from=no). Arbitrary envelope sender is needed only in > very specific corner cases. > > > $envelope_from=no in $sendmail case causes in fact *no* sender > determination by Mutt, but by the $sendmail app: Generally > username@localhost. $envelope_from=no in SMTP case should probably cause > Mutt to do MAIL FROM:<username@localhost> itself, no? Hmm, this would strongly imply that there was an MTA running on whatever localhost expands to, in which case why bother with using SMTP directly?
Attachment:
pgp2uZfLw9PDY.pgp
Description: PGP signature