Setting up Janet Mailer Shield

Download as PDFDownload as PDF
  • Inbound relay
    • What you need to do
    • What Janet will do
  • Outbound relay
    • What you need to do
    • What Janet will do
  • Additional features

Inbound relay

You can arrange for all legitimate mail arriving at your network from Janet and the rest of the Internet to pass first through a relay of the Janet Mailer Shield service. The relay will only pass to you mail for addresses in your own domain or domains. You will find this helpful if your own mailer is not able to identify and reject mail for other domains correctly.

Your mail system then needs only to accept connections from your own network and from the service relays. You should enforce this policy at your router or firewall, and so far as is practicable at the mail system itself. There may be specific local reasons to allow certain other connections, for instance:

  • you may have an agreement with another trusted mail sender
  • you may wish to allow some of your staff to send messages out through your mail system using their e-mail addresses in your domain, while connected from home or elsewhere through a dialup or other service provider.

In such circumstances you will need to make very careful arrangements to ensure that your mail service is secure. Access from ISP accounts is difficult to arrange securely. In particular you MUST NOT leave your mail system open to connections from the whole of the Internet.

Unwanted connection attempts may come to any IP address in your allocated range, at the following TCP ports:

  • port 25, the usual mail port
  • port 587, assigned for mail submission
    (certain mailer products may accept messages to the SUBMIT port without applying the same authorisation requirements as for port 25)
  • port 1080, SOCKS proxy service
    (proxy servers can help to simplify your provision of web browsing facilities within your organisation, but if not carefully configured they may allow unauthorised connections to your mail server).

If you operate a web proxy or cache (normally listening on port 80, port 3128 or port 8080) then you must check that it is not possible to connect to your mail system through the proxy.

It is good practice to maintain secure configuration of all your computers, whether or not you intend them to act as mail or other servers. It is also good practice to configure your router so that all connections to your network are rejected except those you specifically allow to identified and managed servers. This may also give you protection when you add to your network a new system whose software is not yet fully configured.

The Janet relays are able to identify certain patterns of bulk mail behaviour and other abuse, and reject transfers. For example, messages with contrived addresses intended to abuse your mail system for unauthorised relaying will be rejected. On the other hand, the relays will accept all messages with recipient addresses that are correctly formed and are in your domains, and will attempt to transfer them to you. The Janet relays do not know what local addresses are valid. It is up to your mail server to reject invalid addresses in the usual way.

What you need to do

This example is intended to illustrate what is required. Your situation may be more complicated; if you are not sure how to relate your own needs to the example you should contact the Janet Service Desk and ask for the service operator to discuss them with you. is the (fictitious) domain name for your organisation. The IP addresses here are also fictitious (indeed, they are deliberately chosen to be invalid!).

Adjust your DNS records

This set-up is a preferred option, erring on the side of caution for less experienced local mail managers. If you consider one of the other options listed in Inbound Relay Arrangements is more appropriate in your case, discuss it with the service operator.

Essentially, you simply add the Janet Mailer Shield service to your list of MX records for any domains at your site to which e-mail may be sent. The value of the MX record MUST be greater than that of all your local e-mail servers. In the following examples for the imaginary domain, it is supposed that the server has the domain name mail* If you have two local e-mail servers with MX records with values 3 and 7 as below: IN MX 3 IN MX 7

the third MX record MUST then be set up with an MX value greater than 7, e.g., IN MX 13

In the above MX record the value ‘MX 13’ is arbitrary but you should discuss the matter with the Janet relay managers in order to select an appropriate value. Once this is in place you mustconfigure your router or firewall to reject all in-bound e-mail connections from everywhere except trusted services.

It is important that you reject the connection if possible, rather than simply dropping it, as a rejection tells the remote server to give up on that particular MX record and try the next best MX record, whilst dropping the connection means the remote server will continue to try for up to 5 minutes before giving up and trying the next one. The list of Janet servers in use by the Janet Mailer Shield service will be provided when you are registered, and any subsequent updates will be announced on the Janet Mailer Shield service contact mailing list.

This method means your e-mail server is still being announced to the world, therefore a mail system anywhere in the Internet having a message for your domain will first try your servers, but due to your local Internet block on port 25, will fall back to the Janet Mailer Shield service. This will cause a variable delay in e-mail. It can take the remote site up to 5 minutes, depending on their configuration, to give up on the first MX record and move on to the next.

It is highly desirable that there is a PoinTeR (PTR) record associating the name and the address of the mail server in the other (reverse) direction. Note that this will be in a different zone database as indicated by the $ORIGIN directive here


It is possible that the nameserver for the reverse zone is not your own and you will have to make arrangements with some local or regional support centre to have the PTR record put in place.

Configure your mail server

Your mailer MUST ACCEPT e-mail connections (SMTP, to TCP port 25) from the JMS relays in your MX records. It SHOULD REJECT connections from all other IP addresses outside your own network. If you cannot configure it to do so, your firewall or router MUST block them instead (see below).

