Re: this is my postfix conf
On Thursday 14 August 2008 12:46:26 sharad kanekar wrote: > Thanks a lot for your reply, > When I try to telnet on 110 port the error is as follows: > > [EMAIL PROTECTED] postfix]# telnet localhost 110 > Trying 127.0.0.1... > Connected to localhost.localdomain (127.0.0.1). > Escape character is '^]'. > +OK Dovecot ready. > USER sharad > +OK > PASS sharad > -ERR Authentication failed. This is a question for the Dovecot mailinglist, not Postfix. Mark. -- Mark Watts BSc RHCE MBCS Senior Systems Engineer QinetiQ Applied Technologies GPG Key: http://www.linux-corner.info/mwatts.gpg signature.asc Description: This is a digitally signed message part.
anvil logging
Is there a mechanism to reduce/stop the logging that anvil does? I have a low-traffic mail server and I'd prefer anvil to not log anything if possible. Am I limited to setting anvil_status_update_time to something high? (~1 week) Regards, Mark. -- Mark Watts BSc RHCE MBCS Senior Systems Engineer QinetiQ Applied Technologies GPG Key: http://www.linux-corner.info/mwatts.gpg signature.asc Description: This is a digitally signed message part.
Re: anvil logging
On Monday 01 September 2008 14:21:56 Wietse Venema wrote: > Mark Watts: > > Is there a mechanism to reduce/stop the logging that anvil does? > > No. Anvil logs something when it terminates (Postfix is not receiving > mail), and it logs something every 10 minutes or so when Postfix > is busy. > > > I have a low-traffic mail server and I'd prefer anvil to not log anything > > if possible. > > > > Am I limited to setting anvil_status_update_time to something high? (~1 > > week) > > That would suck up an insane amount of memory when you get > hit by a backscatter wave. > > What is the problem that you are trying to solve and that could > not be solved with grep(1)? Please describe the problem not the > solution. Are you worried that the disk wears out, or that you are > accelerating the thermodynamic death of the universe? > > Wietse My "problem" can be solved by grep, but since anvil's statistics are of no immediate use to me, I see little point in filling my logs with them. Mark. -- Mark Watts BSc RHCE MBCS Senior Systems Engineer QinetiQ Applied Technologies GPG Key: http://www.linux-corner.info/mwatts.gpg signature.asc Description: This is a digitally signed message part.
Re: Rejecting mail for a domain
On Thursday 11 September 2008 13:49:44 Robert Fitzpatrick wrote: > I have a domain getting hit this morning that is not being used any > longer, so I decided to just reject all mail to that domain. I put the > domain in my recipient_checks file as 'example.com REJECT', postmap'd > the file and did postfix reload. But still piling up in the logs with > address verification probes, I have my recipient_checks before address > verification in my smtpd_recipient_restrictions, can someone tell me > where else I need to reject the domain...thanks, Robert Why not just remove the domain from, I presume, your relay_domains list, whereupon it will be blocked by reject_unauth_destination? Mark. -- Mark Watts BSc RHCE MBCS Senior Systems Engineer QinetiQ Applied Technologies GPG Key: http://www.linux-corner.info/mwatts.gpg signature.asc Description: This is a digitally signed message part.
Re: postfix/virtual and dovecot/deliver
On Wednesday 01 October 2008 00:28:37 Stephen Holmes wrote: > Wietse Venema wrote > > > If root can do "cat /etc/postfix/mysql/virtual-mailbox-maps.cf" > > but the Postfix virtual delivery agent running as root can open > > the file, then you have something that interferes with file system > > access, like Selinux, Apparmor, Systrace, and so on. Configuring > > such systems is outside the scope of Postfix. > > > > Wietse > > Thanks Wietse. It's a pretty slim install (actually inside a Xen VM) > and running at init level 3 - it's primary function is as an email > server (hence the mailboxes on an NFS share). I'll check the filesystem > and process persmissions and see if I can track it down. Definitely no > AppArmor/SE Linux involved. Will let you know if I solve it. Thanks > again! You said earlier that you were running CentOS 5.2. As per a standard install, SELinux defaults to ON. If it is on (/usr/sbin/selinuxenabled returns 1 if its on, 0 if its disabled), you have two choices: 1) Disable SELinux Edit /etc/sysconfig/selinx and change: SELINUX=enforcing to SELINUX=permissive or SELINUX=disabled Then reboot and retry. 2) Fix your SELinux context on /etc/postfix/mysql/ If you use "ls -laZ /etc/postfix" I suspect you will see that the config files are "system_u:object_r:postfix_etc_t" and any scripts are "system_u:object_r:postfix_exec_t". I suspect your /etc/postfic/mysql directory is neither. Reset your SELinux context on that directory with: chcon -R system_u:object_r:postfix_etc_t /etc/postfix/mysql Mark. -- Mark Watts BSc RHCE MBCS Senior Systems Engineer QinetiQ Applied Technologies GPG Key: http://www.linux-corner.info/mwatts.gpg signature.asc Description: This is a digitally signed message part.
Re: postfix/virtual and dovecot/deliver
On Wednesday 01 October 2008 09:28:47 mouss wrote: > Mark Watts wrote: > > You said earlier that you were running CentOS 5.2. As per a standard > > install, SELinux defaults to ON. > > for this particular problem, he is using Suse (see the "Problem with > virtual mailboxes" short thread) and he said Apparmor isn't installed. > > > [snip] Humm, I wonder where I read CentOS then. Sorry for the noise... -- Mark Watts BSc RHCE MBCS Senior Systems Engineer QinetiQ Applied Technologies GPG Key: http://www.linux-corner.info/mwatts.gpg signature.asc Description: This is a digitally signed message part.
Re: Refused Message from RCPT TO
On Friday 10 October 2008 15:39:32 Carlos Williams wrote: > On Fri, Oct 10, 2008 at 10:33 AM, Brian Evans - Postfix List > > <[EMAIL PROTECTED]> wrote: > > Simply grep out the Queue ID from your log. > > The status parameter will tell you if it was sent, bounced, or delayed > > again. > > Thanks - so basically this is not specifically something my Postfix > server is doing wrong or occurring due to config, correct? Nothing you are directly in control of, no. Mark. -- Mark Watts BSc RHCE MBCS Senior Systems Engineer QinetiQ Applied Technologies GPG Key: http://www.linux-corner.info/mwatts.gpg signature.asc Description: This is a digitally signed message part.
Re: Refused Message from RCPT TO
On Friday 10 October 2008 14:56:42 Carlos Williams wrote: > I am seeing in my logs several of the following: > > -Queue ID- --Size-- Arrival Time -Sender/Recipient--- > 9D3DB1FA461C 1046060 Fri Oct 10 09:37:27 [EMAIL PROTECTED] > (host mx2.east.saic.com[198.151.13.25] said: 452 Deferred - [X.X.X.X] > (in reply to RCPT TO command)) > [EMAIL PROTECTED] > > Above the [X.X.X.X] is my public IP address for my Postfix server. My > question is this being caused due to a poor Postfix configuration in > main.cf or is this an issue based on how the client connecting to my > Postfix server is composing the message headers? > > I am assuming that the machine / client initiating the message is > improperly using the mail servers IP and this is what the receiving > host is rejecting, no? Probably greylisting. The messaage will probably get through on the next attempt. Mark. -- Mark Watts BSc RHCE MBCS Senior Systems Engineer QinetiQ Applied Technologies GPG Key: http://www.linux-corner.info/mwatts.gpg signature.asc Description: This is a digitally signed message part.
Re: postfix behind load balancers
On Friday 31 October 2008 13:22:27 Brian Evans - Postfix List wrote: > Robert Schetterer wrote: > > Hi @ll, > > has anbody experience with > > postfix behind load balancers > > im planning to test > > ha-proxy > > pen > > balance(ng) on ubuntu hardy in a HA-Cluster > > in front of postfix servers > > The pro's and con's of load balancing has been discussed many times > here. Search the archives for details. > > A different, and possibly better, way to handle the load of mail is a > simple round-robin DNS or multiple MX records of the same priority. > > A load balance setup can, and probably will, change the TCP source. > This is important in the detection of mynetworks as well as the > requirement for the XFORWARD command. Otherwise, Postifx will not know > the true origination and always log the load balancer as the source. Direct-Server-Return load balancing would not suffer from this problem, but it's about as good as multiple MX's, and a lot more complicated to setup. We use multiple MX's here to good effect. Mark. -- Mark Watts BSc RHCE MBCS Senior Systems Engineer QinetiQ Applied Technologies GPG Key: http://www.linux-corner.info/mwatts.gpg signature.asc Description: This is a digitally signed message part.
TLS Logging
I'm in the process of setting up TLS on a number of servers. I have two servers, both running Postfix, one an smtp client and the other an smtpd server, using a self-signed SSL certificate. Sending messages, I get the following in the log on the sender: Nov 19 10:05:01 mailr postfix/smtp[22688]: setting up TLS connection to mail.linux-corner.info Nov 19 16:05:01 mailr postfix/smtp[22688]: TLS connection established to mail.linux-corner.info: TLSv1 with cipher ADH-AES256-SHA (256/256 bits) However, the same server sending to another TLS-enabled server (I believe its qmail), I get this: Nov 19 10:09:09 mailr postfix/smtp[25134]: setting up TLS connection to burn.qinetiq.com Nov 19 10:09:09 mailr postfix/smtp[25134]: certificate verification failed for burn.qinetiq.com: num=18:self signed certificate Nov 19 10:09:09 mailr postfix/smtp[25134]: Unverified: subject_CN=burn.qinetiq.com, issuer=burn.qinetiq.com Nov 19 10:09:09 mailr postfix/smtp[25113]: TLS connection established to burn.qinetiq.com: TLSv1 with cipher AES256-SHA (256/256 bits) Why do I not get any verification messages from the remote postfix server, yet I do with the remote (qmail) one, when both are usiong self-signed certificates? Mark. -- Mark Watts BSc RHCE MBCS Senior Systems Engineer QinetiQ Applied Technologies GPG Key: http://www.linux-corner.info/mwatts.gpg signature.asc Description: This is a digitally signed message part.
Re: TLS Logging
On Wednesday 19 November 2008 13:23:39 Noel Jones wrote: > Mark Watts wrote: > > I'm in the process of setting up TLS on a number of servers. > > I have two servers, both running Postfix, one an smtp client and the > > other an smtpd server, using a self-signed SSL certificate. > > > > Sending messages, I get the following in the log on the sender: > > > > Nov 19 10:05:01 mailr postfix/smtp[22688]: setting up TLS connection to > > mail.linux-corner.info Nov 19 16:05:01 mailr postfix/smtp[22688]: TLS > > connection established to mail.linux-corner.info: TLSv1 with cipher > > ADH-AES256-SHA (256/256 bits) > > When receiving mail, a client certificate is not requested. > As a result, the connection is considered "Anonymous". > You can control this with smtpd_tls_ask_ccert, but some mail > clients have trouble when this is set to "yes", so the > sensible default is "no". > http://www.postfix.org/postconf.5.html#smtpd_tls_ask_ccert > > > However, the same server sending to another TLS-enabled server (I believe > > its qmail), I get this: > > > > Nov 19 10:09:09 mailr postfix/smtp[25134]: setting up TLS connection to > > burn.qinetiq.com Nov 19 10:09:09 mailr postfix/smtp[25134]: certificate > > verification failed for burn.qinetiq.com: num=18:self signed certificate > > Nov 19 10:09:09 mailr postfix/smtp[25134]: Unverified: > > subject_CN=burn.qinetiq.com, issuer=burn.qinetiq.com Nov 19 10:09:09 > > mailr postfix/smtp[25113]: TLS connection established to > > burn.qinetiq.com: TLSv1 with cipher AES256-SHA (256/256 bits) > > When sending mail, the server certificate is always received > and verified. There are various smtp_tls_* options that allow > you to control what happens next; the sensible default > behavior is to ignore verification errors and continue. > http://www.postfix.org/TLS_README.html > > > Why do I not get any verification messages from the remote postfix > > server, yet I do with the remote (qmail) one, when both are usiong > > self-signed certificates? > > > > Mark. > > Virtually all MTA to MTA smtp tls is opportunistic encryption > - it's nice but not required. In this context, it doesn't > matter if the certificate is verified since you are willing to > accept unencrypted connections from the same client. > > If you're establishing a secure channel between sites with > encryption and verification required, there are options > discussed in the TLS_README to allow this. OK, I understand this, but in my example both connections were from the same server to remote servers with self-signed certificates. I would have expected to see the same verification (failures in this case) log entries for both connections, but I don't. Mark. -- Mark Watts BSc RHCE MBCS Senior Systems Engineer QinetiQ Applied Technologies GPG Key: http://www.linux-corner.info/mwatts.gpg signature.asc Description: This is a digitally signed message part.
Re: TLS Logging
> When you're sending mail, no client certificate is requested. > Your postfix doesn't know (and doesn't care) that the client > has a self-signed certificate. Indeed, but its the *remote servers* than have self-signed certificates. The originating server doesn't have any certificates at all. I've simply configured "smtp_use_tls = yes" and "smtp_tls_loglevel = 1". The logs are from the originating server. Mark. -- Mark Watts BSc RHCE MBCS Senior Systems Engineer QinetiQ Applied Technologies GPG Key: http://www.linux-corner.info/mwatts.gpg signature.asc Description: This is a digitally signed message part.
Re: TLS Logging
On Wednesday 19 November 2008 13:42:59 Noel Jones wrote: > Mark Watts wrote: > >> When you're sending mail, no client certificate is requested. > >> Your postfix doesn't know (and doesn't care) that the client > >> has a self-signed certificate. > > Ooops, spoke backwards there. When you receive mail (the > smtpd server) no certificate is requested, so no certificate > verification is performed and no complaints are logged. > > > Indeed, but its the *remote servers* than have self-signed certificates. > > The originating server doesn't have any certificates at all. > > I've simply configured "smtp_use_tls = yes" and "smtp_tls_loglevel = 1". > > The logs are from the originating server. > > Right. I think my original question still stands; why do connections to one server not generate verification messages, while connections to a third server do. Both remote servers have self-signed ssl certificates. Real logs from the sending server: [This is a single mail sent to recipients at both domains, both of which have self-signed ssl certificates] Nov 19 13:46:18 mailr postfix/smtpd[25668]: connect from internal[128.98.2.2] Nov 19 13:46:18 mailr postfix/smtpd[25668]: C9B7C8CCD7: client=internal[128.98.2.2] Nov 19 13:46:18 mailr postfix/smtpd[25732]: connect from internal[128.98.2.2] Nov 19 13:46:18 mailr postfix/smtpd[25732]: CF0BE8CCD8: client=internal[128.98.2.2] Nov 19 13:46:18 mailr postfix/cleanup[25730]: C9B7C8CCD7: message-id=<[EMAIL PROTECTED]> Nov 19 13:46:18 mailr postfix/qmgr[22680]: C9B7C8CCD7: from=<[EMAIL PROTECTED]>, size=1726, nrcpt=1 (queue active) Nov 19 13:46:18 mailr postfix/smtpd[25668]: disconnect from internal[128.98.2.2] Nov 19 13:46:18 mailr postfix/cleanup[25734]: CF0BE8CCD8: message-id=<[EMAIL PROTECTED]> Nov 19 13:46:18 mailr postfix/qmgr[22680]: CF0BE8CCD8: from=<[EMAIL PROTECTED]>, size=1725, nrcpt=1 (queue active) Nov 19 13:46:18 mailr postfix/smtpd[25732]: disconnect from internal[128.98.2.2] Nov 19 13:46:19 mailr postfix/smtp[25735]: setting up TLS connection to burn.qinetiq.com Nov 19 13:46:19 mailr postfix/smtp[25735]: certificate verification failed for burn.qinetiq.com: num=18:self signed certificate Nov 19 13:46:19 mailr postfix/smtp[25735]: Unverified: subject_CN=burn.qinetiq.com, issuer=burn.qinetiq.com Nov 19 13:46:19 mailr postfix/smtp[25735]: TLS connection established to burn.qinetiq.com: TLSv1 with cipher AES256-SHA (256/256 bits) Nov 19 13:46:19 mailr postfix/smtp[25735]: CF0BE8CCD8: to=<[EMAIL PROTECTED]>, relay=burn.qinetiq.com[192.102.214.28]:25, delay=0.74, delays=0.07/0.02/0.46/0.2, dsn=2.0.0, status=sent (250 ok 1227102371 qp 26972 by burn.qinetiq.com) Nov 19 13:46:19 mailr postfix/qmgr[22680]: CF0BE8CCD8: removed Nov 19 13:46:19 mailr postfix/smtp[25731]: setting up TLS connection to mail.linux-corner.info Nov 19 13:46:20 mailr postfix/smtp[25731]: TLS connection established to mail.linux-corner.info: TLSv1 with cipher ADH-AES256-SHA (256/256 bits) Nov 19 13:46:22 mailr postfix/smtp[25731]: C9B7C8CCD7: to=<[EMAIL PROTECTED]>, relay=mail.linux-corner.info[209.20.80.102]:25, delay=3.3, delays=0.06/0/1.3/1.9, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 78ABD12C24D) Nov 19 13:46:22 mailr postfix/qmgr[22680]: C9B7C8CCD7: removed Mark. -- Mark Watts BSc RHCE MBCS Senior Systems Engineer QinetiQ Applied Technologies GPG Key: http://www.linux-corner.info/mwatts.gpg signature.asc Description: This is a digitally signed message part.
Re: TLS Logging
On Wednesday 19 November 2008 14:00:29 Wietse Venema wrote: > Mark Watts: > > I think my original question still stands; why do connections to > > one server not generate verification messages, while connections > > to a third server do. Both remote servers have self-signed ssl > > certificates. > > Presumably, those certificates are signed with different keys. I > run tests with self-signed certificates and never see complaints, > because the clients know the signing key. The client (the sending postfix server) in this case does not know about *any* signing keys used by the remote servers for their ssl certificates. My understanding is that the verification failure messages are akin to those you would see browsing to an HTTPS:// website using a self-signed certificate? If so, I know for a fact that the remote server which does not generate verification messages is using a self-signed certificate, because I created it (and the self-signed CA to go with it). Now is this the issue; that if the server certificate is signed by a CA (regardless of whether that CA is itself self-signed or not), it does not trigger verification failure messages? Mark. -- Mark Watts BSc RHCE MBCS Senior Systems Engineer QinetiQ Applied Technologies GPG Key: http://www.linux-corner.info/mwatts.gpg signature.asc Description: This is a digitally signed message part.
Re: TLS Logging
On Wednesday 19 November 2008 14:48:32 Noel Jones wrote: > Mark Watts wrote: > > On Wednesday 19 November 2008 14:00:29 Wietse Venema wrote: > >> Mark Watts: > >>> I think my original question still stands; why do connections to > >>> one server not generate verification messages, while connections > >>> to a third server do. Both remote servers have self-signed ssl > >>> certificates. > >> > >> Presumably, those certificates are signed with different keys. I > >> run tests with self-signed certificates and never see complaints, > >> because the clients know the signing key. > > > > The client (the sending postfix server) in this case does not know about > > *any* signing keys used by the remote servers for their ssl certificates. > > > > My understanding is that the verification failure messages are akin to > > those you would see browsing to an HTTPS:// website using a self-signed > > certificate? > > If so, I know for a fact that the remote server which does not generate > > verification messages is using a self-signed certificate, because I > > created it (and the self-signed CA to go with it). > > > > Now is this the issue; that if the server certificate is signed by a CA > > (regardless of whether that CA is itself self-signed or not), it does not > > trigger verification failure messages? > > > > Mark. > > Did you use the same CA on both servers? Then the certificate > is not unknown. Self-signed certificates verify just fine if > both sites have the same CA. No. The server I'm in control of is signed by a CA. (This server does not give any verification failure messages) I don't know about the other server. Mark. -- Mark Watts BSc RHCE MBCS Senior Systems Engineer QinetiQ Applied Technologies GPG Key: http://www.linux-corner.info/mwatts.gpg signature.asc Description: This is a digitally signed message part.
Re: TLS Logging
> One thing to keep in mind is that recent Postfix versions don't > necessarily exchange certificates (also known as anonymous TLS). As mentioned earlier in the thread, the remote server with the extra log entries is not Postfix, so this may also go towards explaining the behaviour I'm seeing. > We could speculate forever on what is happening, or you could make > a proper recording and let the data speak for itself. At the risk of sounding dumb, what would a "proper recording" be in this case? Mark. -- Mark Watts BSc RHCE MBCS Senior Systems Engineer QinetiQ Applied Technologies GPG Key: http://www.linux-corner.info/mwatts.gpg signature.asc Description: This is a digitally signed message part.
Re: TLS Logging
On Wednesday 19 November 2008 16:29:09 Victor Duchovni wrote: > On Wed, Nov 19, 2008 at 07:23:39AM -0600, Noel Jones wrote: > > Mark Watts wrote: > > >I'm in the process of setting up TLS on a number of servers. > > >I have two servers, both running Postfix, one an smtp client and the > > > other an smtpd server, using a self-signed SSL certificate. > > > > > >Sending messages, I get the following in the log on the sender: > > > > > >Nov 19 10:05:01 mailr postfix/smtp[22688]: setting up TLS connection to > > >mail.linux-corner.info > > >Nov 19 16:05:01 mailr postfix/smtp[22688]: TLS connection established to > > >mail.linux-corner.info: TLSv1 with cipher ADH-AES256-SHA (256/256 bits) > > > > When receiving mail, a client certificate is not requested. > > As a result, the connection is considered "Anonymous". > > You can control this with smtpd_tls_ask_ccert, but some mail > > clients have trouble when this is set to "yes", so the > > sensible default is "no". > > http://www.postfix.org/postconf.5.html#smtpd_tls_ask_ccert > > This is wrong. The Postfix server in the above case supports anonymous > ciphers, so a certificate-less cipher (ADH-AES256-SHA) is negotiated. > > > >However, the same server sending to another TLS-enabled server (I > > > believe its qmail), I get this: > > > > > >Nov 19 10:09:09 mailr postfix/smtp[25134]: setting up TLS connection to > > >burn.qinetiq.com > > >Nov 19 10:09:09 mailr postfix/smtp[25134]: certificate verification > > > failed for burn.qinetiq.com: num=18:self signed certificate > > >Nov 19 10:09:09 mailr postfix/smtp[25134]: Unverified: > > >subject_CN=burn.qinetiq.com, issuer=burn.qinetiq.com > > >Nov 19 10:09:09 mailr postfix/smtp[25113]: TLS connection established to > > >burn.qinetiq.com: TLSv1 with cipher AES256-SHA (256/256 bits) > > > > When sending mail, the server certificate is always received > > and verified. There are various smtp_tls_* options that allow > > you to control what happens next; the sensible default > > behavior is to ignore verification errors and continue. > > http://www.postfix.org/TLS_README.html > > This has nothing to do with client certs, the server does not support > anon ciphers, so AES256-SHA is used, which uses RSA certs, and the > warning is issued. I did wonder what the difference between ADH-AES256-SHA and AES256-SHA was. Both still result in an encrypted connection though, right? Mark. -- Mark Watts BSc RHCE MBCS Senior Systems Engineer QinetiQ Applied Technologies GPG Key: http://www.linux-corner.info/mwatts.gpg signature.asc Description: This is a digitally signed message part.
Re: TLS Logging
On Thursday 20 November 2008 15:05:50 Victor Duchovni wrote: > On Thu, Nov 20, 2008 at 08:56:04AM +0000, Mark Watts wrote: > > I did wonder what the difference between ADH-AES256-SHA and AES256-SHA > > was. Both still result in an encrypted connection though, right? > > $ openssl ciphers -v ADH-AES256-SHA:AES256-SHA > ADH-AES256-SHA SSLv3 Kx=DH Au=None Enc=AES(256) > Mac=SHA1 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) > Mac=SHA1 > > It would be to call a cipher suite an AES256 cipher-suite if no encryption > took place. Both if the above SSLv3 (thus also TLS 1.x) cipher-suites > use AES256 for data encryption, and SHA1 for message integrity. > > "Encryption" is not a synonym for "security", when SSL is used to encrypt, > but not to authenticate, you are protected from passive-eavedropping > (wiretap) attacks, but not from active man-in-the-middle attacks. If you > want to know the the peer on the other end of the encrypted channel is > the one you intended to communicate with, you need to authenticate that > peer, which is where certificate checks enter the discussion. Indeed - this is next on my list of things to investigate. > The first cipher has no authentication mechanism in the SSL handshake, > so you get encryption only, no authentication. The second cipher makes > authentication "possible", but you can still (and typically do) ignore the > peer certificate. So in practice the two ciphers offer the same security, > provided you are not going to reject unauthenticated connections when > sending email to the domain in question. Do people typically use SASL authentication insted of certificate checking? On the remote server I have control over, I've configured SASL + TLS on the submission port, and TLS is optional on port 25 for Internet clients. Does adding (client) certificates add anything in this case? Mark. -- Mark Watts BSc RHCE MBCS Senior Systems Engineer QinetiQ Applied Technologies GPG Key: http://www.linux-corner.info/mwatts.gpg signature.asc Description: This is a digitally signed message part.
Re: TLS Logging
On Thursday 20 November 2008 15:52:56 Victor Duchovni wrote: > On Thu, Nov 20, 2008 at 03:48:32PM +0000, Mark Watts wrote: > > > The first cipher has no authentication mechanism in the SSL handshake, > > > so you get encryption only, no authentication. The second cipher makes > > > authentication "possible", but you can still (and typically do) ignore > > > the peer certificate. So in practice the two ciphers offer the same > > > security, provided you are not going to reject unauthenticated > > > connections when sending email to the domain in question. > > > > Do people typically use SASL authentication insted of certificate > > checking? > > You are confusing authenticating users for submission access with > authenticating the destination server for channel integrity. > > This is the difference between web-site login forms and HTTPS server > certificate checks. > > I don't want to sidetrack into client certs vs SASL login in this thread. OK, I understand - thanks for your help, its certainly increased my understanding of my original problem. Thanks, Mark. -- Mark Watts BSc RHCE MBCS Senior Systems Engineer QinetiQ Applied Technologies GPG Key: http://www.linux-corner.info/mwatts.gpg signature.asc Description: This is a digitally signed message part.
Re: Redundant remote server
On Monday 24 November 2008 12:04:44 bsd wrote: > Hello folks, > > > I am actually working for an African country where the electricity is > not as stable as one could expect - even in the infrastructure of the > historical telco operator… > > With all the care that we have been able to devote to this project, > stability is still very very limited. > So my idea was to create a fully redundant mail server. > > Ideally I would like people not to have to reconfigure anything on > their client and to be able to connect to any resource available > online (main African server or the backup one in Europe) - in a > seamless way. > > > Mail protocol has solved the issue of "backup" server (secondary MX)… > but how can I achieve a real redundant server. Knowing that the "main > server" and the "slave" are located 8000 Km away with poor link quality. > > What would be your aproach to solving this problem. > Of course loosing mail is really an issue. Technical solutions to this would typically involve some form of replication, often at the filesystem or block layer (eg: DRBD), coupled to a mechanism to fail-over between systems (eg: heartbeat moving an IP address between two machines on the same subnet). These start to break-down when you have an unreliable link between the two systems, since this will cause a lot of bouncing between the sites, and probably a lot of split-brain scenarios where both machines think they are the primary, and both try and claim the "live" resources. As an aside, requiring that clients do not need to change any configuration would assume that they are configured to point to a DNS hostname, so you'd need a mechanism to change that in the event of a fail-over. While this is technically easy, what happens if your primary DNS server is hosted in the same place as your mail server and a failure occurs? Assuming your working data-set is such that a regular rsync would suffice to keep two machines in sync (with a human making the decision to change a DNS entry to point to the backups server) I think this may be one of the few viable options you have. Mark. -- Mark Watts BSc RHCE MBCS Senior Systems Engineer QinetiQ Applied Technologies GPG Key: http://www.linux-corner.info/mwatts.gpg signature.asc Description: This is a digitally signed message part.
Re: SPF Checking
On Wednesday 14 January 2009 16:22:25 Russ Lavoy wrote: > Hello List, > > I am wondering about an SPF checking addition for postfix. Where I see all > of the addon software, I am not 100% comfortable modifying the postfix code > and still have it be as secure as it was when I first set it up. > > Are there any plans on integrating SPF checking into postfix itself? > > If not, does anyone out there know how to stop forged emails coming in as > someone you know, but they did not send them (as per their email headers)? > > Thanks! Personally, I use "python-postfix-policyd-spf" from http://www.openspf.org/Software (a.k.a. pypolicyd-spf), implemented as a check_policy_service. EG: master.cf: policyd-spf unix - n n - 0 spawn user=nobody argv=/usr/bin/policyd-spf main.cf: smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, ... check_policy_service unix:private/policyd-spf # ls -l /var/spool/postfix/private/policyd-spf srw-rw-rw- 1 postfix postfix 0 Jan 6 16:09 /var/spool/postfix/private/policyd-spf HTH, Mark. -- Mark Watts BSc RHCE MBCS Senior Systems Engineer QinetiQ Applied Technologies GPG Key: http://www.linux-corner.info/mwatts.gpg signature.asc Description: This is a digitally signed message part.
Splitting recieve/transmit processes
I have a requirement to split a postfix relay installation across two servers. One server will be responsible for receiving incoming SMTP email, and queueuing it on disk. A 3rd party piece of software will be responsible for moving the queued mail to the second server. (Additional processing on the mail will happen here). The second server will be responsible for picking up the queue and continuing the SMTP relaying process. This system will not be connected to the Internet, and is designed to be used in a controlled environment. Does anyone have any advice on configuring postfix in such a way? Mark. -- Mark Watts BSc RHCE MBCS Senior Systems Engineer QinetiQ Applied Technologies GPG Key: http://www.linux-corner.info/mwatts.gpg signature.asc Description: This is a digitally signed message part.
Re: Splitting recieve/transmit processes
On Wednesday 28 January 2009 13:10:52 Wietse Venema wrote: > Mark Watts: > > I have a requirement to split a postfix relay installation across two > > servers. > > > > One server will be responsible for receiving incoming SMTP email, and > > queueuing it on disk. > > > > A 3rd party piece of software will be responsible for moving the queued > > mail to the second server. (Additional processing on the mail will happen > > here). > > Postfix has two "queue export" mechanisms: smtp(8) and pipe(8). > Direct queue file access by non-Postfix software is unsupported. Assuming no modification of the queue files is necessary, is duplication of /var/spool/postfix/queue/ to another machine possible? The remote machine will never recieve email (due to the closed environment). I understand that the use of "postsuper" may deal with the naming/inode issue - is this correct? Mark. -- Mark Watts BSc RHCE MBCS Senior Systems Engineer QinetiQ Applied Technologies GPG Key: http://www.linux-corner.info/mwatts.gpg signature.asc Description: This is a digitally signed message part.
Queue monitoring
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have a requirement to be able to monitor a postfix queue over time, and to determine whether any messages are delayed due to problems connecting to a remote servers. The mail system concerned is pretty simple; messages are generated locally and relayed to a remote server across a VPN. While I can monitor connectivity to port 25 on the remote server, that doesn't guarantee that it would accept a message for onward delivery; I need to be able to notice delivery issues and initiate a meatware interface. Once the message is accepted by the remote server, onward delivery is monitored by another system that I have no control over. I believe I am limited to monitoring the local mail queue to see if messages are being deferred, and reporting accordingly? The postqueue(1) command doesn't appear to generate output in a format particularly useful for scripts to parse, so is there another tool I can use or is there better way to approach this problem? Regards, Mark. - -- Mark Watts BSc RHCE Senior Systems Engineer, Secure Managed Hosting www.QinetiQ.com QinetiQ - Delivering customer-focused solutions GPG Key: http://www.linux-corner.info/mwatts.gpg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkzultIACgkQBn4EFUVUIO12BACg+dN8IS1m9B0hBCmPEobBoUJs koAAoMBATaCVSxfHw4A0JM42SfEMXt3d =2dAI -END PGP SIGNATURE-
Re: Queue monitoring
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/25/2010 05:24 PM, Wietse Venema wrote: > Mark Watts: >> >> I have a requirement to be able to monitor a postfix queue over time, >> and to determine whether any messages are delayed due to problems >> connecting to a remote servers. >> >> The mail system concerned is pretty simple; messages are generated >> locally and relayed to a remote server across a VPN. >> >> While I can monitor connectivity to port 25 on the remote server, that >> doesn't guarantee that it would accept a message for onward delivery; I >> need to be able to notice delivery issues and initiate a meatware >> interface. Once the message is accepted by the remote server, onward >> delivery is monitored by another system that I have no control over. >> >> I believe I am limited to monitoring the local mail queue to see if >> messages are being deferred, and reporting accordingly? >> >> The postqueue(1) command doesn't appear to generate output in a format >> particularly useful for scripts to parse, so is there another tool I can >> use or is there better way to approach this problem? > > QSHAPE (bundled with Postfix source) reports queue stats by age. > http://www.postfix.org/QSHAPE_README.html > > Wietse This should do the trick - thanks. Mark. - -- Mark Watts BSc RHCE Senior Systems Engineer, Secure Managed Hosting www.QinetiQ.com QinetiQ - Delivering customer-focused solutions GPG Key: http://www.linux-corner.info/mwatts.gpg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkzzdyoACgkQBn4EFUVUIO2d/QCgnuYy/HhCZL4TN9UEMujUvQKO +8gAniS/R7Hd5rscYsAY5qbOjNMWV5xo =v0gR -END PGP SIGNATURE-
GeoIP based rejections
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'd like to be able to reject connections from remote IP addresses if they're from certain countries (or conversely only allow from certain countries). What are my options for doing this in/with postfix? Mark. - -- Mark Watts BSc RHCE Senior Systems Engineer, MSS Secure Managed Hosting www.QinetiQ.com QinetiQ - Delivering customer-focused solutions GPG Key: http://www.linux-corner.info/mwatts.gpg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1478QACgkQBn4EFUVUIO3U6ACgz+hO+yC8keYsZYLKHyby6ztl J54AoPc3DPtnqjalqtPrNq/Pc7XtnFtC =bj6C -END PGP SIGNATURE-
Re: GeoIP based rejections
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/10/2011 03:49 PM, Bas Mevissen wrote: > On Thu, 2011-03-10 at 15:35 +0000, Mark Watts wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> >> I'd like to be able to reject connections from remote IP addresses if >> they're from certain countries (or conversely only allow from certain >> countries). >> >> What are my options for doing this in/with postfix? >> > > What is the reason you want to do this? If you want this mere as an anti > spam measure, I advise to use IP-based black lists. They are more > powerful and are adapted for spam hosts around the globe as they appear. > > Regards, > I'm already using three RBL's (b.barracudacentral.org, zen.spamhaus.org and dnsbl.sorbs.net) yet I'm still seeing a fair amount of spam coming in from Russian and Romanian IP ranges that isn't blocked. Mark. - -- Mark Watts BSc RHCE Senior Systems Engineer, MSS Secure Managed Hosting www.QinetiQ.com QinetiQ - Delivering customer-focused solutions GPG Key: http://www.linux-corner.info/mwatts.gpg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk149QAACgkQBn4EFUVUIO2iBACfRmtaWbHtuRFX8fLJhLvt/kR+ c5cAn2/y3ckj5ORHcap+zVNMNCDXGTpo =Cjjy -END PGP SIGNATURE-
Re: GeoIP based rejections
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/12/2011 12:17 PM, Justin Piszcz wrote: > > On Sat, 12 Mar 2011, mouss wrote: > >> - write your own policy server or milter > > Hi, > > There is a GeoIP policy server out there if you search around, it is > called: geoip-policyd-0.01.tar.gz > > With some modifications, it works quite nicely. > > Justin. > This is just what I'm looking for. Annoyingly, the spams I was getting (they were all supposedly coming from one particular domain) have ceased! Thanks for all the advice, Mark. - -- Mark Watts BSc RHCE Senior Systems Engineer, MSS Secure Managed Hosting www.QinetiQ.com QinetiQ - Delivering customer-focused solutions GPG Key: http://www.linux-corner.info/mwatts.gpg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1+NS8ACgkQBn4EFUVUIO3sEACfZ3PkwI2alGepb2palg3S5RZp XPEAoLtISZQc0yJrElTl4h4sYzduZPVQ =qQ9F -END PGP SIGNATURE-
