Shelter In Computers
: Our Aim & Mission as a Organization to Promote Information
Technology , Cyber Secuirty , Entrepreneurship Education into Young Generation
, Teach , Train & Employee them in Eduction Sector , Banks & Different
Industries and Bulid them Future Leaders.
Email Server Security
1. Configure mail relay options carefully to avoid
being an Open Relay
Itís very important to configure your mail
relay parameter to be very
restrictive. All mail servers have this option, where you can specify which
domains or IP addresses your mail server¬ will relay mail¬ for. In other words,
this parameter specifies for whom your SMTP protocol should forward mail.
Misconfiguration of this option can harm you because spammers can use your mail
server (and network resources) as a gateway for spamming others, resulting in
your getting blacklisted.
2. Set up SMTP
authentication to control
SMTP Authentication forces the people who use your server to obtain permission
to send mail by first supplying a username and password. This helps to prevent
open relay and abuse of your server. If configured the right way, only known
accounts can use your servers SMTP to send email. This configuration is highly
recommended when your mail server has a routed IP address.
connections to protect your
server against DoS attacks
The number of connections to your SMTP server should be limited. These
parameters depend on the specifications of the server hardware (memory, NIC
bandwidth, CPU, etc.) and its nominal load per day. The main parameters used to
handle connection limits include: total number of connections, total number of
simultaneous connections, and maximum connection rate. To maintain optimal
values for these parameters may require refinement over time.
This could be very helpful to mitigate spam floods and DoS attacks that target
your network infrastructure.
4. Activate Reverse
DNS to block bogus senders
Most messaging systems use DNS lookups to verify the existence of the senders
email domain before accepting a message. A reverse lookup is also an interesting
option for fighting off bogus mail senders. Once Reverse DNS Lookup is
activated, your SMTP verifies that the senders IP address matches both the host
and domain names that were submitted by the SMTP client in the EHLO/HELO
This is very valuable for blocking messages that fail the address matching test.
5. Use DNSBL
servers to fight incoming
One of the most important configurations for protecting your email server is to
use DNS-based blacklists. Checking if the sender domain or IP is known by DNSBL
servers world-wide (e.g., Spamhaus, etc.), could cut down substantially the
amount of received spam. Activating this option and using a maximum number of
DNSBL servers will greatly reduce the impact of unsolicited incoming email.
DNSBL servers list all known spammers IPs and domains for this purpose.
SPF to prevent spoofed
Sender Policy Framework (SPF) is a method used to prevent spoofed sender
addresses. Nowadays, nearly all abusive email messages carry fake sender
addresses. The SPF check ensures that the sending MTA is allowed to send mail on
behalf of the senders domain name. When SPF is activated on your server, the
sending servers MX record (the DNS Mail Exchange record) is validated before
message transmission takes place.
SURBL to verify message
SURBL (Spam URI Real-time Block Lists) detects unwanted email based on invalid
or malicious links within a message. Having a SURBL filter helps to protect
users from malware and phishing attacks. At present, not all mail servers
support SURBL. But if your messaging server does support it, activating it will
increase your server security, as well as the security of your entire network
since more than 50% of Internet security threats come from email content.
local IP blacklists to block
Having a local IP blacklist on your email server is very important for
countering specific spammers who only target you. Maintenance of the list can
take resources and time, but it brings real added-value. The result is a speedy
and reliable way to stop unwanted Internet connections from bothering your
POP3 and IMAP authentication for
POP3 and IMAP connections were not originally built with safety in mind. As a
result, they are often used without strong authentication. This is a big
weakness since users passwords are transmitted in clear text through your mail
server, thus¬ making them easily accessible to hackers and people with malicious
intent. SSLTLS is the best known and easiest way to implement strong
authentication; it is widely used and considered reliable enough.
10. Have at least 2
MX records for failover
This is the last, but not least, important tip. Having a failover configuration
is very important for availability. Having one MX record is never adequate for
ensuring a continuous flow of mail to a given domain, which is why its
strongly recommended to set up at least 2 MXs for each domain. The first one is
set as the primary, and the secondary is used if the primary goes down for any
reason. This configuration is done on the DNS Zone level.
Securing SMTP mail servers
Mail servers are a front line security risk. This article shows you how to
minimise the risks of using SMTP.
Thereís no way we can live without e-mail these days. But anything that lets us
communicate freely to anyone, anywhere, must leave us wide open for security
problems. Here are a few areas to watch for when using SMTP in general, with
guidelines on how to minimise the risks.
Too much information?
Itís never a good idea to offer too much information to potential intruders.
SMTP banners typically provide the client with information on the version of
code running, which just gives a helping hand to anyone trying to access your
system illegally. Similarly the SMTP help command can provide this information,
so disable it if you can.
Commands which offer information on your users include VRFY, which returns a
positive or negative answer to the querier, depending on whether the e-mail
address exists on your system, and also provides the full user name and login
name. This can be used to test for valid user IDs; if the user has used a weak
password, access isnít too difficult from there.
Disabling the command helps prevent spoofing by not allowing someone outside
your network to check if a user id is valid. If you select this option, when the
SMTP server receives an SMTP VRFY request, it will return the message: 252
Cannot VRFY user, rather than an explicit yes or no to the userís existence.
Be aware that some systems still make use of this facility to legally perform
security checks on someone signing up for their services, however.
The EXPN command also provides more information that you might want to willingly
give out - it can be used to expand on a mailing list alias to provide the
individual e-mail addresses of everyone on that list.
Depending on the SMTP server you are using, you should be able to customize your
configuration here: for example sendmail allows you to enable VRFY and EXPN only
for users who have identified themselves, using the PrivacyOptions settings.
Validating incoming mail
If someone is trying to send you mail that will cause disruption, either
targeting your users or using your server as a pass-through point, they may try
to hide by not providing a source e-mail address. You should configure your mail
server to check that the user's mail address is specified in the MAIL FROM or
REPLY-TO line of any incoming mail messages; otherwise the message should be
discarded. In some systems there is a separate way to handle null addresses (<
>) in the MAIL FROM line by enabling or disabling a Refuse NULL < > Senders
You may also be able to check for large blocks of data which are sent outwith
the actual data phase of SMTP. Sending more than 512 characters in anything but
the SMTP DATA command will look like an attempt to hack in to your server and
should be blocked.
The SMTP kill file lets you specify a mail address or a particular mail host
that you do not want to accept mail from. You can edit this to restrict access
from hosts or domains; however this doesnít scale very well.
If you have e-mail aliases, you should also consider whether you want them
accessible to outside users or not. For instance, you probably donít want
customers sending technical support queries on your products direct to an
internal mailing list
Mail relay allows e-mail received by your e-mail server to be passed onto the
intended recipient even if that user is not registered on your server. While
this is often a necessary feature to have, to provide for scalability and
resilience, the problem occurs where malicious individuals send your server a
message to relay on to potentially hundreds of other users. This will at best
use up your serverís resources (especially if a large number of those addresses
are out of date, and your server then gets hit with numerous
message-sending-failed reports) and worse, get your server blacklisted since the
spam e-mails may look as if they came directly from your mail server.
So donít set your server to relay mail for just anyone. If you do need to have
relay enabled, your best option is to allow it for authenticated users only.
Authentication is done either via IP address or user id and password - your
users will need to select the "user authorisation" option in their mail client.
For instance in Outlook or Eudora, you must select "my server requires
authenticationĒ, although this wording will change slightly from client to
Be aware also that these capabilities vary from server to server. For example,
in Exchange 5.0, you could enable or disable relay and that was pretty much it.
It wasnít until 5.5 that the options to add in authentication, or to allow relay
only from pre-specified network address ranges were added.
Developed by Webmaster Abbas Shahid Baqir
Webmaster Feedback: [email protected]
Reserved Copyright, 2010-2020 Student Shelter In Computers