Root privileges

[varad gupta]

Hi

A colleague asked me a question to which I had not given much thought before.

We all know that most postfix daemons/services run as unpriviliged
users (apart from local and virtual) but the master daemon runs with
root privileges?

Is it not a risk running master as root (the same reason for running
other processes as unprivileged) ?

output of ps and lsof commands on my system are attached below :

[root@vbg postfix]# ps -ef | grep master
root  2237 1  0 16:29 ?00:00:00 /usr/libexec/postfix/master

[root@vbg postfix]# lsof -i tcp:25
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
master  2237 root   12u  IPv4  15503  0t0  TCP
localhost.localdomain:smtp (LISTEN)


Thanx in anticipation,


Regards

Varad Gupta

Re: Root privileges

[Ralf Hildebrandt]

* varad gupta :
> Hi
> 
> A colleague asked me a question to which I had not given much thought before.

That happens from time to time :)
 
> We all know that most postfix daemons/services run as unpriviliged
> users (apart from local and virtual) but the master daemon runs with
> root privileges?

Yes.
 
> Is it not a risk running master as root (the same reason for running
> other processes as unprivileged) ?

It must bind to ports < 1024 AND it must be able to spawn processes as
other, unprivileged users.

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de

Re: Looking for a maillist manager

[Mark Alan]

On Sun, 30 Jan 2011 07:19:48 +0200, Jaques Cochet
 wrote:

