ORC Owl Logo 2  

Owl River Company

 
  Your IP is: 54.80.158.127

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:
  1. Receiving and tracking inbound email from others
  2. 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)
  3. Delivering and tracking outbound email to others
  4. 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:
  1. 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
  2. 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
  3. 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.'
       

Back to Top Page
[legal] [ no spam policy ] [ Copyright] © 2008 Owl River Company
All rights reserved.

Last modified: Mon, 11 Dec 2006 12:34:48 -0500
http://www.owlriver.com/support/email/index.php