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<jer...@adaptr.nl>
> >>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