It MAY accept connections from e-mail clients in your own network to send mail out, if your e-mail programs need that facility. Ensuring secure operation is then more difficult and is discussed in the section on ‘Outbound relay’.

Your mailer SHOULD reject messages for invalid mail addresses in your own domain or domains during the RCPT TO: phase of the SMTP protocol (leaving the JMS relay to decide whether or not to send a non-delivery report) rather than accepting them and then attempting to send its own non-delivery reports.

Your mailer SHOULD also reject messages from the JMS relays that are not for your own domain or domains (although the relays will never offer it any such messages).

Configure your router or firewall

The aim is to make the path from the JMS relays to your own mail server the only route by which e-mail enters your network.

The starting point (default behaviour) is that the router or firewall will reject connections from addresses outside your network to TCP port 25 at all addresses inside (the default behaviour for all other ports is beyond the scope of this note but should be fairly restrictive).

You must then allow TCP connections from the IP address of each JMS relay (and from no other outside addresses) to port 25 at the IP address of your server.

Whether or not any internal addresses are allowed to reach port 25 of the mail server depends on your arrangements for outgoing e-mail, discussed separately.

Monitor your mail

Check at regular intervals (no less often than once a day) that messages are entering and leaving your network. You may be able to extract statistics from your mail server and automatically e-mail them to a technician who can take action if the figures are in any way unusual.

You may also find the ‘echo‘ facility described in the section ‘Additional Features’ useful for service monitoring.

What Janet will do

The relay managers will configure the service relays to:

  • accept messages from the Internet for addresses in your domain
  • attempt to transfer your messages to the server you specify when you apply to use the service
  • store your messages for up to four days if your own server is temporarily unavailable, making further transfer attempts at intervals
  • return to the apparent sender any messages that cannot be delivered to you within the four days, with an indication that they were undeliverable.
  • attempt to return to the apparent sender messages which your own server does not accept.

Once a message is transferred or returned, no copies of it are retained at the Janet relay.

Outbound relay

You can arrange to relay all mail from your network for Janet and the rest of the Internet through the Janet Mailer Shield service. This is not available as a routine service but may be useful in an emergency:

  • if your site mailer is not able to look up the proper destination to connect to in the DNS
  • while your own mailer is blacklisted somewhere following a relaying or other abuse incident
  • to suppress certain messages which your server should not be sending (e.g. the results of virus software or unauthorised relaying).

The outbound relay service is only available to Janet organisations that already use the inbound service, and as a special arrangement. To use this facility, telephone the Janet Operations Desk (0870 850 6672).

It is crucial that the service does not send out on your behalf messages that will be perceived by their recipients as abuse; actual or perceived abuse could make the outbound service unavailable to other Janet organisations for some time. Unauthorised relaying and e-mail from virus programs are the most probable routes for abuse, and precautions against them are discussed in References. If it appears that your organisation is the source of such abuse, your use of the outbound service will be suspended immediately, and before any attempt is made to contact your organisation. You will be unable to send any e-mail.

What you need to do

In advance

It will only be practicable for you to use the outbound service if your e-mail clients and servers are sensibly set up beforehand, following the guidance in References.

If an emergency arises

In consultation with the Janet Mailer Shield managers, configure your mail server to send all outgoing messages through a JMS relay rather than attempting to connect directly to other Internet addresses. Typically you will need to specify that the JMS system is a ‘smart host’ or ‘relay’.

What Janet will do

Arrange for the Janet relay to accept mail from you for all Janet and Internet addresses and to attempt to transfer it to its destination. When delivery fails for any reason, messages will be returned to the address from which they were sent. If the originator address is invalid at that time, the message will be lost without warning.

Additional features

Added header lines

On request, the relays of the Janet Mailer Shield service will add the following additional lines to the header of each message, indicating a number of things which may indicate that the message is spam or otherwise constitutes e-mail abuse.

Commonly used resources are the global DNS Blackhole Lists (DNSBLs), operated by various individuals and groups to indicate which IP addresses on the Internet are currently sending spam. Many such lists have broad support in the Internet.

A list of all known DNSBLs is given at:

The spam tagging program also performs its own evaluation in addition to using several DNSBLs, and is updated as required to minimise false positives (legitimate e-mail incorrectly marked as spam) whilst correctly identifying as much spam as possible.

Add spam tag to message headers 
The Janet Mailer Shield service can attempt to identify spam and add a line in the message header with a score indicating the possibility of an e-mail being spam. It takes the form of:

X-Spam-Bar: ########## Score 10 (3,10) angel1:DATA/E42F1.f0*

If you ask for messages to be tagged, this line is always present. The higher the score, the more likely it is that the message will be spam. The service achieves this by passing the e-mail through a program that uses several criteria to try and discover the nature of the e-mail being sent.

This header line is intended for the end-users to filter messages. Based on the score given in the tag, their mail program may be configured to move suspected spam into a folder they specify, and then let them review it before deleting. Review will prevent losing some legitimate e-mails (false positives), although the rate of these is typically low (about 2%).

