|
mail server testing notes |
| Note:we now only create home directories on the mail server
for new accounts for "department members" - aka - those who will be
included on the everyone@phas email list. Here's a code snippet from addusr:
# Set up files on mail server (for "everyone" only)
This therefore WILL NOT include the following categories of users: Ugrad, Visitor, System, Misc If a Ugrad or Visitor needs/want to have an email account you just need to log onto the mail server and run the following command: /opt/sysadmin/passwd/make_mailhome <username>
Assuming that the username has already been propagated to the mail server /etc/passwd file. |
Testing SendmailUsing telnet
|
To make sure your sendmail binary is compiled with Milter support just run :You can display class w entries with the following command: echo '$=w' | sendmail -bt -d0.4By default, class w contains localhost, the IP address 127.0.0.1, and the system's IP address(es), fully qualified domain names, and short hostnames. Entries placed in /etc/mail/local-host-names or /etc/mail/sendmail.cw are added to these default values. |
Testing SMTP AUTH connectionshttp://qmail.jms1.net/test-auth.shtml When setting up a mail server, one of the things you should do before you "go live" is to test it- not only to make sure things which should work, do work, but to make sure things which shouldn't work, don't. One of the things to test is whether or not your server correctly supports the AUTH command. This command is used when a remote client wishes to identify themself as an "authenticated" user, normally so that they can use your server as an outbound mail relay. This is very handy for companies with employees who travel, or for ISPs with clients who travel. Find your authentication informationIn order to use the AUTH command, you need to know the base64-encoded version of the userid and password you will be using to authenticate to the server. Normally this would be the same as the userid and password you would use to check your mail using IMAP or POP3. This perl command (which requires the MIME::Base64 module) will do the encoding for you:
% perl -MMIME::Base64 -e 'print
encode_base64("\000jms1\@jms1.net\000not.my.real.password")'
Note: Make sure to use
\0 both as the first character of what you're
encoding, and as the separator between the userid and the password.
There was an error with the original version of these directions- I had
forgotten about needing a \0 at the beginning.
Sorry
all!
Another reader pointed out that perl silently interprets the "@" sign in the middle of a string and replaces it with the contents of an array with that name, if one exists... or with nothing, if not. I just did a full two-way test with my real password, and it turns out if you don't put a backslash in front of the "@" sign it won't work. Good call. And JT Justman pointed out that if you use \0
as the
separator, and the userid or password happens to start with a digit,
perl will try to find and use a three-digit octal character code
instead
of a one-digit null byte with two normal digits behind it. Using
\000 instead of just \0
prevents
this from happening.
Connecting to the serverDepending on how the server is configured, you may need to use SSL or TLS before you are able to use the AUTH command. In fact, if you are able to use the AUTH command without using either SSL or TLS, you are in fact sending your userid and password over the internet in clear text. Anybody with a packet sniffer in the right spot will be able to read the base64-encoded string you send to authenticate, and it's really easy to decode that stuff- in fact the same command above will work if you change "encode_base64" to "decode_base64" (and put the encoded string between the double quotes, obviously.)
Make sure the server supports AUTHWhen you first connect to an SSL or TLS server, you will see the key-exchange information fly by on the screen, and the last line you see when it stops scrolling text will be the server's "banner" message, which tells the client that the server is ready to accept commands. For a non-secured connection, the first thing you see will be the banner. When the banner is received, a normal SMTP client would send an EHLO command to the server in order to identify the client machine, as well as ask for a list of the capabilities supported by the server. If you are using an openssl command to connect to an SSL or TLS server, make sure to enter your SMTP commands in lowercase as shown here. The openssl "s_client" command watches what you type- if you send a line of text starting with a capital "R", it will re-key the SSL layer instead of sending your command to the server... and if you send a line of text which starts with a capital "Q", it will terminate the SSL connection and exit.
220 a.mx.jms1.net NO UCE ESMTP Look at the response from your EHLO command, make sure AUTH is on the list, and that PLAIN is one of the options it supports. If it's not listed, the server will not let you send an AUTH command. This may be because the connection is not secured and the server is protecting you from sending your authentication information across the net in plain text... Sending the AUTH commandAssuming the server supports AUTH, we will send the actual AUTH command to try and authenticate.
AUTH PLAIN AGptczFAam1zMS5uZXQAbm90Lm15LnJlYWwucGFzc3dvcmQ= If you see this message, you are authenticated. If you see this one instead...
AUTH PLAIN AGptczFAam1zMS5uZXQAbm90Lm15LnJlYWwucGFzc3dvcmQ= ... then obviously it means you are not authenticated. If you were not able to authenticate, you can try another AUTH PLAIN command- although if the server is logging the traffic or running an intrusion detection system, having multiple AUTH commands in a single SMTP session is enough to raise a red flag. Be careful not to ban your test client's IP address. Sending the messageOnce you are authenticated, you may continue with a normal SMTP conversation and the server should accept any message from you, whether you are relaying to an outside domain or not. Even if you don't authenticate, the server will still accept messages from you- it just won't relay (it will act the same as if you had never entered an AUTH command at all.)
mail from: <nospam@jms1.net> |
| Testing IMAPD |
IMAPD Testing
[root@mail root]# telnet localhost 143 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. * OK [CAPABILITY IMAP4REV1 LOGIN-REFERRALS STARTTLS AUTH=LOGIN] localhost.localdomain IMAP4rev1 2003.338rh at Thu, 27 Sep 2007 14:34:47 -0700 (PDT) A01 CAPABILITY * CAPABILITY IMAP4REV1 IDLE NAMESPACE MAILBOX-REFERRALS BINARY UNSELECT SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND LOGIN-REFERRALS STARTTLS AUTH=LOGIN A01 OK CAPABILITY completed A02 LOGOUT * BYE mail.phas.ubc.ca IMAP4rev1 server terminating connection A02 OK LOGOUT completed Connection closed by foreign host. |