Student Shelter In Computers
Slogan : 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 user access

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.

3. Limit 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 command.

This is very valuable for blocking messages that fail the address matching test.

5. Use DNSBL servers to fight incoming email abuse

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.

6. Activate SPF to prevent spoofed sources

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.

7. Enable SURBL to verify message content

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.

8. Maintain local IP blacklists to block spammers

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 messaging system.

9. Encrypt POP3 and IMAP authentication for privacy concerns

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 option.

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
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 client.

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.