> I'm currently using qmail with ezmlm maillist manager. I intent to
> move to postfix, and i'm looking for a mail list manager that stores
> maillists subscribers in mysql databse, includes posting permissions,
> and can handle several hundreds of mail lists. Any suggestions?

 In terms of mail listing, postfix + mlmmj (http://mlmmj.org/) is roughly
equivalent to qmail + ezmlm.

But it will do its stuff using only plain text files just like ezmlm.
I.e., 'touched' files to signal options, email addresses or header and
footer customization inside plain files.
On the other hand, just like ezmlm, there will be no deamons runing and
no security problems associated with .cgi web interfaces and most of
the admin stuff will be done by simple email messages sent by the
owners, admins, moderators, etc.


M.

Re: Text Substitution with pcre:

[Wietse Venema]

Jerrale G:
> -- Well it seems if we cant UNDERSTAND the man pages completely that we 
> shouldnt expect clarification. PCRE is NOT perl even though it uses 
> perl; therefore, we cannot use it and require your man pages to do so. 

Pcre does not use Perl code.

> Since your man pages give NO examples for string manipulation, we are 
> here. And now we seem be subject to being scrutinized.

The pcre_table manpage has the following examples:

EXAMPLE SMTPD ACCESS MAP
EXAMPLE HEADER FILTER MAP
EXAMPLE BODY FILTER MAP

The header_checks manpage has the following examples:

Header pattern to block attachments with bad file name extensions
Body pattern to stop a specific HTML browser vulnerability exploit.

You want to replace headers with pcre maps, so I would expect that
these manpages are among the first that you would read.

Wietse

Re: Root privileges

[Wietse Venema]

varad gupta:
> Hi
> 
> A colleague asked me a question to which I had not given much thought before.
> 
> We all know that most postfix daemons/services run as unpriviliged
> users (apart from local and virtual) but the master daemon runs with
> root privileges?
> 
> Is it not a risk running master as root (the same reason for running
> other processes as unprivileged) ?
> 
> output of ps and lsof commands on my system are attached below :
> 
> [root@vbg postfix]# ps -ef | grep master
> root  2237 1  0 16:29 ?00:00:00 /usr/libexec/postfix/master
> 
> [root@vbg postfix]# lsof -i tcp:25
> COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
> master  2237 root   12u  IPv4  15503  0t0  TCP
> localhost.localdomain:smtp (LISTEN)

All Postfix daemons are created as a root-privileged process.  Root
privilege is needed during process initialization, to drop privileges,
while shutting down Postfix, to impersonate a recipient, or to
invoke a non-Postfix program without giving it postfix privileges.
Examples of such system calls are: bind, chroot, set(e)uid,
set(e)gid, (f)chown, kill.

Wietse

Re: Looking for a maillist manager

[Miles Fidelman]

On Sun, 30 Jan 2011 07:19:48 +0200, Jaques Cochet

  wrote:
   

I'm currently using qmail with ezmlm maillist manager. I intent to
move to postfix, and i'm looking for a mail list manager that stores
maillists subscribers in mysql databse, includes posting permissions,
and can handle several hundreds of mail lists. Any suggestions?
 
The best one I've found is sympa (www.sympa.org) - open source, 
web-based management interface, bounce management, integrated archiving, 
developed and supported by a French research consortium - used by a lot 
of universities and other folks who need to handle lots of lists.  
Nothing else comes close.  Only downside is that you have to navigate a 
bunch of web screens to set all the various features, though you can set 
up defaults and templates and such to simplify things.


It's a little tricky to set up, but once it's running, it's pretty 
powerful.  For what it's worth, at least for the Debian version, I've 
always found it easier to install from the tarball, rather than the 
packaged version.


Miles Fidelman

--
In theory, there is no difference between theory and practice.
In  practice, there is.    Yogi Berra

Re: Looking for a maillist manager

[Pascal Maes]

On Sun, 30 Jan 2011 07:19:48 +0200, Jaques Cochet
 wrote:

> I'm currently using qmail with ezmlm maillist manager. I intent to
> move to postfix, and i'm looking for a mail list manager that stores
> maillists subscribers in mysql databse, includes posting permissions,
> and can handle several hundreds of mail lists. Any suggestions?



We are using SYMPA with several thousands of mails lists




-- 
Pascal

Postfix and Postgrey Not Really Communicating

[jason hirsh]

OK after some work I have postgrey running but it doesn't appear to be  
doing "mail stuff" with postfix


I am running postfix 2.8  clamav amavid-new dovecot


my rc.conf

postgrey_enable="YES"
postgrey_pidfile="/var/run/postgrey.pid"
postgrey_flags="--pidfile=${postgrey_pidfile} --inet=127.0.0.1:6000 -d  
--user=postgrey --group=postgrey --dbdir=/var/db/postgrey --auto- 
whitelist-clients=10 --delay=60 --max-age=20"


postconf -n

body_checks = regexp:/usr/local/etc/postfix/body_check
command_directory = /usr/local/sbin
config_directory = /usr/local/etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/local/libexec/postfix
daemon_timeout = 36000s
data_directory = /var/db/postfix
delay_warning_time = 2h
disable_vrfy_command = yes
header_checks = regexp:/usr/local/etc/postfix/header_checks
home_mailbox = Maildir/
html_directory = /usr/local/share/doc/postfix
mail_owner = postfix
mail_spool_directory = /var/mail/vmail
mailq_path = /usr/local/bin/mailq
manpage_directory = /usr/local/man
maps_rbl_domains = bl.spamcop.net
message_size_limit = 1024
mydestination = localhost.$mydomain, localhost
mydomain = theoceanwindow-bv.com
mynetworks = 127.0.0.0/32, 209.160.65.133, 209.160.68.112
newaliases_path = /usr/local/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = /usr/local/share/doc/postfix
receive_override_options = no_address_mappings
relay_recipient_maps = hash:/usr/local/etc/postfix/relay_recipients
sample_directory = /usr/local/etc/postfix
sendmail_path = /usr/local/sbin/sendmail
setgid_group = maildrop
smtp_tls_note_starttls_offer = yes
smtpd_banner = tuna.theoceanwindow-bv.com
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_sasl_authenticated,check_helo_access  
hash:/usr/local/etc/postfix/helo_access,reject_invalid_hostname,permit
smtpd_recipient_restrictions = permit  
mynetworks 
,permit_sasl_authenticated,reject_unauth_destination,reject_rbl_client  
zen.spamhaus.org,reject_rbl_client bl.spam,check_policy_service inet: 
127.0.0.1:6000

smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $myhostnamebroken_sasl_auth_clients = yes
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_sender_restrictions = permit_sasl_authenticated
smtpd_tls_CAfile = /usr/local/etc/keys/root.crt
smtpd_tls_cert_file = /usr/local/etc/keys/server.cert
smtpd_tls_key_file = /usr/local/etc/keys/private.key
smtpd_tls_loglevel = 3
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
tls_random_source = dev:/dev/urandom
unknown_local_recipient_reject_code = 550
virtual_alias_maps = hash:/usr/local/etc/postfix/virtual
virtual_gid_maps = static:1000
virtual_mailbox_base = /var/mail/vmail
virtual_mailbox_domains = /usr/local/etc/postfix/virtual_domains
virtual_mailbox_maps = hash:/usr/local/etc/postfix/virtual_mailbox
virtual_minimum_uid = 100
virtual_uid_maps = static:1003

ps aux | grep postgrey  shows

postgrey  1258  0.0  1.0 12196  9952  ??  Is   11:10AM   0:00.03 /usr/ 
local/sbin/postgrey --pidfile=/var/run/postgrey.pid -- 
inet=127.0.0.1:6000 -d --user=postgrey --group=postgrey --dbdir=/var/ 
db/postgrey --auto-whitelist-clients=10 --delay=60 --max-age=20  
(perl5.10.1)



he only reference in mail.log of postgrey is at start

Jan 30 11:10:48 tuna postgrey[1258]: Process Backgrounded
Jan 30 11:10:48 tuna postgrey[1258]: 2011/01/30-11:10:48 postgrey  
(type Net::Server::Multiplex) starting! pid(1258)

Jan 30 11:10:48 tuna postgrey[1258]: Using default listen value of 128
Jan 30 11:10:48 tuna postgrey[1258]: Binding to TCP port 6000 on host  
127.0.0.1

Jan 30 11:10:48 tuna postgrey[1258]: Setting gid to "225 225"
Jan 30 11:10:48 tuna postgrey[1258]: Setting uid to "225"


So it would  would appear postgrey is now running but postfix is not  
using it


any thoughts or help??

Re: Postfix and Postgrey Not Really Communicating

[Wietse Venema]

jason hirsh:
> smtpd_recipient_restrictions = permit  

Right, all mail passes because you have "permit" first.

Wietse

Solved: Postfix and Postgrey Not Really Communicating

[jason hirsh]

my mistake i was cutting and paste from some some advise and copies  
the typo


spaces are bad in postfix

now to see if postgre wil actually learn this time  so far no

Begin forwarded message:


From: Wietse Venema 
Date: January 30, 2011 12:41:56 PM AST
To: jason hirsh 
Cc: postfix-users@postfix.org
Subject: Re: Postfix and Postgrey  Not Really Communicating

jason hirsh:

smtpd_recipient_restrictions = permit


Right, all mail passes because you have "permit" first.

Wietse

Re: Solved: Postfix and Postgrey Not Really Communicating

[Wietse Venema]

jason hirsh:
> my mistake i was cutting and paste from some some advise and copies  
> the typo
> 
> spaces are bad in postfix
> 
> now to see if postgre wil actually learn this time  so far no

As configured, postgrey is not used for clients in "mynetworks"
or for clients that use SASL authentication.

For some background on how smtpd_recipient_restrictions works, see:

http://www.postfix.org/SMTPD_ACCESS_README.html


Wietse

Re: Root privileges

[Victor Duchovni]

On Sun, Jan 30, 2011 at 05:22:39PM +0530, varad gupta wrote:

> Is it not a risk running master as root (the same reason for running
> other processes as unprivileged) ?

No, quite the opposite. It takes privileges to "drop" privileges.  A well
designed system (such as Postfix) is *more* secure by in part using root
privileges to enable it to operate in multiple security contexts.

My short maxim for this is indebted to a marketing campaign:

http://en.wikipedia.org/wiki/Frank_Perdue

"it takes a tough man to make a tender chicken"

By which I mean that you sometimes need higher privileges to optimally
use lower privileges.

-- 
Viktor.

restricting outbound e-mail to be from the authenticated user only

[Daniel Bromberg]

Hi,

I've recently started using postfix several weeks ago to run my e-mail 
services. Using spamassassin/spamd, greylists/SQLgrey, several RBLs, 
multiple domains, virtual users against MySQL tables in multiple 
domains, so somewhat knowledgeable, but mostly not.


One of the companies I administrate has a policy that users submitting 
outgoing mail via submission/SSL/465 can only use the server to submit 
'MAIL FROM:' their SASL authenticated username, so they cannot do 
non-company business as a different e-mail identity through the server.


This is turning out to be harder than I thought however.

A. IIUC, check_sender_access applies to all mail received, whether 
intended for local delivery via smtp/unencrypted/25 or intended for 
outbound relaying via submission/SSL/465.


B. writing a content filter to be appended to the submission line in 
master.cf (say a perl script) that scans the e-mail for the 'From:' 
line, then does a MySQL query against my virtual table, (then exits with 
some kind of code indicating the mail should be rejected??), seems an 
awful lot of work relative to the simple goal. Also how would the perl 
script know the SASL authenticated ID? Maybe an environment variable 
gets created?


C. Starting a second instance of postfix so that I can have a distinct 
check_sender_access ruleset just for submission/465 mail seems highly 
wasteful of resources. Plus, as a 2-month-old Postfix admin, I feel like 
the complexity and chance of getting something very wrong is just very 
high, what with ensuring I have separate directories for all the right 
things.


Someone set me straight?

Thanks,
-Daniel

Selective Relaying

[Dominik Schulz]

Hi,

I'm currently planning to migrate an Exim mailserver to Postfix due to 
performance issues and security concerns.

The only remaining open issue is something I'd like to call selective relaying 
- please provide a more apt name if there is one.

The Exim mailserver is configured to handle several virtual domains. If a 
recipient is not found in the virtual table, before rejecting this recipient, 
exim checks an MS Exchange mailserver via SMTP if the it would accept this 
recipient. If it does the mail is accepted and relayed to the Exchange server. 
If it does not the mail is rejected.

My question is: How can configure postfix to allow the same kind of selective 
relaying?

At the moment I don't think that I could use relay maps, because the as far as 
I understood it, they work with a static list of recipients. Futhermore I 
don't have LDAP access to the Exchange server - only SMTP.

I welcome simple or complex solutions as long as they come as close as 
possible to the existing setup. However I can't use internal Domains which are 
rewritten to the outside.

-- 
Mit freundlichen Grüßen / Best Regards
Dominik


signature.asc
Description: This is a digitally signed message part.

Re: Selective Relaying

[Noel Jones]

On 1/30/2011 3:57 PM, Dominik Schulz wrote:

Hi,

I'm currently planning to migrate an Exim mailserver to Postfix due to
performance issues and security concerns.

The only remaining open issue is something I'd like to call selective relaying
- please provide a more apt name if there is one.

The Exim mailserver is configured to handle several virtual domains. If a
recipient is not found in the virtual table, before rejecting this recipient,
exim checks an MS Exchange mailserver via SMTP if the it would accept this
recipient. If it does the mail is accepted and relayed to the Exchange server.
If it does not the mail is rejected.

My question is: How can configure postfix to allow the same kind of selective
relaying?

At the moment I don't think that I could use relay maps, because the as far as
I understood it, they work with a static list of recipients. Futhermore I
don't have LDAP access to the Exchange server - only SMTP.

I welcome simple or complex solutions as long as they come as close as
possible to the existing setup. However I can't use internal Domains which are
rewritten to the outside.





Maybe this helps?
http://www.postfix.org/ADDRESS_VERIFICATION_README.html#recipient

IIRC the examples in that document show verifying recipients 
for all accepted domains.  It's also possible to verify 
recipients for a single target domain by using a 
check_recipient_access map.



  -- Noel Jones

Re: Selective Relaying

[Wietse Venema]

Dominik Schulz:
> Hi,
> 
> I'm currently planning to migrate an Exim mailserver to Postfix due to 
> performance issues and security concerns.
> 
> The only remaining open issue is something I'd like to call selective relaying
> - please provide a more apt name if there is one.

I can try, if you can describe what it is supposed to do.

> The Exim mailserver is configured to handle several virtual domains. If a 
> recipient is not found in the virtual table, before rejecting this recipient, 
> exim checks an MS Exchange mailserver via SMTP if the it would accept this 
> recipient. If it does the mail is accepted and relayed to the Exchange server.
> If it does not the mail is rejected.

Postfix uses a deterministic routing model, where mail for domain
X is routed via a fixed path. 

You can make per-user overrides with virtual_alias_maps or
transport_maps, and use reject_unverified_recipient to find out if
a recipient address accepts mail. But this gets messy and results
either in rejecting mail (user unknown) or accepting too much,
causing you to become a backscatter source.

The following is the simplest example that uses virtual_alias_maps
to deflect unknown users to the MS Exchange mailserver, and that
uses reject_unverified_recipient to find out if those users exist.
Postfix 2.7 and later automatically cache the reject_unverified_recipient
result.

/etc/postfix/main.cf:
virtual_alias_domains = a.example
virtual_alias_maps = hash:/etc/postfix/virtual_alias
smtpd_recipient_restrictions = 
reject_unauth_destination reject_unverified_recipient

/etc/postfix/virtual_alias:
user1@a.example user1@localhost
user2@a.example user2@localhost
@a.example  @ms-exchange-mailserver

It is also possible to marry this to virtual_mailbox_domains,
but you didn't say that you were using those.

Wietse

Re: restricting outbound e-mail to be from the authenticated user only

[Noel Jones]

On 1/30/2011 3:31 PM, Daniel Bromberg wrote:

Hi,

I've recently started using postfix several weeks ago to run
my e-mail services. Using spamassassin/spamd,
greylists/SQLgrey, several RBLs, multiple domains, virtual
users against MySQL tables in multiple domains, so somewhat
knowledgeable, but mostly not.

One of the companies I administrate has a policy that users
submitting outgoing mail via submission/SSL/465 can only use
the server to submit 'MAIL FROM:' their SASL authenticated
username, so they cannot do non-company business as a
different e-mail identity through the server.

This is turning out to be harder than I thought however.

A. IIUC, check_sender_access applies to all mail received,
whether intended for local delivery via smtp/unencrypted/25 or
intended for outbound relaying via submission/SSL/465.


No, you can override most main.cf settings, including all the 
smtpd_*_restrictions, with -o options on the submission/smtps 
entries in master.cf.  See:

http://www.postfix.org/postconf.5.html

A simple check would be adding a regexp check_sender_access 
map that rejects any address that doesn't contain 
@example.com.  A more sophisticated check would insure that 
the SASL credentials match the MAIL FROM, using 
reject_sender_login_mismatch.
Also note that postfix operates on the MAIL FROM envelope 
address, not the address given in the From: header.


Note that too many overrides can make postfix somewhat 
confusing due to the config being in several places.  At some 
point it's easier and cleaner to run multiple instances. 
Multiple postfix instances is substantially easier with 
postfix versions 2.6 and newer.

http://www.postfix.org/MULTI_INSTANCE_README.html


  -- Noel Jones

Re: limit/tune the smtp sender dameon for specific destination domains

[Steve Jenkins]

On Sat, Jan 29, 2011 at 1:23 PM, mouss  wrote:
> Le 29/01/2011 22:19, David Touzeau a écrit :
>> Dear
>>
>> I would like to tune postfix smtp sender according specific destination
>> domains eg number of connexions, number of email per seconds, queue life
>> time
>>
>> Is there any documentation on this needs or how can i define settings in
>> order to achieve this task ?
>>
>
> clone the smtp transport in master.cf. for example:
>
> slowsmtp      unix  -       -       n       -       -       smtp
>
> foosmtp      unix  -       -       n       -       -       smtp
>
> barsmtp      unix  -       -       n       -       -       smtp
>
>
> then you can use
>
> foosmtp_some_variable = some_value

Ok - I read "man 5 master" to try and figure this out, but it still
didn't make sense.

So for example, let's say I wanted to limit outgoing mail to yahoo.com
to 10 simultaneous connections and 20 emails per second. In master.cf
I'm presuming I put:

yahoosmtp      unix  -       -       n       -       -       smtp

But then I didn't understand the "some_variable = some_value" part of
the solution. I'm assuming that part goes in main.cf, but beyond that
I'm stumped on how my "10" and "20" values get declared and
interpreted properly.

Thanks,

SteveJ

Re: limit/tune the smtp sender dameon for specific destination domains

[Wietse Venema]

Steve Jenkins:
> So for example, let's say I wanted to limit outgoing mail to yahoo.com
> to 10 simultaneous connections and 20 emails per second. In master.cf
> I'm presuming I put:
> 
> yahoosmtp ? ? ?unix ?- ? ? ? - ? ? ? n ? ? ? - ? ? ? - ? ? ? smtp

To limit the concurrency to 10:

/etc/postfix/main.cf:
yahoosmtp_destination_concurrency_limit = 10
transport_maps = hash:/etc/postfix/transport

/etc/postfix/transport:
yahoo.com   yahoosmtp:

Details:
http://www.postfix.org/postconf.5.html#transport_destination_concurrency_limit
http://www.postfix.org/postconf.5.html#transport_maps

To limit the sending rate:

/etc/postfix/main.cf:
yahoosmtp_rate_delay = 1
transport_maps = hash:/etc/postfix/transport

/etc/postfix/transport:
yahoo.com   yahoosmtp:

The ..._destination_rate_delay feature always sends one message at
a time, and it does not support delays smaller than 1s. It is
primarily meant for home users and their ISP's usage policies.

Details:
http://www.postfix.org/postconf.5.html#transport_destination_rate_delay
http://www.postfix.org/postconf.5.html#transport_maps
http://www.postfix.org/postconf.5.html#transport_destination_recipient_limit

Wietse

Re: limit/tune the smtp sender dameon for specific destination domains

[mouss]

Le 31/01/2011 00:09, Steve Jenkins a écrit :
> On Sat, Jan 29, 2011 at 1:23 PM, mouss  wrote:
>> Le 29/01/2011 22:19, David Touzeau a écrit :
>>> Dear
>>>
>>> I would like to tune postfix smtp sender according specific destination
>>> domains eg number of connexions, number of email per seconds, queue life
>>> time
>>>
>>> Is there any documentation on this needs or how can i define settings in
>>> order to achieve this task ?
>>>
>>
>> clone the smtp transport in master.cf. for example:
>>
>> slowsmtp  unix  -   -   n   -   -   smtp
>>
>> foosmtp  unix  -   -   n   -   -   smtp
>>
>> barsmtp  unix  -   -   n   -   -   smtp
>>
>>
>> then you can use
>>
>> foosmtp_some_variable = some_value
> 
> Ok - I read "man 5 master" to try and figure this out, but it still
> didn't make sense.

read for example:
http://www.postfix.org/postconf.5.html#default_destination_concurrency_limit

and look at the line that says: Use transport_...  if you look enough,
you'll notice that "transport" is in italics.

now you can read the postconf.5.html and look for all
default_destination_* variables.

so maybe some examples are easier to read?

foosmtp_destination_concurrency_limit = 10
foosmtp_destination_rate_delay = 1
foosmtp_destination_concurrency_failed_cohort_limit = 10

http://www.postfix.org/postconf.5.html#transport_destination_concurrency_failed_cohort_limit
http://www.postfix.org/postconf.5.html#transport_destination_rate_delay
http://www.postfix.org/postconf.5.html#default_destination_concurrency_limit

> 
> So for example, let's say I wanted to limit outgoing mail to yahoo.com
> to 10 simultaneous connections and 20 emails per second. In master.cf
> I'm presuming I put:
> 
> yahoosmtp  unix  -   -   n   -   -   smtp
> 
> But then I didn't understand the "some_variable = some_value" part of
> the solution. I'm assuming that part goes in main.cf, but beyond that
> I'm stumped on how my "10" and "20" values get declared and
> interpreted properly.
> 


see above, as well as
http://tech.groups.yahoo.com/group/postfix-users/message/234969




> Thanks,
> 
> SteveJ

Re: restricting outbound e-mail to be from the authenticated user only

[mouss]

Le 30/01/2011 22:31, Daniel Bromberg a écrit :
> Hi,
> 
> I've recently started using postfix several weeks ago to run my e-mail
> services. Using spamassassin/spamd, greylists/SQLgrey, several RBLs,
> multiple domains, virtual users against MySQL tables in multiple
> domains, so somewhat knowledgeable, but mostly not.
> 
> One of the companies I administrate has a policy that users submitting
> outgoing mail via submission/SSL/465 can only use the server to submit
> 'MAIL FROM:' their SASL authenticated username, so they cannot do
> non-company business as a different e-mail identity through the server.
> 
> This is turning out to be harder than I thought however.
> 
> A. IIUC, check_sender_access applies to all mail received, whether
> intended for local delivery via smtp/unencrypted/25 or intended for
> outbound relaying via submission/SSL/465.
> 

In addition to Noel's answer, maybe you can also use something like this:


smtpd_sender_restrictions =
check_sender_access hash:/etc/postfix/our_sender
reject_unauth_destination

== our_sender:
example.com OK
.example.comOK


with this, no relay is allowed for addresses not of the form
*@example.com or *@*.example.com. so your users can use an external
address but only if sending to domains that your postfix delivers or
relays mail to.

if this is not enough, ovberride smtpd restrictions in master.cf:

smtps ...
-o smtpd_sender_restrictions=${smtps_sender_restrictions}

and in main.cf, define
smtps_sender_restrictions =
check_sender_access hash:/etc/postfix/our_sender
reject


As Noel said, this only controls the envelope sender, not headers if you
want to also check the headers, you need to define a specific cleanup
service, say cleanout, set it as the cleanup service for smtps, and
configure it to use a specific header_checks map which would have
something like

if /^From:/
/@example\.com($|\b)/   dunno
/./ reject blah blah
endif

of course, users can trick this. for example:
From: "joe (@example.com!again)" 



> B. writing a content filter to be appended to the submission line in
> master.cf (say a perl script) that scans the e-mail for the 'From:'
> line, then does a MySQL query against my virtual table, (then exits with
> some kind of code indicating the mail should be rejected??), seems an
> awful lot of work relative to the simple goal. Also how would the perl
> script know the SASL authenticated ID? Maybe an environment variable
> gets created?
> 
> C. Starting a second instance of postfix so that I can have a distinct
> check_sender_access ruleset just for submission/465 mail seems highly
> wasteful of resources. Plus, as a 2-month-old Postfix admin, I feel like
> the complexity and chance of getting something very wrong is just very
> high, what with ensuring I have separate directories for all the right
> things.
> 
> Someone set me straight?
> 
> Thanks,
> -Daniel
> 

Re: restricting outbound e-mail to be from the authenticated user only

[Daniel Bromberg]

Brilliant, reject_sender_login_mismatch is the perfect level of 
flexibility and is working now.  I can add whatever authorizations I 
need to my virtual user table in the DB, in a separate column if need 
be. (right now I'm using the trivial match of  = login name>)


Importantly, if it's not a SASL-based session no such authorization 
check is done, rather the usual "you're a stranger, for local delivery 
only" rules apply there. So, I don't need to have a separate ruleset, as 
this rule already has the proper granularity.


Conceivably, someone could hack a non-standard e-mail client to use the 
SASL name in the MAIL FROM, but tweak the 'From: ' line to anything they 
like (although the MAIL FROM would appear in the Return-Path / Sender 
fields), and this is harder to stop, correct? But we are in rare corner 
cases now, not ordinary users I would think.


Anyway, thanks for the quick follow-up, resolved.

Daniel



On 1/30/2011 5:58 PM, Noel Jones wrote:

On 1/30/2011 3:31 PM, Daniel Bromberg wrote:

Hi,

I've recently started using postfix several weeks ago to run
my e-mail services. Using spamassassin/spamd,
greylists/SQLgrey, several RBLs, multiple domains, virtual
users against MySQL tables in multiple domains, so somewhat
knowledgeable, but mostly not.

One of the companies I administrate has a policy that users
submitting outgoing mail via submission/SSL/465 can only use
the server to submit 'MAIL FROM:' their SASL authenticated
username, so they cannot do non-company business as a
different e-mail identity through the server.

This is turning out to be harder than I thought however.

A. IIUC, check_sender_access applies to all mail received,
whether intended for local delivery via smtp/unencrypted/25 or
intended for outbound relaying via submission/SSL/465.


No, you can override most main.cf settings, including all the 
smtpd_*_restrictions, with -o options on the submission/smtps entries 
in master.cf.  See:

http://www.postfix.org/postconf.5.html

A simple check would be adding a regexp check_sender_access map that 
rejects any address that doesn't contain @example.com.  A more 
sophisticated check would insure that the SASL credentials match the 
MAIL FROM, using reject_sender_login_mismatch.
Also note that postfix operates on the MAIL FROM envelope address, not 
the address given in the From: header.


Note that too many overrides can make postfix somewhat confusing due 
to the config being in several places.  At some point it's easier and 
cleaner to run multiple instances. Multiple postfix instances is 
substantially easier with postfix versions 2.6 and newer.

http://www.postfix.org/MULTI_INSTANCE_README.html


  -- Noel Jones

Re: restricting outbound e-mail to be from the authenticated user only

[Bernhard Rohrer]

Port 587 has been invented for this very purpose ;)

On 30/01/11 21:31, Daniel Bromberg wrote:

Hi,

I've recently started using postfix several weeks ago to run my e-mail 
services. Using spamassassin/spamd, greylists/SQLgrey, several RBLs, 
multiple domains, virtual users against MySQL tables in multiple 
domains, so somewhat knowledgeable, but mostly not.


One of the companies I administrate has a policy that users submitting 
outgoing mail via submission/SSL/465 can only use the server to submit 
'MAIL FROM:' their SASL authenticated username, so they cannot do 
non-company business as a different e-mail identity through the server.


This is turning out to be harder than I thought however.

A. IIUC, check_sender_access applies to all mail received, whether 
intended for local delivery via smtp/unencrypted/25 or intended for 
outbound relaying via submission/SSL/465.


B. writing a content filter to be appended to the submission line in 
master.cf (say a perl script) that scans the e-mail for the 'From:' 
line, then does a MySQL query against my virtual table, (then exits 
with some kind of code indicating the mail should be rejected??), 
seems an awful lot of work relative to the simple goal. Also how would 
the perl script know the SASL authenticated ID? Maybe an environment 
variable gets created?


C. Starting a second instance of postfix so that I can have a distinct 
check_sender_access ruleset just for submission/465 mail seems highly 
wasteful of resources. Plus, as a 2-month-old Postfix admin, I feel 
like the complexity and chance of getting something very wrong is just 
very high, what with ensuring I have separate directories for all the 
right things.


Someone set me straight?

Thanks,
-Daniel

Re: Root privileges

[varad gupta]

Thanx for all the replies - I now understand the reason for master
daemon to run with superuser privileges. They were really helpful.

But then, is postfix not running the same risk as "sendmail" ?

As a student, I was told that sendmail is a single monolithic binary,
performing all its functions as superuser; therefore if an attacker
could control the sendmail process, he/she would have superuser
access.

Does it mean, that unless run in a chroot environment, postfix is
susceptible to the same risks as sendmail and gives an attacker
capability of causing similar damage (despite having a far better
system of tasks divided amongst various unprivileged processes
designed to perform specific tasks) ?


Regards

On Sun, Jan 30, 2011 at 11:47 PM, Victor Duchovni
 wrote:
> On Sun, Jan 30, 2011 at 05:22:39PM +0530, varad gupta wrote:
>
>> Is it not a risk running master as root (the same reason for running
>> other processes as unprivileged) ?
>
> No, quite the opposite. It takes privileges to "drop" privileges.  A well
> designed system (such as Postfix) is *more* secure by in part using root
> privileges to enable it to operate in multiple security contexts.
>
> My short maxim for this is indebted to a marketing campaign:
>
>    http://en.wikipedia.org/wiki/Frank_Perdue
>
>    "it takes a tough man to make a tender chicken"
>
> By which I mean that you sometimes need higher privileges to optimally
> use lower privileges.
>
> --
>        Viktor.
>

Re: Selective Relaying

[Victor Duchovni]

On Sun, Jan 30, 2011 at 05:36:00PM -0500, Wietse Venema wrote:

> The following is the simplest example that uses virtual_alias_maps
> to deflect unknown users to the MS Exchange mailserver, and that
> uses reject_unverified_recipient to find out if those users exist.
> Postfix 2.7 and later automatically cache the reject_unverified_recipient
> result.
> 
> /etc/postfix/main.cf:
> virtual_alias_domains = a.example
> virtual_alias_maps = hash:/etc/postfix/virtual_alias
> smtpd_recipient_restrictions = 
>   reject_unauth_destination reject_unverified_recipient
> 
> /etc/postfix/virtual_alias:
> user1@a.example   user1@localhost
> user2@a.example   user2@localhost
> @a.example@ms-exchange-mailserver

The domain could be added to relay_domains, with relay_recipient_maps
set empty. An access table could have:

rcpt-access:
# Some known, verify the rest:
example.com reject_unverified_recipient
example.net reject_unverified_recipient

# All known, so default reject:
example.org REJECT 5.1.1 Recipient address unknown

# The list of known users
#
known-us...@example.com DUNNO
known-us...@example.net DUNNO
known-us...@example.org DUNNO
...

main.cf:
# Use access(5) instead of relay_recipient_maps:
relay_recipient_maps = 
relay_domains = example.com
smtpd_recipient_restrictions =
reject_unauth_destination,
check_recipient_access hash:/etc/postfix/rcpt-access

-- 
Viktor.

Re: Root privileges

[Victor Duchovni]

On Mon, Jan 31, 2011 at 08:02:28AM +0530, varad gupta wrote:

> Thanx for all the replies - I now understand the reason for master
> daemon to run with superuser privileges. They were really helpful.
> 
> But then, is postfix not running the same risk as "sendmail" ?

No.

> Does it mean, that unless run in a chroot environment, postfix is
> susceptible to the same risks as sendmail and gives an attacker
> capability of causing similar damage (despite having a far better
> system of tasks divided amongst various unprivileged processes
> designed to perform specific tasks) ?

No.

-- 
Viktor.

Re: Root privileges

[Daniel Bromberg]

Varad,

I may be talking out of turn as I am fairly new to Postfix, but I think 
we need to distinguish between a *practical* risk and a *theoretical* risk.


Theoretically, any software that runs as root, sufficiently attacked, 
could be used to compromise an entire system. The sufficient attack 
would simply be arbitrary native code injection (the worst and hardest 
kind of attack, but always a theoretical risk.)


However, that does not mean the root user, and by extension root-owned 
processes, is fundamentally toxic. By reducto ad absurdum, the root user 
shouldn't exist at all!


Practically speaking, what Postfix does much better than sendmail (among 
other things) is reduce the amount of *time* and *code* and *scope of 
operation* over which superuser privileges are used. This is 
accomplished with a modular design that quickly dispatches to lower 
privilege modes to actually do anything, like process untrusted input, 
write or delete a file, or send a message.


More experienced admins, please confirm with acknowledgements and/or 
refinements of this.


-Daniel

On 1/30/2011 9:32 PM, varad gupta wrote:

Thanx for all the replies - I now understand the reason for master
daemon to run with superuser privileges. They were really helpful.

But then, is postfix not running the same risk as "sendmail" ?

As a student, I was told that sendmail is a single monolithic binary,
performing all its functions as superuser; therefore if an attacker
could control the sendmail process, he/she would have superuser
access.

Does it mean, that unless run in a chroot environment, postfix is
susceptible to the same risks as sendmail and gives an attacker
capability of causing similar damage (despite having a far better
system of tasks divided amongst various unprivileged processes
designed to perform specific tasks) ?


Regards

On Sun, Jan 30, 2011 at 11:47 PM, Victor Duchovni
  wrote:

On Sun, Jan 30, 2011 at 05:22:39PM +0530, varad gupta wrote:


Is it not a risk running master as root (the same reason for running
other processes as unprivileged) ?

No, quite the opposite. It takes privileges to "drop" privileges.  A well
designed system (such as Postfix) is *more* secure by in part using root
privileges to enable it to operate in multiple security contexts.

My short maxim for this is indebted to a marketing campaign:

http://en.wikipedia.org/wiki/Frank_Perdue

"it takes a tough man to make a tender chicken"

By which I mean that you sometimes need higher privileges to optimally
use lower privileges.

--
Viktor.

Re: Root privileges

[Chris Tandiono]

On 30 Jan 2011, at 18:46 , Victor Duchovni wrote:

> On Mon, Jan 31, 2011 at 08:02:28AM +0530, varad gupta wrote:
> 
>> Thanx for all the replies - I now understand the reason for master
>> daemon to run with superuser privileges. They were really helpful.
>> 
>> But then, is postfix not running the same risk as "sendmail" ?
> 
> No.
> 
>> Does it mean, that unless run in a chroot environment, postfix is
>> susceptible to the same risks as sendmail and gives an attacker
>> capability of causing similar damage (despite having a far better
>> system of tasks divided amongst various unprivileged processes
>> designed to perform specific tasks) ?
> 
> No.
> 
> -- 
>   Viktor.

I don't know how accurate my interpretation is, but the way I see it, postfix's 
master process, if hacked, would obviously present a lot of problems. But since 
it does less, it's also less open to hacks. For example, an empty program that 
does nothing cannot be hacked or exploited in any way because there is nothing 
to exploit. By moving most of the functions out of the master process, even if 
the other processes have flaws, they aren't privileged.

Someone else can feel free to correct me.

Chris

Re: restricting outbound e-mail to be from the authenticated user only

[Noel Jones]

On 1/30/2011 6:17 PM, Daniel Bromberg wrote:

Conceivably, someone could hack a non-standard e-mail client
to use the SASL name in the MAIL FROM, but tweak the 'From: '
line to anything they like (although the MAIL FROM would
appear in the Return-Path / Sender fields), and this is harder
to stop, correct? But we are in rare corner cases now, not
ordinary users I would think.


I think alternate From: is a fairly standard feature, no 
hacking required.  Even easier for them to use Reply-To:, 
which is supported by pretty much every mail client and aided 
by the fact that when reading mail, some popular mail clients 
don't show the address of the sender, only the name.


As mouss already pointed out, you can use a header_checks rule 
on submission/smtps that rejects mail that doesn't have 'From: 
.*@example.com', but it's not iron-clad protection.
Also note that defining a separate header_checks for 
submission/smtps requires defining an alternate 
cleanup_service, or a separate postfix instance.  Examples can 
be found in the archives.




  -- Noel Jones

Re: Root privileges

[Michael J Wise]

On Jan 30, 2011, at 6:50 PM, Chris Tandiono wrote:

> On 30 Jan 2011, at 18:46 , Victor Duchovni wrote:
> 
>> On Mon, Jan 31, 2011 at 08:02:28AM +0530, varad gupta wrote:
>> 
>>> Thanx for all the replies - I now understand the reason for master
>>> daemon to run with superuser privileges. They were really helpful.
>>> 
>>> But then, is postfix not running the same risk as "sendmail" ?
>> 
>> No.

Short answers from Victor are a good sign that you've headed down the wrong 
track.  :)
There's a reason that Postfix was once known by another name.

>>> Does it mean, that unless run in a chroot environment, postfix is
>>> susceptible to the same risks as sendmail and gives an attacker
>>> capability of causing similar damage (despite having a far better
>>> system of tasks divided amongst various unprivileged processes
>>> designed to perform specific tasks) ?
>> 
>> No.

Here's the first hint, you're comparing Oranges with Orangutans.
You say that Sendmail is a monolithic process running as root, and Postfix' 
Master process is running as root, so they are thus open to the same sorts of 
problems.

You are grossly incorrect.

To put it in another way, what vulnerabilities is the Master process exposed 
to? It doesn't talk to the internet, it doesn't talk to the local user. Almost 
all the interactions it has with anything are done via processes running with 
less privilege.

> I don't know how accurate my interpretation is, but the way I see it, 
> postfix's master process, if hacked, would obviously present a lot of 
> problems. But since it does less, it's also less open to hacks. For example, 
> an empty program that does nothing cannot be hacked or exploited in any way 
> because there is nothing to exploit. By moving most of the functions out of 
> the master process, even if the other processes have flaws, they aren't 
> privileged.
> 
> Someone else can feel free to correct me.

Sounds about right.

Another point... is there any record AT ALL of Postfix ever being hacked?
Sendmail ... we don't have time to recount all the hacks, and quite frankly, I 
don't know where one would go to get a list, but I know that anything less than 
version 8.8.8 was considered un-secure by definition, and that was about when I 
stopped keeping track way back then. Have never heard anything about Postfix.

