Welcome NetMail/3000 Customers
This is the fourth e-mail newsletter sent to our NetMail/3000 customers; it is intended to let those of you with support contracts know about new and planned features of NetMail/3000, along with a few tips on ways you can use the system you have which you may not be aware of.
Those of you with Internet e-mail addresses should receive this by e-mail, others will receive it via fax. If you get a fax but have an Internet e-mail address you would prefer us to use, please let us know. Those of you who do not want to receive any more notices (these are intended to highlight features you have already paid for; not merely plugs for additional products) may let us know and we will remove you from the distribution list. Note that we will also use this list to make you aware of important problems or bug reports if applicable, so I urge you to have someone at your site at least review these messages. Also - anyone who would like us to add other mailboxes to our distribution (others at your site that might be interested) you may also let us know.
Finally, if you have questions about NetMail/3000 or any other 3k Associates product (DeskLink, PopServer, Gopher Server, Ftp Server, Fax Server) feel free to give us a call at +44 1480 492400 or e-mail us at sales@3kassociates.com or support@3kassociates.com.
Now that we're done with that...
In this issue:
1) "Vacation" (while I'm away) messages from NetMail/3000 2) "The ultimate spam-relay protection" Feature 3) Pop server now supports encrypted passwords (APOP)
To most mail systems, this function is known as a "vacation" message; an
automated process that replies to all incoming messages with a short fixed message stating
that the intended recipient is not able to view the message received - that he/she is out
of the office/on vacation/etc.
While some (POP) mail clients have this capability as well, NetMail users can setup this
function at the server level (the big difference being, if your POP client processes your
replies and you're not in the office - chances are you didn't leave your POP client
running the whole time you're gone either).
Some systems simply bounce back a message in response to every message received. If any of
you are on mailing lists, you probably remember some of these people (and likely not
fondly). Auto-responders that bounce a message back to EVERY message they receive are
irresponsible as they often cause mailing loops on mailing lists, and at best are terribly
annoying to other list members that get messages back for every single message sent to the
list. NetMail/3000 has a simple and effective solution to this problem; our vacation
responder keeps a list of every address it has already responded to, and ensures that it
sends one and ONLY one message to each address, no matter how many incoming messages are
received. Further, since NetMail's vacation responder is linked to a message filter
(rule), you can specify your rule(s) such that only certain types of messages get
responded to. By intercepting mailing lists before your "vacation" rule ever
gets "hit", you can easily prevent a vacation message from being broadcast to
the lists you are on. And since rules can be based on any header (from/to/cc/subject/etc)
as well as on any text within the message itself, you can easily customize your responses
with separate vacation rules/messages for different types of messages
(business/personal/inquiries/etc).
NetMail/3000's vacation function is implemented as an "action" linked to a
message "rule" or filter. NetMail users create a rule as usual, selecting as the
action "reply" and entering special filenames in the parameter field.
These (two) filenames are:
message file,history file
**NetMail/3000 "rules" are only available to mailboxes which the administrative
user has flagged as being allowed "extended capabilities" in Netmaint. This is
due to the fact that message rules (and the forwarding capability also allowed with
extended capabilities) have the potential to cause headaches for the mail administrator if
misused, and therefore should only be granted to users with some training in the proper
use of these capabilities.
Important notes about these two files;
The "message file" must be an MPE 80 byte (fixed ascii) file on the HP3000
somewhere so that the "SERVER.THREEK" (or SERVER3K.HPOFFICE as appropriate) user
has at least *READ* access to it. Further, the first line of this file is used as the
subject of the message which goes back to the sender. You can use any text you want
(limited to about 70 characters), and can even have NetMail
"substitute" the value of the subject of the incoming message by including a
"^" (quotes not required) character in the string somewhere. All lines following
the first line become the body of the message. For example:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I got your message '~'!!!
But I'm temporarily our of the office. I will read it when I get back, but
if you're in a hurry, you can send your message to my boss in the meantime.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Next, the history file must be readable AND writable by the SERVER.THREEK (or
SERVER3K.HPOFFICE for HPDesk users) logon. The vacation process will append every address
it has responded to onto this file. [You will probably want to purge/create a new file for
each time you go on "vacation"]. If you don't create the file, it will be built
for you **if the background job can create the file in that group/account (not likely if
it is in a different account as the background job does NOT have SM capability). If you
don't specify the group or account name of the file, they will default to the netmail
group of the account the background job runs in (either THREEK or
HPOFFICE depending on whether you also have DeskLink).
As a simple example, a rule that will generate vacation responses to every message it is
executed for:
++Edit Message Rules++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+
+ IF FROM <> Y (Case Sensitive?)
+ ***
+ THEN REPLY USING (PARAMETER)
+ myvac.user.acct1,myhist.user.acct1
+
+ Y Stop further rule processing if result is true?
+
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
This says, for any message whose From: header is not "***" (which will be true
in all cases) then REPLY using the myvac.user.acct1 (message) and the myhist.user.acct1
(history file).
As active members of the "SPAM-L" anti-spam mailing list (mostly frequented
by ISPs) and a frequent target of spammers, we see evidence of a dozen systems a week that
have been victimized by relay-spammers. Relay spam is a means of cost shifting (aka
resource theft) where a spammer, often from a throwaway dialup account, locates an
unsecured mail server which will deliver their trash mail for them. By connecting directly
to this server and submitting tens of thousands of messages to recipients all over the
world, the
spammer is able to quickly dispense his trash and move on, leaving the victim's mail
server to deal with final delivery of the tens of thousands of messages, and even worse,
the thousands of undeliverable messages, and all too frequently mail bombs, mass
complaints, and other attacks from the angry recipients of the spam.
These attacks can be devastating (and expensive) for their victims.
The obvious (brute force) solution is to configure your mail server to not
"relay" any messages. ["relay" means to accept a message from another
machine which is destined for a mailbox on a third party's machine; a feature that was
intentionally designed *into* all SMTP servers from the earliest days of the Internet.
This was a critical component back in the days when networks and the Internet itself were
less reliable and quick and e-mail often needed to go through obscure paths to get to it's
final destination.]
The problem with simply turning off any relaying is that there are still two valid cases
when you need to allow it;
1) If you have another mail server - perhaps behind a firewall - that needs to route mail
through your server to get to certain locations - like the Internet
2) All POP clients require a "smart" SMTP mail server to relay their outbound
mail for them. If you have *any* POP clients, your server needs to relay their mail (or
they won't be able to send any outbound e-mail)
A few months ago, some clever anti-spam activists came up with a process which has been
called "pop before send" or "read before send", which we have now
adopted to the NetMail/3000 (and Pop Server/3000) products. Simply put, this feature (if
enabled) prevents ANY relayed mail message EXCEPT:
* You can build a file called "relay.netmail" which lists permanently allowed IP
addresses of hosts you will allow to relay mail through your server
and
* Whenever a POP client "checks" their mail, the server records the IP address
the user is on and saves it for a number of hours (configurable) and for that period of
time, the server will allow mail to be relayed by that computer
Anyone else attempting to relay mail through your server will get an error message for
every relayed-recipient, the mail itself will never enter your system, and an error
message will be logged to the errorlog file, the system console, and via an
"urgent" mail message to the system administrator.
The caveat here is that if a POP user coming in via a remote connection and immediately
tries to "send" a message (before checking their mail) they may also get the
error message, which says:
"This site does not 'relay'. POP users must check-mail before sending"
So, inform POP users that they should always check their mail before trying to send a
message [or for users with permanent fixed IP addresses, put their address in the
'relay.netmail' file.]
The JCW in the NetMail job that controls this feature is "RELAYPOP" and is set
to 0 (zero) for disabled, or a number (of hours to 'remember' addresses).
The "relay.netmail" file is a plain ascii file, in the account your background
job runs under (i.e. THREEK or HPOFFICE) and has one IP address per line, using 3-digit
numbers (i.e. 192.001.002.003) followed by any comments. You can also use the digit '255'
in any position as a wildcard (i.e. 140.001.255.255 will match any address starting with
140.001).
You need POP3SERV.SYS.THREEK version B.07 98/07/13 or later and SMTPSERV.SYS.THREEK
version B.07 98/06/25 or later to use the relaypop feature.
When a POP client connects to a POP server to check/retrieve mail, it logs on by
sending packets containing the mailbox name and the mailbox password. These packets are
sent in "clear text" (i.e. not encrypted) over the network. While this is not a
big deal for most sites, users coming in via WANs or via the Internet or in large open
networks (like universities) may be reasonably concerned that someone with the software or
hardware to monitor network "traffic" could see this information, and in turn
compromise someone's mail
box.
Recently a new enhancement to the POP standard was approved called "APOP". This
authentication method is widely available in most POP clients today (usually under the
setup configuration info). This method uses a secure "hash" (one-way encryption)
scheme to validate mailbox passwords, meaning that clients using "APOP" as their
authentication method will not transmit their mailbox passwords over the network.
Detection by the server is automatic, so clients can continue using the normal
"password" method or choose the "APOP" method as the choose. (Since
the additional overhead is trivial, you might want to recommend to users that they select
"APOP" if their client supports it).