On Fri, Dec 21, 2012 at 06:52:21AM -0500, John Allen wrote:
> On 21/12/2012 6:25 AM, Reindl Harald wrote:
> >Am 21.12.2012 01:19, schrieb John Allen:
> >>I am doing the admin work for a small group, about 30 people.
> >>
> >>While this setup works I have the feeling that I am missing
> >>something in the Submission stanza of master.cf which might
> >>leave me vulnerable
> >below a 100% woring one with no open relay
> >
> >submission inet n - n - 50 smtpd -o
> > -o smtpd_client_connection_count_limit=15
> > -o smtpd_client_connection_rate_limit=80
> > -o smtpd_sasl_auth_enable=yes -o smtpd_delay_reject=yes -o
> > smtpd_client_restrictions=permit_sasl_authenticated,reject
Not directly a security issue, but it's a good idea to set -o
syslog_name so that you can know which connections were on which
port/smtpd. This is done in recent master.cf examples.
The above assumes that smtpd_recipient_restrictions also has
permit_sasl_authenticated If maintaining strict separation of your
outbound/submission stream from your inbound/MX stream, this might
not be a safe assumption.
Another thing missing from this, which exists in the sample:
-o milter_macro_daemon_name=ORIGINATING
If using smtpd_milters, this might be needed. If not, it hurts
nothing to have it set.
> Interesting, might it be a good idea to carry the rate limits
> to the main.cf in addition to including them in the submission
> stanza?
MX smtpd has different needs. The limits in this example would not
work on MX mail. Some MTAs (qmail comes to mind) which do one
connection per mail might easily exceed the above count and rate
limits. However, a user's MUA would be very unlikely to do so,
unless, of course, it is possessed by malware.
Note that these limits would only slow down malware; they couldn't
stop it.
--
http://rob0.nodns4.us/ -- system administration and consulting
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: