RE: Best practice: sendmail and SMTP auth
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Doug Poland Sent: Wednesday, March 12, 2008 11:20 AM To: [EMAIL PROTECTED] Subject: Best practice: sendmail and SMTP auth Hello, Not sure if this is the most appropriate place for this question, but since all my servers are FreeBSD 6.x/7.x, I'll give it a go... I am considering setting up SMTP auth on a number of sendmail instances that I control. After much googling and reading, it is not clear to me that a server with SMTP auth configured/enabled can relay mail in both auth and non-auth modes. Some of the explanations posted have been Rube Goldberg in the extreme, greatly complicating what should have been a very simple response. A standard FreeBSD server determines relaying through use of the access.db file, as you probably already are aware. If you add in SMTP-auth then the ONLY change is that any client that authenticates in, is exempted from checking the access.db file - by default, they are allowed to relay. It is not necessary to turn on an encrypted channel for SMTP-auth. In fact, the most popular mail clients under Windows - Outlook, only support NTLM encryption on authentication which REQUIRES that the password be in cleartext on the mailserver. OR, you can use SSL encryption for Outlook - however it will require a (costly) commerically-rooted certificate on the server to do SSL or your mail clients won't encrypt without a lot of nasty mucking around on the user's side to install a self-signed root cert in their clients. As for 587, by default sendmail will allow auth on either port 25 or 587 and will allow non-encrypted auth on port 587. The fact of the matter is that the most secure way of running a production setup is to use a completely separate mailserver for AUTH-smtp and to use DIFFERENT userID's/passwords on that server than on the primary mailserver. That way spammers that discover the users e-mail address (which for most ISP's is the same as the userID account) cannot launch dictionary attacks against the SMTP-auth server. And, attackers that sniff a cleartext password on the SMTP-auth channel cannot use that userID to spam the mailserver. Ted ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Best practice: sendmail and SMTP auth
On Thu, Mar 13, 2008 at 01:43:11AM +, Matthew Seaman wrote: Derek Ragona wrote: At 02:19 PM 3/12/2008, Doug Poland wrote: Hello, Not sure if this is the most appropriate place for this question, but since all my servers are FreeBSD 6.x/7.x, I'll give it a go... I am considering setting up SMTP auth on a number of sendmail instances that I control. After much googling and reading, it is not clear to me that a server with SMTP auth configured/enabled can relay mail in both auth and non-auth modes. If one sendmail configuration cannot accommodate both SMTP auth and access.db, does one setup a dedicated SMTP auth host with a SMART_HOST option and feed incoming email to an non-auth instance of sendmail? Sorry if my terminology is ambiguous, I'm not a sendmail professional by day. You can set up sendmail to do both auth and non-auth. However best practice is to use auth only to control any spam relaying. Check the sendmail.org website FAQ's for setting this up. You will want to probably use cyrus-sasl or cyrus-sasl2 ports along with sendmail. A good solution to this is to use port 587 for Authenticated new mail submission and leave port 25 for the normal MTA-MTA type of (not authenticated) traffic. Firstly, to enable authentication you need to compile sendmail against cyrus SASL2 (don't bother with SASL1 -- it's legacy only). Now, you can either do that by installing sendmail from ports, or you can install the cyrus-sasl port and then make the base system sendmail link against it by adding this to /etc/make.conf: SENDMAIL_CFLAGS+= -I/usr/local/include -DSASL=2 SENDMAIL_LDFLAGS+= -L/usr/local/lib SENDMAIL_LDADD+=-lsasl2 I also like to use these two so that any milters etc. I build from ports interoperate with the base system sendmail. SENDMAIL_MILTER_IN_BASE=yes WITH_SENDMAIL_BASE= yes In order to do SMTP AUTH most effectively, you should enable STARTSSL support -- I alway feel better knowing that passwords are sent over an encrypted connection. This is a guide to what you need in your $(hostname).mc to add STARTSSL with AUTH /required/ on mail submitted via port 587, but not provided on port 25: first: turn off the default MSA setup, which we'll provide our own settings for later: FEATURE(no_default_msa)dnl ## overridden with DAEMON_OPTIONS below [...] second: basic configuration for SMTP AUTH -- what mechanisms are supported Note that LOGIN should only ever be allowed over encrypted connections as it sends passwords in plain text. You can also authenticate by using SSL certificates but that is handled directly by sendmail and you don't need to list EXTERNAL as a SASL mechanism. dnl ## Set SASL options TRUST_AUTH_MECH(`GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN')dnl define(`confAUTH_REALM', `your.domain.name')dnl define(`confAUTH_MECHANISMS', `GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN')dnl define(`confDONT_BLAME_SENDMAIL',`GroupReadableSASLDBFile')dnl [...] thirdly: insert the IP numbers of your servers into the following rules -- if you don't use IPv6 you can omit the lines for the external address, but you'll find things seem to work rather smoother if you keep the ::1 entries. The M=E flag says 'disable ETRN' and the M=Ea flag says 'require authentication (and disable ETRN)' M=A means 'don't offer authentication here' Note that I'm only requiring authentication on the external interfaces so I implicitly trust myself to submit e-mails via localhost:587 without it. You requirements may differ. See http://www.sendmail.org/~gshapiro/8.10.Training/DaemonPortOptions.html for an explanation of the capabilities of DAEMON_OPTIONS: dnl dnl Where the sendmail daemon should listen dnl DAEMON_OPTIONS(`Name=IPv4, Addr=12.34.56.78, M=A, Family=inet')dnl DAEMON_OPTIONS(`Name=IPv4, Addr=127.0.0.1, M=A, Family=inet')dnl DAEMON_OPTIONS(`Name=IPv6, Addr=::1, M=A, Family=inet6')dnl DAEMON_OPTIONS(`Name=IPv6, Addr=2000:aa:bb:cc::1, M=A, Family=inet6')dnl DAEMON_OPTIONS(`Name=MSA, Addr=12.34.56.78, Port=587, M=Ea')dnl DAEMON_OPTIONS(`Name=MSA, Addr=127.0.0.1, Port=587, M=E')dnl DAEMON_OPTIONS(`Name=MSA, Addr=2000:aa:bb:cc::1, Port=587, M=Ea, Family=inet6')dnl DAEMON_OPTIONS(`Name=MSA, Addr=::1, Port=587, M=E, Family=inet6')dnl fourthly: enable SSL capabilities in sendmail. See http://aput.net/~jheiss/sendmail/tlsandrelay.shtml for a good article on configuring this stuff (although ignore the section on compiling sendmail: you get that automatically built into the base system sendmail already) dnl dnl TLS stuff dnl define(`CERT_DIR', `MAIL_SETTINGS_DIR`'certs')dnl define(`confCACERT_PATH', `CERT_DIR')dnl define(`confCACERT', `CERT_DIR/cacert.pem')dnl define(`confSERVER_CERT', `CERT_DIR/cert.pem')dnl define(`confSERVER_KEY', `CERT_DIR/key.pem')dnl define(`confCLIENT_CERT', `CERT_DIR/cert.pem')dnl define(`confCLIENT_KEY', `CERT_DIR/key.pem')dnl fifthly: there is no
Best practice: sendmail and SMTP auth
Hello, Not sure if this is the most appropriate place for this question, but since all my servers are FreeBSD 6.x/7.x, I'll give it a go... I am considering setting up SMTP auth on a number of sendmail instances that I control. After much googling and reading, it is not clear to me that a server with SMTP auth configured/enabled can relay mail in both auth and non-auth modes. If one sendmail configuration cannot accommodate both SMTP auth and access.db, does one setup a dedicated SMTP auth host with a SMART_HOST option and feed incoming email to an non-auth instance of sendmail? Sorry if my terminology is ambiguous, I'm not a sendmail professional by day. -- Regards, Doug ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Best practice: sendmail and SMTP auth
At 02:19 PM 3/12/2008, Doug Poland wrote: Hello, Not sure if this is the most appropriate place for this question, but since all my servers are FreeBSD 6.x/7.x, I'll give it a go... I am considering setting up SMTP auth on a number of sendmail instances that I control. After much googling and reading, it is not clear to me that a server with SMTP auth configured/enabled can relay mail in both auth and non-auth modes. If one sendmail configuration cannot accommodate both SMTP auth and access.db, does one setup a dedicated SMTP auth host with a SMART_HOST option and feed incoming email to an non-auth instance of sendmail? Sorry if my terminology is ambiguous, I'm not a sendmail professional by day. -- Regards, Doug You can set up sendmail to do both auth and non-auth. However best practice is to use auth only to control any spam relaying. Check the sendmail.org website FAQ's for setting this up. You will want to probably use cyrus-sasl or cyrus-sasl2 ports along with sendmail. -Derek -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Best practice: sendmail and SMTP auth
Derek Ragona wrote: At 02:19 PM 3/12/2008, Doug Poland wrote: Hello, Not sure if this is the most appropriate place for this question, but since all my servers are FreeBSD 6.x/7.x, I'll give it a go... I am considering setting up SMTP auth on a number of sendmail instances that I control. After much googling and reading, it is not clear to me that a server with SMTP auth configured/enabled can relay mail in both auth and non-auth modes. If one sendmail configuration cannot accommodate both SMTP auth and access.db, does one setup a dedicated SMTP auth host with a SMART_HOST option and feed incoming email to an non-auth instance of sendmail? Sorry if my terminology is ambiguous, I'm not a sendmail professional by day. You can set up sendmail to do both auth and non-auth. However best practice is to use auth only to control any spam relaying. Check the sendmail.org website FAQ's for setting this up. You will want to probably use cyrus-sasl or cyrus-sasl2 ports along with sendmail. A good solution to this is to use port 587 for Authenticated new mail submission and leave port 25 for the normal MTA-MTA type of (not authenticated) traffic. Firstly, to enable authentication you need to compile sendmail against cyrus SASL2 (don't bother with SASL1 -- it's legacy only). Now, you can either do that by installing sendmail from ports, or you can install the cyrus-sasl port and then make the base system sendmail link against it by adding this to /etc/make.conf: SENDMAIL_CFLAGS+= -I/usr/local/include -DSASL=2 SENDMAIL_LDFLAGS+= -L/usr/local/lib SENDMAIL_LDADD+=-lsasl2 I also like to use these two so that any milters etc. I build from ports interoperate with the base system sendmail. SENDMAIL_MILTER_IN_BASE=yes WITH_SENDMAIL_BASE= yes In order to do SMTP AUTH most effectively, you should enable STARTSSL support -- I alway feel better knowing that passwords are sent over an encrypted connection. This is a guide to what you need in your $(hostname).mc to add STARTSSL with AUTH /required/ on mail submitted via port 587, but not provided on port 25: first: turn off the default MSA setup, which we'll provide our own settings for later: FEATURE(no_default_msa)dnl ## overridden with DAEMON_OPTIONS below [...] second: basic configuration for SMTP AUTH -- what mechanisms are supported Note that LOGIN should only ever be allowed over encrypted connections as it sends passwords in plain text. You can also authenticate by using SSL certificates but that is handled directly by sendmail and you don't need to list EXTERNAL as a SASL mechanism. dnl ## Set SASL options TRUST_AUTH_MECH(`GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN')dnl define(`confAUTH_REALM', `your.domain.name')dnl define(`confAUTH_MECHANISMS', `GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN')dnl define(`confDONT_BLAME_SENDMAIL',`GroupReadableSASLDBFile')dnl [...] thirdly: insert the IP numbers of your servers into the following rules -- if you don't use IPv6 you can omit the lines for the external address, but you'll find things seem to work rather smoother if you keep the ::1 entries. The M=E flag says 'disable ETRN' and the M=Ea flag says 'require authentication (and disable ETRN)' M=A means 'don't offer authentication here' Note that I'm only requiring authentication on the external interfaces so I implicitly trust myself to submit e-mails via localhost:587 without it. You requirements may differ. See http://www.sendmail.org/~gshapiro/8.10.Training/DaemonPortOptions.html for an explanation of the capabilities of DAEMON_OPTIONS: dnl dnl Where the sendmail daemon should listen dnl DAEMON_OPTIONS(`Name=IPv4, Addr=12.34.56.78, M=A, Family=inet')dnl DAEMON_OPTIONS(`Name=IPv4, Addr=127.0.0.1, M=A, Family=inet')dnl DAEMON_OPTIONS(`Name=IPv6, Addr=::1, M=A, Family=inet6')dnl DAEMON_OPTIONS(`Name=IPv6, Addr=2000:aa:bb:cc::1, M=A, Family=inet6')dnl DAEMON_OPTIONS(`Name=MSA, Addr=12.34.56.78, Port=587, M=Ea')dnl DAEMON_OPTIONS(`Name=MSA, Addr=127.0.0.1, Port=587, M=E')dnl DAEMON_OPTIONS(`Name=MSA, Addr=2000:aa:bb:cc::1, Port=587, M=Ea, Family=inet6')dnl DAEMON_OPTIONS(`Name=MSA, Addr=::1, Port=587, M=E, Family=inet6')dnl fourthly: enable SSL capabilities in sendmail. See http://aput.net/~jheiss/sendmail/tlsandrelay.shtml for a good article on configuring this stuff (although ignore the section on compiling sendmail: you get that automatically built into the base system sendmail already) dnl dnl TLS stuff dnl define(`CERT_DIR', `MAIL_SETTINGS_DIR`'certs')dnl define(`confCACERT_PATH', `CERT_DIR')dnl define(`confCACERT', `CERT_DIR/cacert.pem')dnl define(`confSERVER_CERT', `CERT_DIR/cert.pem')dnl define(`confSERVER_KEY', `CERT_DIR/key.pem')dnl define(`confCLIENT_CERT', `CERT_DIR/cert.pem')dnl define(`confCLIENT_KEY', `CERT_DIR/key.pem')dnl fifthly: there is no fifthly -- you're done. Build a sendmail.cf and test that it all works. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory
Re: Best practice: sendmail and SMTP auth
On 2008-03-12 14:19, Doug Poland [EMAIL PROTECTED] wrote: Hello, Not sure if this is the most appropriate place for this question, but since all my servers are FreeBSD 6.x/7.x, I'll give it a go... I am considering setting up SMTP auth on a number of sendmail instances that I control. After much googling and reading, it is not clear to me that a server with SMTP auth configured/enabled can relay mail in both auth and non-auth modes. If one sendmail configuration cannot accommodate both SMTP auth and access.db, does one setup a dedicated SMTP auth host with a SMART_HOST option and feed incoming email to an non-auth instance of sendmail? Sure it can. One of the ways to do something like this is: [1] Configure Sendmail to *require* authentication when one connects to its `submission' port (TCP port 587), and keep using /etc/mail/access for the default listener of the `smtp' port (TCP port 25). [2] Then you can configure your `trusted' clients to connect through port 587, and let everyone else keep using port 25. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Best practice: sendmail and SMTP auth
I dont remember if it can be done by sendmail, but with exim it can be done easy. Doug Poland пишет: Hello, Not sure if this is the most appropriate place for this question, but since all my servers are FreeBSD 6.x/7.x, I'll give it a go... I am considering setting up SMTP auth on a number of sendmail instances that I control. After much googling and reading, it is not clear to me that a server with SMTP auth configured/enabled can relay mail in both auth and non-auth modes. If one sendmail configuration cannot accommodate both SMTP auth and access.db, does one setup a dedicated SMTP auth host with a SMART_HOST option and feed incoming email to an non-auth instance of sendmail? Sorry if my terminology is ambiguous, I'm not a sendmail professional by day. -- Regards, Doug ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
