On 02/18/2012 02:22 PM, [email protected] wrote:
Thanks Eric that makes me feel a little better.
Since the "incident" I'm determined to give myself a crash course in Qmail
mailserver administration. I'm certainly not at the level you and most
others on the list are but I'm going to get better. I'm determined not to have
this happen again since we are still fighting the ridiculousness of
a "poor" rating at senderbase.org. Since our server is pretty low volume, it
could take a while for that to clear itself up. Although, I could
always take the Cisco support rep's advice and contact all 206 (at last count)
Ironport domains that are blocking our email and have them whitelist
us temporarily :)
Do you have any configurations is place to prevent this type of thing? Such as
limiting the rate/amount of email being sent from an account? How
do you monitor your server to tell if something is even taking place? I did
look back at our Cacti graphs of the mailserver, and of course it's
obvious now and I'll monitor that more closely, however, I was just wondering if you use
something in "real-time" to check on things?
Thanks, as always, for your help
Robert
I guess I don't need to mention passwords being compromised. ;) Along
those lines, be sure that your webmail is configured to always use
https. These lines in /etc/httpd/conf/squirrelmail.conf help:
RewriteEngine on
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(webmail.*)$ https://%{SERVER_NAME}/$1 [R=301,L]
This should probably be in the stock configuration, although ssl needs
to be configured properly as well.
Likewise, all clients should be configured to use secure transports,
like TLS. This is enforced in dovecot by default. There is no way to
enforce this with smtp/submission yet, but a request has been made to
add the feature to spamdyke. Hopefully that will be coming soon.
If your QMT host shares a public address with other hosts, especially
windoze machines, this can be a source of spam that doesn't originate
from QMT. When QMT is not the sole host on a public IP address, a
firewall should be in place (I use IPCop myself) which blocks all
traffic destined to port 25 that does not originate from the QMT (or
other mail server) host.
SPF and DKIM can improve deliverability, but I don't think they help
regarding blacklisting. You should set up SPF records for your domains
though, as it's pretty simply. I'm not sure that DKIM is worth the
effort at this point. The DK (which is different than DKIM)
implementation in QMT is slightly broken, and I think it's best simply
to disable that.
Throttling outbound messages is a great feature, and I intend to create
an enhancement ticket for this feature as soon as our new ticket system
is available (I'd do it on the old system, but I'd only have to re-do it
with the new system). I think this will be a great preventative measure.
That's all that comes to mind regarding QMT. There might be more on the
wiki - I'm not sure. If any of this isn't on the wiki, would someone
care to add it? Thanks.
I'm not familiar at all with Ironport. It might be a good idea to do a
little investigation into how one goes about getting delisted from that.
Also, check online blacklist checkers to see if you're still listed and
where, and contact those resources individually.
--
-Eric 'shubes'
---------------------------------------------------------------------------------
Qmailtoaster is sponsored by Vickers Consulting Group
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
If you need professional help with your setup, contact them today!
---------------------------------------------------------------------------------
Please visit qmailtoaster.com for the latest news, updates, and packages.
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
