Mail server, what else?
Hi, All,
I just built a new mail server and so far it works well. It took me
almost two weeks to figure out all kind of stuff. I want to protect the
mail system at the best effort to use open source or free licensed
software.
Now I would like your advises on my system so I can improve it more.
Here is my mail server system:
- CentOS 6.4 64bit (SELinux disabled), iptables is in action.
- Apache, MySql, PHP
- Postfix 2.6.6 + Courier(Support virtual domain)
- MailScanner with ClamAV and Spamassassin(with pyzor/rozor2/DCC)
- Fail2ban (SSH, RoundCube, SASL)
- SPF, OpenDKIM, DMARC
- RoundCube webmail
- Mailman maillist
I appreciate if you can give me advise so I can further improve my system.
Gao
--
__
_|==|_
('')__/
>--(`^^')
(`^'^'`)
`=='
Re: which type of list should I use ?
On 07/10/2013 04:04 PM, jeffrey j donovan wrote:
On Jul 9, 2013, at 10:18 PM, jeffrey j donovan wrote:
Greetings
it's been a while since I have done this.
I have an old server running a mail list. I have successfully relocated the
list to a new server.
what i need to do re-route any message sent incorrectly to this list to the new
server.
message to --> listname@oldHost ---> hits { smtp relay on smtpHost } " some
rewrite or alias / transport sends to the message to --> list name@newHost.
transport maps didn't seem to make sense. as when it arrived at the new host,
the message would still say To:list name@oldHost, so newHost is going to throw
it back.
alias on the smtp relay said the alias had to be local, which made sense.
What type of re-write do i need to perform this action?
suggestions and flames welcome
-j
answering my own question
okay,.. I set up a generic map on my smtp relay
smtp_generic_maps = hash:/etc/postfix/generic
listn...@host1.example.com listn...@host2.example.com
when the message arrives it is delivered to "host1" and host1 sends the message
to host2.
How can I get the smtp relay to " not forward to host1 " but deliver directly
to host2. Do I need to setup transport also ?
Yes.
The generic map only changes the address - it doesn't change where it is
sent.
smtP_generic_maps is applied by the smtp(8) daemon, as its name indicates.
It has already been queued and routed at that point, and the next-hop is
fixed.
The OVERVIEW may help: http://www.postfix.org/OVERVIEW.html
Use a transport_map to alter the next-hop before it is queued.
--
J.
Re: Mail server, what else?
Forgot to mention that I also use SASL to authenticated user:
SMTP on port 587 only (STARSSL)
IMAP on port 993 (SSL)
POP3 on port 995 (SSL)
So for email, port 25, 587, 993,995 is opened on firewall.
--
__
_|==|_
('')__/
>--(`^^')
(`^'^'`)
`=='
Re: Mail server, what else?
Le 12/07/2013 21:08, J Gao a écrit : > Forgot to mention that I also use SASL to authenticated user: > SMTP on port 587 only (STARSSL) > IMAP on port 993 (SSL) > POP3 on port 995 (SSL) > > So for email, port 25, 587, 993,995 is opened on firewall. > > STARTTLS also exists in IMAP or POP3 (where it is called STLS). And you'll need SMTP on port 25 to receive email from outside.
"can't read SMFIC_RCPT reply packet header" errors with large attachments
Note: postfix 2.7.10 release A number of customers are noting that they are getting the following error when using a milter: Jun 26 20:18:10 zmail postfix/smtpd[11438]: connect from server.domain.com[1.2.3.4] Jun 26 20:18:10 zmail postfix/smtpd[32729]: NOQUEUE: filter: RCPT from server.domain.com[1.2.3.4]: : Sender address triggers FILTER smtp-amavis:[127.0.0.1]:10026; from= to= proto=ESMTP helo= Jun 26 20:18:10 zmail postfix/smtpd[32729]: warning: milter inet:127.0.0.1:7026: can't read SMFIC_RCPT reply packet header: Success Jun 26 20:18:10 zmail postfix/smtpd[32729]: NOQUEUE: milter-reject: RCPT from server.domain.com[1.2.3.4]: 451 4.7.1 Service unavailable - try again later; from= to= proto=ESMTP helo= Jun 26 20:18:10 zmail postfix/smtpd[32729]: lost connection after RCPT from server.domain.com[1.2.3.4] Jun 26 20:18:10 zmail postfix/smtpd[32729]: disconnect from server.domain.com[1.2.3.4] So far, we've tried increasing timeouts for the milter via: milter_connect_timeout milter_command_timeout milter_content_timeout But even for very large values, we are still seeing the problem occur. Setting milter_default_action=accept stops the error messages, but then bypasses the milter for these messages, somewhat defeating the purpose of the milter. ;) Any hints on what else we can look at? Thanks, Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration
Re: "can't read SMFIC_RCPT reply packet header" errors with large attachments
Quanah Gibson-Mount:
>
> Note: postfix 2.7.10 release
>
> A number of customers are noting that they are getting the following error
> when using a milter:
>
> Jun 26 20:18:10 zmail postfix/smtpd[32729]: NOQUEUE: filter: RCPT from
> server.domain.com[1.2.3.4]: :
> Sender address triggers FILTER smtp-amavis:[127.0.0.1]:10026;
> from= to=
> proto=ESMTP helo=
> Jun 26 20:18:10 zmail postfix/smtpd[32729]: warning: milter
> inet:127.0.0.1:7026: can't read SMFIC_RCPT reply packet header: Success
Note that this is logged within the same second, so changing the
POSTFIX milter_xxx_timeout settings has no effect.
Have you considered changing the timeout settings on the MILTER end?
It is possible that the Milter times out when requests from Postfix
are too far apart in time. The Postfix SMTP server has a 300s time
limit for client commands (reduced to 10s under overload). The Milter
time limit may be less.
The error message comes from this Postfix code fragment:
/*
* Receive the packet length.
*/
if ((vstream_fread(milter->fp, (char *) &len, UINT32_SIZE))
!= UINT32_SIZE) {
smfic_name = str_name_code(smfic_table, event);
msg_warn("milter %s: can't read %s reply packet header: %m",
milter->m.name, smfic_name != 0 ?
smfic_name : "(unknown MTA event)");
If you monitor the postfix-to-Milter communication with a network
sniffer, then you will see that the Milter closes the connection
without sending the SMFIC_RCPT reply to Postfix.
Wietse
rcpt to other domain
Dear all, I have a smtp account , but i can't send to other domain, Suppose: / root@debian:/home/mohsen# telnet MYHOST 25 Trying 74.207.236.196... Connected to MYHOST. Escape character is '^]'. 220 MYFQDN ESMTP Postfix ehlo MYHOST 250-MYFQDN 250-PIPELINING 250-SIZE 1024 250-VRFY 250-ETRN 250-STARTTLS 250-AUTH PLAIN 250-AUTH=PLAIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN mail from: MYEMAILADDRESS 250 2.1.0 Ok rcpt to: ANEMAILFROMGMAIL 554 5.7.1 : Relay access denied // How can i repair it? --mohsen
bounce departed users email
We run postfix 2.6.6 on a CentOS 6.3 server with a OpenLDAP 2.4.23 as a backend. Up until recently when a user would depart the agency we would just change their password and forward their email to their supervisor. However today we have had a user that has left that gets literally over a thousand "coupon" emails a day. We need to stop this user from receiving emails altogether. Temporarily I have removed the users ldap account completely and it appears that emails are indeed bouncing with a error 550 5.1.1 like I want. Any idea how to accomplish this without totally removing the users account? -- Donny B.
Re: "can't read SMFIC_RCPT reply packet header" errors with large attachments
--On Friday, July 12, 2013 4:10 PM -0400 Wietse Venema
wrote:
Quanah Gibson-Mount:
Note: postfix 2.7.10 release
A number of customers are noting that they are getting the following
error when using a milter:
Jun 26 20:18:10 zmail postfix/smtpd[32729]: NOQUEUE: filter: RCPT from
server.domain.com[1.2.3.4]: :
Sender address triggers FILTER smtp-amavis:[127.0.0.1]:10026;
from= to=
proto=ESMTP helo=
Jun 26 20:18:10 zmail postfix/smtpd[32729]: warning: milter
inet:127.0.0.1:7026: can't read SMFIC_RCPT reply packet header: Success
Note that this is logged within the same second, so changing the
POSTFIX milter_xxx_timeout settings has no effect.
Have you considered changing the timeout settings on the MILTER end?
It is possible that the Milter times out when requests from Postfix
are too far apart in time. The Postfix SMTP server has a 300s time
limit for client commands (reduced to 10s under overload). The Milter
time limit may be less.
The error message comes from this Postfix code fragment:
/*
* Receive the packet length.
*/
if ((vstream_fread(milter->fp, (char *) &len, UINT32_SIZE))
!= UINT32_SIZE) {
smfic_name = str_name_code(smfic_table, event);
msg_warn("milter %s: can't read %s reply packet header: %m",
milter->m.name, smfic_name != 0 ?
smfic_name : "(unknown MTA event)");
If you monitor the postfix-to-Milter communication with a network
sniffer, then you will see that the Milter closes the connection
without sending the SMFIC_RCPT reply to Postfix.
Ok, thanks! We've tried bumping up the milter timeout as well, but perhaps
it wasn't high enough. I will work some more on this with the client.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
Zimbra :: the leader in open source messaging and collaboration
Re: bounce departed users email
On 7/12/2013 4:44 PM, Donny Brooks wrote: > We run postfix 2.6.6 on a CentOS 6.3 server with a OpenLDAP 2.4.23 as a > backend. Up until recently when a user would depart the agency we would just > change their password and forward their email to their supervisor. However > today we have had a user that has left that gets literally over a thousand > "coupon" emails a day. We need to stop this user from receiving emails > altogether. > > Temporarily I have removed the users ldap account completely and it appears > that emails are indeed bouncing with a error 550 5.1.1 like I want. Any idea > how to accomplish this without totally removing the users account? > I find the "relocated" feature useful for this. http://www.postfix.org/postconf.5.html#relocated_maps # main.cf relocated_maps = hash:/etc/postfix/relocated The relocated table is a list of recipients to reject and a comment, usually a new email address, but the comment can be anything. # relocated previous_resid...@example.comu...@gmail.com ## or if you don't have a new address, former_u...@example.comunknown -- 12-07-2013 You can also use a check_recipient_access map in your smtpd_recipient_restrictions list, but for this purpose I find the relocated table easier. You can also add the former recipient to the transport map pointing to the error: transport, but I find the relocated table easier for this purpose. -- Noel Jones
Re: "can't read SMFIC_RCPT reply packet header" errors with large attachments
Quanah Gibson-Mount: > > It is possible that the Milter times out when requests from Postfix > > are too far apart in time. The Postfix SMTP server has a 300s time > > limit for client commands (reduced to 10s under overload). The Milter > > time limit may be less. ... > Ok, thanks! We've tried bumping up the milter timeout as well, but perhaps > it wasn't high enough. I will work some more on this with the client. Consider using MILTER time limits >= Postfix time limits. Setting them to a shorter value is a mistake. Wietse
Re: Mail server, what else?
On 12 Jul 2013, at 12:55 , J Gao wrote: > - Postfix 2.6.6 + Courier(Support virtual domain) Why would you setup a new system with a four year old version of Postfix that it is not even supported? 2.10 is current and 2.11 is right around the corner. -- I have seen galaxies die. I have watched atoms dance. But until I had the dark behind the eyes, I didn't know the death from the dance.
Re: Mail server, what else?
On 13-07-12 04:06 PM, LuKreme wrote:
On 12 Jul 2013, at 12:55 , J Gao wrote:
- Postfix 2.6.6 + Courier(Support virtual domain)
Why would you setup a new system with a four year old version of Postfix that
it is not even supported? 2.10 is current and 2.11 is right around the corner.
I used this:
http://vault.centos.org/6.4/os/Source/SPackages/postfix-2.6.6-2.2.el6_1.src.rpm
And patched with quota patch.
I could use 2.10 but I thought this will be "safe" for CentOS 6.
Gao
--
__
_|==|_
('')__/
>--(`^^')
(`^'^'`)
`=='
Re: Mail server, what else?
On 12 Jul 2013, at 17:15 , J Gao wrote: > I could use 2.10 but I thought this will be "safe" for CentOS 6. It might just be me, but I don't consider any software that is no longer supported to be safe, especially not something as critically important as an MTA. -- A bird in the hand makes it difficult to blow your nose.
Re: Mail server, what else?
On Friday, July 12, 2013 05:22:27 PM LuKreme wrote: > On 12 Jul 2013, at 17:15 , J Gao wrote: > > I could use 2.10 but I thought this will be "safe" for CentOS 6. > > It might just be me, but I don't consider any software that is no longer > supported to be safe, especially not something as critically important as > an MTA. Distributors are often placed in the position of needing to support older releases than are supported by upstream. So no longer supported by upstream isn't the same as no longer supported. Personally, I don't get the RHEL/CentOS preference for ancient software, but that doesn't mean it's unsafe to use. The most important thing is knowing to go talk to your distributor if you have a problem in these cases because it's outside the window of what the upstream is paying attention to. Scott K
