Re: Best way to not allow locally submitted email
On Sun, Aug 14, 2011 at 07:23:18PM +0200, Jeroen Geilman wrote: > On 2011-08-14 18:35, Steve Fatula wrote: > >>From: Jeroen Geilman > >>You're stating contradictory requirements - you cannot AND allow > >>scripts to use sendmail to submit mail for user X, AND disallow > >>user X to submit mail as user X. > >> > >>Just put your script users in authorized_submit_users, and > >>enforce SMTP for everyone else. > >> > >The sendmail binary allows a user to do too many things they > >should not be allowed to. I can send mail FROM you for example. > >The restrictions on sender address that apply to authenticated > >email does not apply, of course, since they are not authenticated! > >So, perhaps the best solution is to use something like msmtp so > >that mail from the command line goes through normal authenticated > >channels, and thus, I CAN achieve my goals. > > Nobody says you cannot achieve your goals. I will. :) I really cannot think of a secure way to distinguish between cron-generated mail and other uses of sendmail(1). Steve could try things like wrapper scripts which might look at parent processes and such, but then, what is to stop an abuser from generating mail abuse via a cron job? This comes down to a "have your cake and eat it, too" problem. > I merely pointed out that you were asking contradicting things > of sendmail(1). > > Now, I would look for a way to force everybody that is not > administrator-controlled to use authenticated SMTP even from > localhost, and disallow sendmail for normal users. > How is that different from what you said ? I would first suggest that this sounds like a political or social problem, or potential problem perhaps. Don't give shell access to users you cannot trust. Make policies known, and revoke access if abuse occurs. On further thought however, I had an idea which might achieve the original goal: multiple instances, where the sendmail submission instance is unable to route outside spcified domains, with a "default_transport=error:No external mail" setting. Permitted destinations could be defined via transport_maps or address class definitions. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Best way to not allow locally submitted email
On 2011-08-14 18:35, Steve Fatula wrote: - Original Message - From: Jeroen Geilman To: postfix-users@postfix.org Cc: Sent: Sunday, August 14, 2011 5:14 AM Subject: Re: Best way to not allow locally submitted email You're stating contradictory requirements - you cannot AND allow scripts to use sendmail to submit mail for user X, AND disallow user X to submit mail as user X. Just put your script users in authorized_submit_users, and enforce SMTP for everyone else. The sendmail binary allows a user to do too many things they should not be allowed to. I can send mail FROM you for example. The restrictions on sender address that apply to authenticated email does not apply, of course, since they are not authenticated! So, perhaps the best solution is to use something like msmtp so that mail from the command line goes through normal authenticated channels, and thus, I CAN achieve my goals. Nobody says you cannot achieve your goals. I merely pointed out that you were asking contradicting things of sendmail(1). Now, I would look for a way to force everybody that is not administrator-controlled to use authenticated SMTP even from localhost, and disallow sendmail for normal users. How is that different from what you said ? -- J.
Re: Best way to not allow locally submitted email
- Original Message - > From: Jeroen Geilman > To: postfix-users@postfix.org > Cc: > Sent: Sunday, August 14, 2011 5:14 AM > Subject: Re: Best way to not allow locally submitted email > > > You're stating contradictory requirements - you cannot AND allow scripts to > use sendmail to submit mail for user X, AND disallow user X to submit mail as > user X. > > Just put your script users in authorized_submit_users, and enforce SMTP for > everyone else. > The sendmail binary allows a user to do too many things they should not be allowed to. I can send mail FROM you for example. The restrictions on sender address that apply to authenticated email does not apply, of course, since they are not authenticated! So, perhaps the best solution is to use something like msmtp so that mail from the command line goes through normal authenticated channels, and thus, I CAN achieve my goals.
Re: Best way to not allow locally submitted email
On 2011-08-14 09:41, Steve Fatula wrote: What is the best way to disable locally submitted email (via sendmail binary, mail, etc.), BUT, still allow cron and such tools to work and be able to send local mail? Not for the same users. You can't set authorized_submit_users, as, that means cron jobs run as users won't send the mail as they don't have permission. Only if you're talking about the SAME users. This would primarily be from command line users, or, web scripts and php programs that run as the user (not www, etc., this is suexec). For web scripts, they would need to send mail via smtp, which is easy enough. So, the idea here is to force that to happen and not allow mail, sendmail, etc. to users. You're stating contradictory requirements - you cannot AND allow scripts to use sendmail to submit mail for user X, AND disallow user X to submit mail as user X. Just put your script users in authorized_submit_users, and enforce SMTP for everyone else. -- J.
Best way to not allow locally submitted email
What is the best way to disable locally submitted email (via sendmail binary, mail, etc.), BUT, still allow cron and such tools to work and be able to send local mail? You can't set authorized_submit_users, as, that means cron jobs run as users won't send the mail as they don't have permission. This would primarily be from command line users, or, web scripts and php programs that run as the user (not www, etc., this is suexec). For web scripts, they would need to send mail via smtp, which is easy enough. So, the idea here is to force that to happen and not allow mail, sendmail, etc. to users. Steve
