Topic: Email is not coming or going between me and a remote correspondent
Executive Summary:
Click this:
'trackemail@owlriver.com'
to send us a diagnostic email. Please also add a 'cc:' to the
other addressee, who is having problems.
... and The Details:
We administer and maintain email
services on behalf of many clients. We asked that you read this page, to
help us clear up a seeming email problem.
We perform several sub-functions, including:
Receiving and tracking inbound email from others
Reducing so-called 'SPAM', email bourne Windows viruses,
and content from un-maintained or un-secure email sources
(which provide transit Open Relay points to propigate SPAM)
Delivering and tracking outbound email to others
Handling re-routing or disposition of misaddressed, and
stale addressed email
Please note: Email is not a substitute for the file
transfer protocols (size limitations as it passes through
intermediate handlers, insecurity from tampering, and
inadvertent disclosure to third-parties, all come to mind).
It is not necessarily immediate -- while we are
accustomed to fast delivery, the Internet design specifications
have a 5 day delivery retry window.
It is also only a 'best-efforts', and not a 'guaranteed'
delivery method. SPAM and virus control measures are not
totally capable of stopping such attacks, as third-parties
continually change ('mutate') their efforts to evade detection and
abatement.
If you, as our customer, think your application needs any of those
attributes [large size transfers, uncorrupted transfers (due to
intermediate MIME and other encoding), positive confirmation of
receipt, security from tampering, and so forth], contact us for
a system designed to meet stated needs and requirements.
What should our clients do to have a missing piece investigated?
Very often, it is a simple case of misaddresing; sometimes, it is
more serious, with a configuration error impeding delivery.
A systematic investigation of the outage is needed to rule out
various causes. Unfortunately, domain registrations expire,
address books get erroneous information, the 'DNS' -- Domain
Name System (which 'publishes' the 'mail exchanger' information
for a given domain) can be temporarily busy. Most of the time,
the normal systems get the email though on a later 'retry.'
When persistent problems occur, in order to track down where a given piece
is going astray, we go to the logfiles which we maintain.
To search effectively, we need some basic information:
The exact email address of the remote correspondent
(-- not Company name, not the remote correspondent's personal
name --) which is having problems; and our client's email
address to which it is being sent
The date and time, accurate within an hour or so, when a
prior piece from that exact email address was
successfully received by our client
A new test case for us to track through the logfiles of our systems,
sent to both that remote correspondent,
and to our email testing account:
trackemail@owlriver.com
Click this:
'trackemail@owlriver.com'
to send a diagnostic email. When we receive an email to that address
from a client, describing that problem -- or if email is not
available or is not working, a problem report
sent using our web
contact system, we will then be able to track the cause of
a non-delivery down. While we will also review reports from
non-clients, obviously these are of lower priority.
Often -- indeed, most of the time when addressing is accurate --
we have found that the remote party's email server does
not meet the specification, called RFC 2821, governing
email exchange, -or- is listed on an anti-spam or 'Open
Relay' listing. See: our webpages on this topic, at the
bottom for a list of resources on this topic. This error
is also knowable at the remote end as well from their
logfiles, and in the case of Windows virus detection, SPAM
or unsecured Open Relays, an automated rejection details
message which is returned for every rejection
when our email servers decline to accept a given piece.
When we so determine a rejection to be due to RFC 2821 non-conformance,
or due to being on a SPAM or Open Relay 'blocklist',
we will document this to the client, and at the client's
request to the remote corrspondent and their 'Postmaster'
What happens then?
In the instance of a problem at the remote end, only the remote
correspondent and their email administrator can address
and resolve the non-conformance at their end of
the transaction. Without authority to administer the
remote email server, it is beyond the scope of what we
can modify to resolve such outages.
Sometimes, the remote correspondent is unsure of the
proper person able to act as their 'email administrator' for
this kind of issue. RFC 2821 requires that the proper remote
email administrator be reachable through the email address:
postmaster@example.com where, of course the proper
domain is substituted for 'example.com'
But I don't care about these standards, spam filtering,
Windows virus filtering, RFC's and all that ... I just
want the email
Us too. But the flood of 'spam' and Windows virus laden email
have made it so we have to take protective measures. Nearly
30 % of all email are from unwanted senders ('spam'), or
malicious ('Windows virus content'). Fortunately, there
exist various standards, including the RFC's, so
that there is a known 'least common denominator' set of features
for mailserver configuration and design purposes.
The filtering software and techniques which
we use identifies mis-configurations ('spammers' tend to use
rogue or mis-configured mail servers to 'shovel' their
advertisements into mail servers), does do automatically on a
rule based content-neutral basis without a human reading your email
(so the relative privacy of your email is not inadventently exposed
to others), and verifies that a 'valid' MIME attachment is structured
(most Windows viruses do not confirm to those standards, and can
so be indentified). Email from a mail server conforming to those
RFC's will go right through, permitting inter-operability of anyone
with anyone else. We discuss this further
here.
The RFC process is well described in
RFC 2223.
Ditto automated identification of insecure email servers,
MIME profile pattern based
Windows virus filtering and automated
spam content 'signature' identification, and
Open Relay
detection and content blocking. It's tricky to set up a mail
server right and to keep the 'spam' and Windows virus content out.
But when one can point to a neutral standard set of rules, we can
all talk when we each follow the 'rules of the road.'