The aim of the Janet Mailer Shield system is to mark messages constituting abuse with a score of 8 or more, and other messages with a score of 7 or less. The ‘ X-Spam-Bar: ’ will contain a row of #’s equal to the score, so even fairly crude mail filters should be able to identify it.

End-users should set up a rule equivalent to:

‘If header "X-Spam-Bar:" contains "########" save mail in spam-folder’

This would also catch spam scoring more than 8. The details of how you achieve this will depend on what software you run locally. The IT support at organisations using the Janet Mailer Shield tagging will need to instruct end-users on how best to configure their local rules on a mail program.

Users should not filter on any scores below 8. Tuning revolves around 8+ equalling spam, so a score of 7 should not be filtered. Filtering on scores greater than 8 is fine: however, the higher values will result in less spam being detected.

Add possible virus warnings to message headers

X-Spam-Bar: WinExe (Probably a virus)

This second ‘ X-Spam-Bar: ’ line will only turn up if the Janet Mailer Shield identifies a Windows® binary executable in the e-mail. The ‘WinExe’ tag (short for Windows® executable) will also be in the first ‘ X-Spam-Bar: ’ but some simple filters are unable to find fixed text in a variable header string, so this second header will be added with the important tag at the start. Please note that the Janet Mailer Shield is not checking for viruses, only Windows® executables. Organisations must run their own anti-virus scanning on the local mail hub and on desktops.

WinExe e-mails will also be given a spam score of at least 10.

Indication of source 
You may wish to make your own decision about delivering or rejecting mail on the basis of the IP address from which it came. Unfortunately, if the Janet service relays your mail to you, that address will always indicate a Janet relay and the information is of little use. Connection information will be present in one of several ‘ Received: ’ lines in the message header, but it is not easy to find or interpret.

The relays of the Janet Mailer Shield service can add a line to the header of each message starting ‘ X-JMS-connection-from: ’ and include in the same line the IP address of the system from which the message reached the relay; for example


(but note that this particular address will never occur in practice).

Note that this is commonly NOT the IP address from which the message started. Tracing the path a message has taken and identifying its origin involves specialised examination of the complete message header. Where a message constitutes abuse, the origin can be very hard to find with certainty.

Add DNSBL warnings to message headers 
As well as identifying the immediate source of each message, the Janet relays can add further header lines indicating whether the source is listed in any of the parts of RBL+. You may then be able to take action on the basis of that information, either centrally or through filtering by recipients.

Janet(UK) checks several public DNSBLs when accepting email, and will insert a header line for any that contain the connecting IP address at the time the email is accepted. The header lines will be of the form:-

 X-DNSBL: <IP> is in a black list at <DNSBL> (value = <x.x.x.x>)

 In the above:-

  <IP>      is the connecting IP address.

  <DNSBL>   is the public DNSBL that the IP address was in.

  <x.x.x.x> is the return value from the DNSBL.

 If no warning lines are added then the IP address concerned was not listed in and of the DNSBLs we monitor at the time the message reached the Janet relay.

The last two added header lines are a form of warning not principally intended for end-users. Ways in which a mail server might use the information include:

  • attempting to return the message or a notification to its sender with an indication of the reason it was rejected, based on the details in the header warning line. Note that in e-mail abuse, the ‘ Return-Path: ’ address, the ‘ MAIL FROM : ’ and the ‘ From:’ header line may all be false, invalid or both
  • destroying the message
  • delivering the message to the intended recipient with a readable warning included in the message body such as

You can in principle look up the source address in a DNSBL of your own choice or a local blacklist, and decide for yourself or on behalf of the message recipient what to do with the message. It may also be possible for recipients to do their own filtering after delivery. Advice on such processing is not a part of this service. Note that some of the possible actions mentioned might be considered to be interfering with recipients’ e-mail. Under most circumstances this particular interference is acceptable provided end-users are aware that it may happen.

Echo service

Janet supports an e-mail address

which accepts a message from any Janet IP address and responds with a message to the e-mail address from which it appeared to come.

The message you send can have any ‘ Subject: ’ ; both this and contents are ignored but they should not be blank. For example, you can if you wish make the content a single line which is the same as the ‘ Subject: ’ . The returned message will have

Subject: Janet echo response

and its contents will be the complete header of your initial message as it reached the echo server, sent as plain text.

You may find this useful:

  1. to confirm from time to time that at least some mail both out of your organisation and into it is working. You may wish to send an automatic echo request early each morning and to arrange for a technician or an automatic process to check the response at the start of the working day. You could note the time between sending your request and receiving the response under normal circumstances, and so be able to spot early signs of trouble. A round-trip time of more than 30 minutes is probably not good enough.
  2. to check that the message headers you send are as you expect them to be. You should be aware of any internal information that is exposed in each message header, and you should examine time stamps and other technical details.

Echo requests are directed to a server that is not one of the relays of the Janet Mailer Shield service, so the reply will have to find your server (possibly a JMS relay) and make connections just as mail from anywhere else in the Internet does.