Welcome NetMail/3000 Customers
This is the fifth 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 +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) Selectively enable "blacklists" by mailbox 2) Fully configurable spam-filter "blacklists" 3) Full support for byte stream files and posix filenames 4) Specify "disposition" of files attached to messages 5) More miscellaneous enhancements
Spammers are constantly working to find new ways to deliver their junk mail into your
mailbox, and likewise several organizations are constantly working on new methods to keep
the unwanted "stuff" out. NetMail/3000 and DeskLink have had advanced filtering
capabilities for many years now, but recently we have significantly improved the
capability and flexibility of these features.
As of B.07 01/08/24 versions of NetMail/3000 you can now selectively activate the
"blacklist filtering" policy you setup (in the NetMail/3000 background job)
"per mailbox". The "Advertise Mailbox" attribute (configurable in the
Netmaint program in the MAIL-USERS screen) now has two new allowable values, for a total
of four:
"Y" - Advertise (i.e. allow SMTP based queries on this mailbox name) but do NOT
utilize any site-defined blacklists.
"N" - Don't advertise the mailbox and do NOT utilize any blacklists
"C" - Advertise the mailbox and DO utilize any site-defined blacklists
"H" - Don't advertise and DO utilize any site-defined blacklists
Note that the old default values were "Y" or "N" - so by default with
this update blacklists will NOT be enabled for your users unless you change their
"advertise" flag in netmaint. This was done intentionally since with any
blacklist there is the possibility of "false positives" where legitimate mail
can be refused, and we feel the mail system defaults should refuse as little
communications as possible. Keep in mind that the flags can be changed individually with
netmaint, or en masse using a tool like Query.
In the past few months, several of the common and popular Internet blacklist databases
have gone offline or been moved. Rather than constantly updating the hard-coded domain
names in our code, we have made all the services configurable via CIVars in the background
job. There are 5 possible services you can enable for your system, and you can now
redirect each of these 5 to any service you like. [We will provide some defaults in our
job stream, but for a list of other possibilities contact 3k/Entrix technical support, or
check out the network-abuse newsgroups, where updates and statistics on the various
services are posted from time to time.]
CIVariables are provided for both the domain name of the blacklist's DNS servers (Internet
blacklists work like DNS servers, returning positive results for lookups of hosts that are
identified as high-risk hosts) as well as a "contact" url - which will be
included in any error logs and error messages returned to senders of refused messages. For
example:
!setvar NETMAIL_ORCA_LIST ".or.orbl.org"
!setvar NETMAIL_ORCA_CONTACT "www.orbl.org"
!setvar NETMAIL_MAPS_LIST ".relays.ordb.org"
!setvar NETMAIL_MAPS_CONTACT "www.ordb.org"
!setvar NETMAIL_ORBS_LIST ".orbs.dorkslayers.com"
!setvar NETMAIL_ORBS_CONTACT "www.dorkslayers.com"
!setvar NETMAIL_IMRSS_LIST ".relays.mail-abuse.org"
!setvar NETMAIL_IMRSS_CONTACT "www.mail-abuse.org"
!setvar NETMAIL_DSSL_LIST ".dssl.imrss.org"
!setvar NETMAIL_DSSL_CONTACT "www.imrss.org"
The "names" in the variables (ORCA, MAPS, ORBS, etc) merely correspond to the
original/default names of the services. You can redefine each one to point to any other
service you choose (i.e. the ORCA list need not actually point to anything to do with the
old ORCA service).
Each "..._LIST" name is the domain name appended to DNS lookups in order to use
that service. Each value MUST begin with a period as in the example.
The "..._CONTACT" variables should contain a short URL, which will be recorded
in your log files when mail is refused, as well as returned as part of the error message
to senders whose mail is "bounced" -- hopefully helping to point legitimate
users to a resource where they can understand why people are refusing their email - and
get their servers fixed (and subsequently removed from the blacklist).
As of versions B.07 01/08/22 NetMail/3000 correctly parses and attaches MPE bytestream files. Also, when attaching a file from the 3000, NetMail/3000 will look for an MPE filecode (first) to assist in identifying the type of file (and how to encode/label it). If there is no filecode (i.e. "0") and the file was expressed as a posix (HFS) name, NetMail/3000 will also check the file extension (i.e. ./myfile.txt /SYS/PUB/Inventory.xls ) to assist in recognizing and labelling the attachment appropriately.
We have had requests from users to override NetMail/3000's default behavior when
attaching text files. By default, when we attach a text file to a mail message, the
attachment is "tagged" with a label called "inline" - which recommends
to the receiving mail system that the attachment be viewed as part of the standard
message. The alternative being having the user be prompted to launch a "helper"
application (word, notepad, etc) to "view" the attachment.
While in most cases this makes sense, there are cases where you may want to force the
behavior of recommending that the recipient view the attachment with a "helper".
Also, "inline" attachments cannot also provide "filenames" in the
label (at least several mailers have this limitation - including Microsoft Outlook), so if
you want to provide a filename with the text file you are attaching, the attachment needs
to be "labelled" by the mailer as an "attachment" (as opposed to an
"inline" portion).
In the past the only means of doing this was by setting a JCW (NETMAILTEXTATTACH=1) before
sending the message, which would force ALL text attachments to be labelled with a
recommended disposition of "attachment". This was an all-or-nothing prospect per
message, and some users requested that this attribute be selectable by individual
attachment.
As of version B.07 01/08/23 when using NetMail/3000 in command mode (or in batch jobs)
when prompted for a filename to attach, you can now add a ";ATTACH" or
";ATT" to the filename. This tells NetMail/3000 to attach the label
"disposition: attachment" to the attachment when it goes out, as well as
supplying the filename you gave it. [Note that MPE filenames will get a ".txt"
appended to their names in the mail message, to make it easier for the receiving mail
system - some of which pay more attention to filename extensions that encoding labels - to
display the message.]
As of B.07 99/06/02 NetMail/3000 and DeskLink installations routing their outbound
email through another server have two additional configuration options for routing these
messages.
The "trusted gateway" routing option in the globals option of the netmaint
program now accepts two new options for routing mail without adding the
old-style/traditional "source routing" information to the address. Source routes
look like "@relayhost.domain.org:finaluser@acme.com" - with the relay host's
name being prepended to the outbound email address. While this was the accepted (and
standards defined method) of routing mail through "relay servers" in the past,
some new mail systems do not properly parse or handle these address formats correctly -
including some Microsoft Exchange servers.
So, If you do encounter problems with mail routing through a "trusted gateway"
from your NetMail/3000 system because of the remote server not "liking"
addresses in this format, you have two new options that you can select in the netmail
globals screen:
"R" - same as "Y" but does NOT source-route outbound addresses
"A" - same as "F" but does NOT source-route outbound addresses
As of B.07 00/03/21 NetMail/3000 understands and utilizes the "Importance:
high" headers that Microsoft Exchange generates.
As of B.07 99/12/20 a new JCW was added "THROTTLEPOP" to combat high cpu and
network utilization caused by POP clients on a local network downloading and sending very
large messages. Since a local pop client can access the 3000 at close to the full speed of
the 3000's lan card, and it isn't uncommon for POP mail clients to attach or send very
large attachments, it wasn't difficult for a pop client to completely dominate the cpu and
network interface of a 3000 by downloading multi megabyte files from the 3000 to their
PC. Since these connections are highly efficient and the NetMail/3000 background processes
typically operate in the CS queue (to provide good response time to these interactive-type
processes) several users doing this couple effectively "lock out" all other
processes on the 3000. To combat this, a "throttle" option was created in
NetMail/3000, causing a short "pause" to be invoked after every few
"packets" of data once the user has exceeded 1Mb of data being downloaded. From
that point on, these pauses would allow other processes to utilize the system, while only
moderately slowing down what is a very large download anyway for the pop client.
To enable this feature,
:SETJCW THROTTLEPOP=n
where 'n' is the delay desired (per packet) in tenths of a second. I.e. for a 1 second
delay per packet, :setjcw throttlepop=10