Mail at CIMS
- Desktop Computing
- Computer Labs
- Compute Servers
- Scanners, Copiers, Burning and Sending Faxes
- Classroom Facilities
- Frequently Asked Questions
- Email at Courant
- Accessing Your Email
- Reading and Sending Email in a Unix or Linux Terminal
- Accessing Your Courant Mail on the Web
- Downloading Email Using IMAP or POP
- Outgoing Email, SMTP and Mail Relaying
- Server Settings for using IMAP or POP, and SMTP
- Remote Mail Clients
- Forwarding Mail
- Automated Replies to Incoming Messages
- Web Interface for configuring Forwarding, Automated Replies and Filtering
- Mailling Lists
- Spam Filtering
The courant.nyu.edu (aka, cims.nyu.edu), cs.nyu.edu, and math.nyu.edu domains share a common mail gateway, through which all CIMS email passes, where each message is scanned for viruses and checked for the likelihood that it is spam before it is passed along to the mail server and spooled to disk. Because we use a common server for the various domains, all Courant users can receive email addressed to email@example.com, firstname.lastname@example.org, or email@example.com, as well as firstname.lastname@example.org. However, since each user is likely to be most closely affiliated with just one of these entities, one would advertise to colleagues the address that is most appropriate.
With the exception of cases in which people have identical names, each user is also given an alias of the form firstname.lastname at any of these domainnames. That is, for user John Doe, each of the addresses email@example.com, firstname.lastname@example.org, email@example.com, and firstname.lastname@example.org would be valid, and since these aliases are not case sensitive, John.Doe and JOHN.DOE would be valid as well. Mail to any of these addresses is all spooled to the individual's mail file on the on the mail server.
Your mail can be directly accessed by logging into one of Courant's Solaris or Linux systems using one of several mail reading programs on the command line. It can also be accessed from the web using our web interface, or from a remote computer, such as an office or home PC, Mac, or laptop, using either the POP (Post Office Protocol) or IMAP (Internet Message Access Protocol) protocol with a remote mail client. Mail can be sent using the same mail programs that are used to read it.
You can read and send email from a terminal window logged into one of the Unix servers, such as access.cims.nyu.edu, or by opening a shell terminal on a Solaris or Linux workstation. This has the advantage that you can access mail directly on the system, rather than connecting via IMAP or POP and transfering mail and headers to a remote computer. However, some disadvantages are that you cannot directly open all attachments, and many operations can be complicated, because they each rely on keyboard input of extensive lists of command strings, rather than simple mouse clicks in a GUI interface. Moreover, as software becomes increasingly GUI or browser driven, command line interfaces are a dying breed.
Of the following standard Unix mail readers, all except Mail can be used to open attachments, but they need to be configured to open them directly using the appropriate program, and this can be cumbersome in some cases. They can readily be used to save attachments as files, then one can view them using the appropriate software. All except Mail can also be configured to download mail via IMAP or POP and to route outgoing mail through a specific SMTP server. All have help facilities within the programs. You can click on the links below to read the Unix man pages here.
If you're having problems viewing emails formatted with European or French characters, you will need to reconfigure your settings to include European characters.
- Mail: The original Unix mail reading program. It is useful for those people who have been habitually using for many years, but is not recommended for users who are new to Unix, because the alternatives are better.
- pine: Probably the most user-friendly of the command line mail readers, it handles attachments well, is relatively easy to configure to taste, and has a reasonable help facility.
- mutt: A powerful mail interface, it is probably as good as any mail reading program in existence once one masters its use. However, it is complicated.
- elm: A predecessor to mutt, it is no longer supported by its creators and does not work well on Linux systems. Its use is not recommended. Those who have used it in the past are encouraged to use mutt instead.
You can access your Courant email from your web browser by logging in to our web interface at webmail.cims.nyu.edu using your Courant account. The system uses a customized version of SquirrelMail, a popular open source package. It has an on-line help facility, an interface for configuring spam filtering, a built-in calendar, and allows you to organize messages into folders. The system was upgraded in early 2010, and performance has improved significantly. Please read about the features of the new version.
While both IMAP and POP can be used to access your mail remotely, and are both supported here at Courant, IMAP is functionally superior to POP, and it is the recommended protocol for online mail access. One of the advantages of IMAP over POP is multiple folder support. With IMAP, you can create remote folders other than your INBOX and still be able to access them from any machine. POP mail clients can only create folders locally. For example, if you create a local mail folder on your work/school PC, you will not be able to access it from home if you use POP. IMAP is also optimized for online performance, such that an IMAP client does not have to download an entire message in order to display information about it and its attachments. In general, you should consider using POP to access your Courant email only if you always access your mail from the same machine, which is very unlikely these days, or if your mail client only supports POP.
Whether you use IMAP or POP, you should specify imap.cims.nyu.edu as the server. For security reasons, we only support IMAP and POP over SSL. This guarantees that your IMAP or POP session is encrypted, and your password is not sent in plain text. Make sure you specify server port 993 for IMAP over SSL or port 995 for POP3 over SSL when you configure your mail client.
SMTP (Simple Mail Transfer Protocol) is the common protocol for transferring mail over the Internet. Your mailer uses SMTP for sending messages. If your machine is inside Courant, you should specify smtp.cims.nyu.edu or smtp.cs.nyu.edu as the SMTP (or outgoing mail) server, depending on whether you want your sender address to appear as email@example.com or firstname.lastname@example.org, respectively. If you are at home, you can use either the SMTP server provided by your ISP, or one of Courant's SMTP servers. However, since we only allow mail relaying for our users, if you use one of the Courant SMTP servers for outgoing messages when you are outside of Courant, you must also configure your mailer to authenticate using your CIMS username and password. For security reasons, you should also specify TLS (or SSL if TLS is not an option) connection for SMTP in your mailer configuration if authentication is configured.
You can relay mail through our SMTP servers using the standard SMTP port (25) or the mail submissions port (587). Some ISPs block outgoing traffic to port 25. If you have trouble using our SMTP servers from home, you should try port 587 in the outgoing SMTP server setting.
Note for Outlook users: SMTP over TLS on port 587 may not work with Outlook. If your ISP blocks outgoing traffic to port 25 and you are using Outlook, then your ISP's SMTP server could be your only choice.
- Server: imap.cims.nyu.edu
- SSL: enabled
- Port: 993
- Server: imap.cims.nyu.edu
- SSL: enabled
- Port: 995
- Server: smtp.cims.nyu.edu or smtp.cs.nyu.edu
- TLS: enabled
- Port: 25 or 587
- Authentication is required if outside Courant.
For detailed instructions on how to configure your settings for a specific mail reader, or "client," please look here.
The address to which mail is delivered for a given user is based on email aliases maintained on the Courant mail gateway and in the directory service database that is queried each time a message is sent on a Unix or Linux system. You can use a
.forward file directly or use the the web interface described below to forward mail to an address outside of Courant. Using a
.forward file to reroute mail to another machine within the Courant network, however, will result in an alias loop due to the existence of your global alias, so this must be done carefully.
If you use the web interface, loops are checked for by the addition of an extra header.
To use your
.forward directly to forward all your mail to an outside address from your CIMS address, simply open the .forward file in your home directory. Modify the file so that it contains only the e-mail address to which you would like all of your mail forwarded. If you would like to forward mail to another address while retaining a copy of each message in your Courant account, you would create an entry as follows:
- \username, forwarding_address
To disable mail-forwarding, simply delete the file, or leave it completely blank. For more information on mail forwarding and mail aliases, please see the Unix man page.
If you would like to set up an automated response to all of your incoming mail, you can use the vacation program or use the web interface described below. This can be useful if you plan to go on vacation and will not be reading your mail, or at any time you want to generate an immediate response to each sender. If you decide to use the web interface described below, do not set this up directly by typing vacation at the command line. This will overwite your
.forward which is used to call procmail when the web interface is used to set things up. If you decide not to use the web interface, follow the manual instructions for running the vacation program (man vacation from the command line.)
The default length of time between auto-replies to each sender address is one week, so multiple messages from a given sender will not generate a new response to each message they send. However, it can be configured to respond more frequently, such as once per day, or to each message you receive. All incoming messages will be processed and delivered as they would under normal circumstances in which automated replies were not being generated.
If you use this Web Interface please be aware that it sets up your
.forward to call procmail. Your .forward should therefore not be used directly to set up Forwarding or Automated Replies (as described above), since it will be overwritten.
For the case where you use the web interface to forward mail, an X-Loop header is added to the forwarded mail. This header is used to detect mail loops, so if you forward to another account which also uses an X-Loop header to determine whether mail should be forwarded, the addition of this header will cause email at the other account not to be forwarded.
To access the web interface go to the Mail Configurator.
Mailing lists are used to send messages to multiple users who share a common need to receive certain messages, whether they are students in a class, researchers interested in a particular topic or series of talks, or administrators who need to be notified regarding University events. There are three types of mailing lists presently in use at Courant:
Software Managed Mailing Lists
These are used for class mailing lists, seminars, departmental lists, and other functions. They enable interested parties to subscribe and unsubscribe over the web, and provide list administrators with the ability to manage the lists and moderate messages posted to them. Requests to create such lists are limited to faculty and staff.
Static Mailing Lists
These fall into two types:
Those generated automatically. Inclusion on this type of list is based on the users home directory. However, it is possible to override this. Requests to be included or excluded should be sent to email@example.com
The use of these lists is restricted. Restrictions are based on message content and type of user and vary for the different lists. The Institute takes these restrictions very seriously. Disregarding them could lead to the suspension of your account. If in doubt please contact us for clarification.
Those maintained by a staff or faculty member. These are primarily used by administrative staff. Use of these lists is not open to the general community. Requests to set up such a list are limited to faculty and staff. Such requests are normally only made for lists that are repeatedly used and that contain over 20 users.
Personal Mailing Lists
These lists can be set up by any user at any time. They have the disadvantage of normally listing all recipients. However this limitation is easily circumvented by blind copying (Bcc) the list. These lists are normally defined in your
.mailrcfile. For information on how to set up such a list see the documentation pertaining to the mailer you are using. It is, of course, up to the owner of such a list to maintain it.
Short of locking down our mailservers to the point that they are either useless or impossible for legitimate users to use, there's not a lot we can do at the system level.
It's the nature of electronic mail, and it really is similar to regular mail in that you can send a letter to anyone for whom you have an address, and, furthermore, you can put any return address on that letter, even that of the recipient. A person can send mail to firstname.lastname@example.org and pretend that the message is coming from email@example.com. The one thing we can prevent is that person sending mail as firstname.lastname@example.org to places outside of NYU.
Greylisting is a spam fighting technique that temporarily rejects incoming mail in the hope that, unlike legitimate mailers, spammers will not try to resend. Technical information can be found greylisting website.
Effective August 31st, 2006, we made greylisting the default for all new users, and those whose accounts showed no recent activity. To avoid any disruption in correspondence, accounts which showed recent activity were not set to use greylisting by default. (If your mail is not being greylisted, we say your mail is being whitelisted). For all accounts that existed prior to August 31st, 2006, a file called
.greylist.cfg was created. If it exists, and has the line
in it, mail to you is not being greylisted. Otherwise, or if the file does not exist, mail to you is being greylisted.
For your convenience, incoming mail from any .edu, .gov, or .mil domain is not greylisted, and otherwise we use a dynamic whitelist that is updated daily, so over time many legitimate domains have become whitelisted, including most major ISPs and open mail services, such as yahoo and gmail.
In general, at the point most users probably do not have to make any customizations to their greylist configurations. However, inevitably there will be users who correspond with senders who use relatively obscure domains, making it desirable to use such customizations. To change your greylisting configuration, you can create and/or edit your
.greylist.cfg file to whitelist specific addresses. To whitelist everything coming from friendly.org, for example, you would use the line
in the file. To whitelist a particular address, put the line
You can have as many whitelist directives as you like, one per line. Similarly, you can have explicit greylist directives, also one per line.
When you have finished editing your
.greylist.cfg file, run
to update the global configuration. Your changes should take effect within about 5 minutes.
An example .greylist.cfg file:
# Below is a sample greylist configuration file. Lines begining with a # a '#' (hash) are considered a comment and are mearly for human consumption # lines begining with a hash will be ignored by our system. Uncommented lines # (lines without a #) will be used by our system for grey/white listing. # # Below we have several examples for greylisting setups. Please uncomment and # tailor to your needs. # # NOTE: THE FIRST RULE THAT MATCHES AN EMAIL WINS. ALL SUBSEQUENT RULES WILL # BE IGNORED. # # Please see # http://www.cims.nyu.edu/systems/resources/mail/index.html#Greylisting # for more details # # Short Instructions: # 1) Modify this file # 2) Save your file as .greylist.cfg in your home directory # 3) Run: greylist-update # ######## # HOWTO: whitelist/greylist specific email addresses # (Uncomment & modify to your liking) whitelist from email@example.com greylist from firstname.lastname@example.org ######## # HOWTO: whitelist/greylist mail from a specific domain # (Uncomment & modify to your liking) whitelist domain sometrusteddomain.org greylist domain somespammerdomain.org ### DEFAULT SETTINGS ### # The last rule in this file is your user default settings. # it should either be to whitelist all other mail or greylist all other # mail. CHOOSE ONLY ONE and leave the other commented out. greylist #whitelist