Aloha,
Michael.
-- 
"Please have your Internet License http://kapu.net/~mjwise/
 and Usenet Registration handy..."

Re: Root privileges

[Morten P.D. Stevens]

2011/1/31 varad gupta :
>
> But then, is postfix not running the same risk as "sendmail" ?

Sendmail is not a security risk. These are old horror stories. Why use big 
companies like IBM or Red Hat still sendmail when postfix is supposed to be so 
much safer? Why is sendmail the default MTA on Solaris, AIX, FreeBSD, RHEL and 
some more. Because it is unsafe?

There is no software without vulnerabilities.

Whatever you use, postfix or sendmail ... the theoretical risk of attack is 
exactly the same.

Best regards,

Morten

Re: restricting outbound e-mail to be from the authenticated user only

[Daniel Bromberg]

Noel, Thanks again, points acknowledged. I can't figure out how to edit 
the From: in Thunderbird without simultaneously changing the envelope 
value, but that's just one client among many.


Re: the From:/Reply-To cases: It seems one can write a better regexp 
then given by mouss, such as including angle brackets in the match 
field, or the full syntax /user@domain|".*"\b*\b*/. (This 
is a guess at the full syntax anyway, haven't read any RFCs recently.) 
But at some point, it seems one can try too hard to prevent such 
"masquerading" activity and instead one has to look at throttling or 
quota limits based on usage statistics (assuming overuse is the real 
concern). If this were a standard need, I imagine there would be a 
canned, comprehensive, iron-clad solution.


-Daniel

On 1/30/2011 10:16 PM, Noel Jones wrote:

On 1/30/2011 6:17 PM, Daniel Bromberg wrote:

Conceivably, someone could hack a non-standard e-mail client
to use the SASL name in the MAIL FROM, but tweak the 'From: '
line to anything they like (although the MAIL FROM would
appear in the Return-Path / Sender fields), and this is harder
to stop, correct? But we are in rare corner cases now, not
ordinary users I would think.


I think alternate From: is a fairly standard feature, no hacking 
required.  Even easier for them to use Reply-To:, which is supported 
by pretty much every mail client and aided by the fact that when 
reading mail, some popular mail clients don't show the address of the 
sender, only the name.


As mouss already pointed out, you can use a header_checks rule on 
submission/smtps that rejects mail that doesn't have 'From: 
.*@example.com', but it's not iron-clad protection.
Also note that defining a separate header_checks for submission/smtps 
requires defining an alternate cleanup_service, or a separate postfix 
instance.  Examples can be found in the archives.




  -- Noel Jones

Re: restricting outbound e-mail to be from the authenticated user only

[mouss]

Le 31/01/2011 01:17, Daniel Bromberg a écrit :
> Brilliant, reject_sender_login_mismatch is the perfect level of
> flexibility and is working now.  I can add whatever authorizations I
> need to my virtual user table in the DB, in a separate column if need
> be. (right now I'm using the trivial match of  =  login name>)
> 
> Importantly, if it's not a SASL-based session no such authorization
> check is done, rather the usual "you're a stranger, for local delivery
> only" rules apply there.

you need to read what reject_sender_login_mismatch does.

- it won't prevent internal users from using an external sender address
(unless you return some invalid login for external addresses, but then
that also applies to external users!).

- it also applies to non authenticated mail.
reject_authenticated_sender_login_mismatch is the variant that only
applies to authenticated mail.


> So, I don't need to have a separate ruleset, as
> this rule already has the proper granularity.
> 
> Conceivably, someone could hack a non-standard e-mail client to use the
> SASL name in the MAIL FROM, but tweak the 'From: ' line to anything they
> like (although the MAIL FROM would appear in the Return-Path / Sender
> fields), and this is harder to stop, correct? But we are in rare corner
> cases now, not ordinary users I would think.

depends on which mail clients they use. some mail clients make that hard
(they derive the envelope sender from the From: header). others make it
easy. but motivated users can ask for help on the Internet...

> 
>[snip]

Re: restricting outbound e-mail to be from the authenticated user only

[Daniel Bromberg]

Hm, there must be a disconnect.

I did read it, it sounded logical, I implemented it, and then my tests 
worked.


I have:

smtpd_sender_login_maps = mysql:/etc/postfix/mysql_sender_login_maps.cf

smtpd_recipient_restrictions =
   reject_sender_login_mismatch,
   permit_mynetworks,
   permit_sasl_authenticated,
...

When I send use the wrong source name invalidorigin, I get this:

*NOQUEUE: reject: RCPT from xxx : Sender 
address rejected: not owned by user validori...@example.com>*


But otherwise mail from the outside continues to come in to local 
(virtual) users fine, and using an authorized source name works.


If I understand correctly, what it does during an unauthenticated 
session is that if there is a recognized virtual user in the MAIL FROM: 
field, it requires that the user be (SASL) logged in. If the MAIL FROM: 
is /not /a recognized virtual user, the rule does nothing and passes the 
filtering to the rest of the rules. This is naturally also what I want. 
All good no?


Your final warning: "it won't prevent internal users from using an 
external sender address" -- define internal user? Those in my virtual 
table, or local Unix users? If the latter, I have none. As for "external 
sender address", are you referring to the envelope field, the Reply-to: 
field, or the From: field? If either of the latter two, yes we agreed 
earlier in the threat that that would have to be done with a cleanup filter.


Clarify?

-Daniel


On 1/31/2011 1:23 AM, mouss wrote:

Le 31/01/2011 01:17, Daniel Bromberg a écrit :

Brilliant, reject_sender_login_mismatch is the perfect level of
flexibility and is working now.  I can add whatever authorizations I
need to my virtual user table in the DB, in a separate column if need
be. (right now I'm using the trivial match of  =)

Importantly, if it's not a SASL-based session no such authorization
check is done, rather the usual "you're a stranger, for local delivery
only" rules apply there.

you need to read what reject_sender_login_mismatch does.

- it won't prevent internal users from using an external sender address
(unless you return some invalid login for external addresses, but then
that also applies to external users!).

- it also applies to non authenticated mail.
reject_authenticated_sender_login_mismatch is the variant that only
applies to authenticated mail.



So, I don't need to have a separate ruleset, as
this rule already has the proper granularity.

Conceivably, someone could hack a non-standard e-mail client to use the
SASL name in the MAIL FROM, but tweak the 'From: ' line to anything they
like (although the MAIL FROM would appear in the Return-Path / Sender
fields), and this is harder to stop, correct? But we are in rare corner
cases now, not ordinary users I would think.

depends on which mail clients they use. some mail clients make that hard
(they derive the envelope sender from the From: header). others make it
easy. but motivated users can ask for help on the Internet...


[snip]