How to find OS architecture

* To find the System (hardware) architecture

$uname -a
will display something link this below.

Linux gisnas.corp.com 2.6.18-8.el5 #1 SMP Fri Jan 26 14:15:21 EST 2007 i686 i686 i386 GNU/Linux

From the end you can see "i686 i686 i386 GNU/Linux" which is the hardware architecture representation.


* To find the OS (operating system) architecture.

$getconf WORD_BIT or $getconf LONG_BIT

32

Both these command will display the loaded OS architecture.

Tips to Secure Email Server

1. Open Relay:

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. SMTP authentication:

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 server’s SMTP to send email. This configuration is highly recommended when your mail server has a routed IP address.

3. Limit connections:

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. Reverse DNS:

Activate Reverse DNS to block bogus senders
Most messaging systems use DNS lookups to verify the existence of the sender’s 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 sender’s 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. DNSBL servers:

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:

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 sender’s domain name. When SPF is activated on your server, the sending server’s MX record (the DNS Mail Exchange record) is validated before message transmission takes place.

7. Enable SURBL

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:

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
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. SSL\TLS is the best known and easiest way to implement strong authentication; it is widely used and considered reliable enough.
10. MX records:

Have at least 2 MX (Mail eXchange) 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 it’s 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.

To check TLS

Command to get information about TLS communication for a recipient system

$openssl s_client  -starttls smtp -crlf -connect alt1.gmail-smtp-in.l.google.com:25

Sample Session details:

SMTP reply codes based on the SMTP commands

SMTP reply codes based on the SMTP commands


The following list groups the SMTP reply codes by the SMTP commands with which they can be associated. This can help you identify at what point the process failed.

HELO

250, 421, 500, 501, 504, 521

EHLO

250, 421, 500, 501, 504, 521

MAIL

250, 421, 451, 452, 500, 501, 552

RCPT

250, 251, 421, 450, 451, 452, 500, 501, 503, 521, 550, 551, 552, 553

DATA

354, 421, 451, 500, 501, 503, 554

SEND

250, 421, 451, 452, 500, 501, 502, 552

SOML

250, 421, 451, 452, 500, 501, 502, 552

SAML

250, 421, 451, 452, 500, 501, 502, 552

RSET

200, 250, 421, 500, 501, 504

VRFY

250, 251, 421, 500, 501, 502, 504, 550, 551, 553

EXPN

250, 421, 500, 501, 502, 504, 550

HELP

211, 214, 421, 500, 501, 502, 504

NOOP

200, 250, 421, 500

QUIT

221, 500

TURN

250, 500, 502, 503

SMTP Error Code

Question: How can I tell why an inbound or outbound message bounced, based on the SMTP reply code?

Solution:

If your inbound messages are bouncing back to the senders, have them inspect the bounced messages for SMTP reply codes generated by the message security service (see below). If the bounced messages contain codes generated by the message security service, then the message security service is at fault, and you can use those codes as a starting point for troubleshooting the cause of the messages not getting through.

If your outbound messages are bouncing, inspect them for the same system-generated codes, and apply the same troubleshooting principles.

In cases where the problem lies with your message security service, consult the Message Security Administration Guide.

If the bounced messages contain SMTP reply codes that were not generated by the message security service, then there is likely a problem with the sender’s or recipient’s mail server, or with the way the message was addressed. SMTP reply codes outside the scope of the message security service are also designed to aid in troubleshooting message delivery problems.

How to avoid sudo password

How to avoid sudo password

When you are logged in as a user other then root and execute a privileged action or action related to privileged resource using "sudo" command, then a "sudo" password is requested .

You face two challenges mainly during this act:

* During a system or configuration setup you can see frequently system is prompting for "sudo" password

* Also you need to execute the command with the full path name.

To overcome this you can login as the "sudo" user and execute the below command.

$ sudo bash

This command will ensure the running shell is supplied with sudo credential, so it won't bother you asking for credential again.

Enjoy Configuring!!!!!!!!

Email Standard.

Email Standard. 

I am trying to put them in writing below.

An Ideal Email ID should have 3 parts in representation, eg. User1@gmail.com

1.       Domain name (gmail.com)

2.       “@” symbol

3.       Valid user in the system (User1)

Always Email ID will be read from back to front, that is the domain name will be read first in the Email ID then everything else.  After Domain name ‘@’ symbol is expected and finally Username will be considered.

When I try to send an email from my machine using telnet session on 25 port, as below.

Date: Fri, 20 Jan 2012 15:23:43 +0530

From: User1@test.com

Message-Id: <201201200953.q0K9rhlj004368@Local.com>

To: Test-user@example.com

Subject: subject

Return-Path: <User1@test.com>

Received: from Local.com ([10.30.117.97])

        by mail.local.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0K9s3DZ012502

        for <Test-user@example.com>; Fri, 20 Jan 2012 04:54:04 -0500

Received: from Local.com (localhost.localdomain [127.0.0.1])

        by Local.com (8.13.8/8.13.8) with ESMTP id q0K9rhv2004369

        for <Test-user@example.com>; Fri, 20 Jan 2012 15:23:43 +0530

Received: (from root@localhost)

        by Local.com (8.13.8/8.13.8/Submit) id q0K9rhlj004368

        for Test-user@example.com; Fri, 20 Jan 2012 15:23:43 +0530

The above example of email header info is modified to make it simple. When you read this header info which is generally analyzed by the email spam scanner you can find few odd things. Like the email says it’s from User1@example.com and the return path also reflect it, but in the header you can see that email is from root@localhost (in your case it will be logged in user wit ‘@’ and machine FQDN) by Local.com (machine name). Also you see the ‘from’ domain is test.com, but the origin machine or the source IP address is a different domain Local.com.

Here you see two odd stuff one the ‘from’ email address and the other is the Domain.

This above contradiction in email header info is what always suspected as spam.

 .

Many relay system or email servers are restricted relay and only few where open relay system.So when you send a email of this contradiction then your IP address would be blocked by the spam database.

When you try sending an email best practice is that create a email ID with your email system and have them as the envelope sender as well as return path of the email.

mail command with specific recipient

Mail command can be used to send email from any UNIX or Linux system to other system. Basically they are command based email program to send email.

mail -s "Subject" name@example.com

To send the email with particular sender email ID then use the below syntax.

mail -s "Subject" name@example.com -- -r "user1@example.com"

Why it becomes very particular to send with an email ID because when you use a mail program it assumes that the logged in user as the sender from the base(current  working) machine. These type of emails are generally rejected on the basis of doubt for spam.

So i recommend a particular email ID for sender which will ensure the safe journey of email.

Body with file redirection:

To send email with data from a file or a source you can always redirect the information to the mail command.

 mail -s "Subject for test" name@example.com -- -r "user1@example.com" </etc/mail/sendmail.cf

The email from user1@example.com to name@example.com will have a subject as 'Subject for test' and carry the data from the sendmail.cf file.