* Dan Raymond via Postfix-users <[email protected]> [251224 15:36]:
> On 12/24/2025 12:48 PM, Marvin Renich via Postfix-users wrote:
>
> > * Wietse Venema via Postfix-users <[email protected]> [251224
> > 10:04]:
> > I think what the OP is saying is that when sendmail auto-generates a
> > "From:" header, it is getting the email portion from the -f
> > envelope.from, but the full name from the current user. I think he is
> > saying that an auto-generated "From:" header (in absence of -F) should
> > either use both the full name and email from the current user or
> > (preferably) use both the full name and email based on the envelope.from
> > address.
> >
> > If the primary use of -f was for specifying a non-root user of the host
> > where sendmail is being invoked when being invoked by root, I would
> > agree with the OP. But in my experience, the primary use is to specify
> > an email that is related to the current user, but not directly related
> > to anything specific to the current host.
> >
> > The fact that -f specifies an email (perhaps not associated with the
> > current host) as opposed to a host user is a clear indication that the
> > current implementation is correct.
>
> I suppose if the caller specifies "-f otheruser@otherhost" (is that
> allowed?)
Absolutely. The -f option, by definition, specifies an email address,
not a host user name. From the sendmail man page:
-f sender
Set the envelope sender address. This is the address where
delivery problems are sent to....
The envelope sender, in the SMTP protocol, has _never_ been a local user
name on the sender's host. It is a fully qualified email address.
If just the user name part of the email is specified, sendmail will add
"@$myorigin" if $append_at_myorigin is yes (the default).
> then there is no way for sendmail to determine the display
> name. In that case it should probably be blank or "<unknown>".
If you don't specify the full name, the default is the appropriate field
of the current user's entry in the /etc/passwd file (I'm pretty sure it
uses getpwent, so where ever nsswitch.conf has configured this).
> In my
> case I am specifying "-f otheruser" and otheruser is an account on the
> current host.
This is semantically the wrong way to think about -f, but works (by
design) on a properly configured host where local users correspond to
email addresses whose domain matches $myorigin.
> I didn't think this was uncommon. In my use case I
> have a PHP script that runs as "www-data" and I want the header to
> specify a different user on the same host that can actually receive
> email replies. I have been running this script for the last 11 years
> using the original sendmail and it has worked without issue. Recently
> I switched over to postfix and my script broke.
> The postfix implementation violates the principle of least surprise
This is because you had a mistaken idea of what -f really specified.
Once you understand that -f specifies an email address (any, possibly
non-local, email address), not a local user name, and not even the
"From:" address (directly), then the behavior should become
unsurprising.
I am reasonably sure that the reason sendmail has the -f option is
because the message text (including headers) read from stdin does not
have any way to specify an envelope sender that is different from the
"From:" header. You are generally expected to include the basic headers
in the message read from stdin. If you do that, the envelope sender is
taken from the "From:" header, not the other way around.
-f does not specify "I'm sending this message as a different local
user", it specifies "bounce messages should go to this email address".
It doesn't even specify "reply to me at this email address".
> and it breaks compatibility with the original sendmail
> implementation.
I can't speak to this. I'm sure I never relied on the behavior you are
expecting when I did use the original sendmail (which is so far back in
ancient history as to be vague in my memory), but my uses of sendmail
back then were much simpler. I'll take your word on this point.
> I doubt this was a conscious decision by the postfix
> developers. More likely this was merely overlooked and should be
> fixed.
Wietse has already said that this would be a breaking change. Whether
he wants to spend the time and add the complexity to do what he outlined
with a compatibility option is up to him. Personally, I don't think it
is worth either the effort or the code complexity or the documentation
complexity for such a corner case where there is a simple fix on the
caller's side. This seems to be a new complaint that Wietse had not
heard before, in the 25 years that postfix has been around.
If Wietse does decide to implement this, he will have to decide (and
document) how to handle the cases where (a) -f specifies just the user
portion but that user does not have a pwent, (b) -f specifies a fully
qualified email address where the domain matches $myorigin and (b.1) the
user has a pwent or (b.2) doesn't have a pwent, and (c) -f specifies a
fully qualified email where the domain doesn't match $myorigin.
Quite honestly, if I were in Wietse's shoes, I would probably write a
getpwgecos command (trivial), include it with postfix, and document for
sendmail that if you want the original sendmail behavior, use «sendmail
-f user -F $(getpwgecos user) ...». That would completely obviate the
necessity for the user to write a 15-line script to do it.
But again, it is Wietse's decision whether this is important enough to
spend his time implementing the compatibility option.
...Marvin
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
