Tracing an email message

merry wrote:
> I know that by using apps such as Interarchy I can see web activity, but
> is there any way I can trace an email message from myself to someone on
> a second ISP?

You can use Interarchy to watch the SMTP transaction between your
machine and the MX server for the domain in question
(File->Net->Traffic...). This could show you if your machine is having
trouble making a connection and pushing the mail out. But once the
remote SMTP server accepts the message, your mail program's job is done,
and there's really only one way to find out what happens then.

>
> I have been finding that mail I send to a major client is taking ages,
> sometimes several hours, while mail I receive from that company has
> (today at least) taken a minute or so to arrive on my desktop. I am not
> sure if the email problems I am having are caused by my ISP or the
> client’s.
>
> [Usually, checking the Received headers (have them send a delayed one
> back to you) will reveal the source of the blockage, if not the reason.
> -Adam]

Adam's right, this is the only way to know. You might also ask your
recipient what goes on internally in their mail servers that might cause
a delay, but you may not get an answer.

--
Paul Schinder
schinderpobox.com

On 11/12/2004 13:39, Adam interjected into a message "merry"
<merriedial.pipex.com> wrote:

> [Usually, checking the Received headers (have them send a delayed
> one back to you) will reveal the source of the blockage, if not the
> reason. -Adam]

You make it sound so easy, Adam.

Most "large clients" would be using Outlook...some would be using Outlook
Express...on Windows. It's rare that such people know there are Received:
headers and even rarer that they know the odd convolutions which are
necessary to see them, much less copy them and paste them somewhere.

[Oh, yeah, right. :-) Usually they're available somewhere, though hidden. -Adam]

We are so fortunate, off in our statistically insignificant part of the
email universe. These things are easy for us.

Merry...if you do get a set of Received: headers back, keep the timezone
markings in mind. Even if the message stayed in the same timezone from end
to end, it may have passed through servers elsewhere, or through servers
which timestamp in GMT (OK, UTC).

  --John

At 1:39 PM -0800 11/12/04, merry wrote:
>I have been finding that mail I send to a major
>client is taking ages, sometimes several hours,
>while mail I receive from that company has
>(today at least) taken a minute or so to arrive
>on my desktop. I am not sure if the email
>problems I am having are caused by my ISP or the
>client’s.

As Adam said, looking at the Received headers
will indicate on which "hop" the delay was
introduced. However, you probably won't be able
to tell which of the 2 machines is having the
problem without looking at one the log files of
one of the machines.

Two things to keep in mind are: (1) Received
headers aren't usually shown by mail clients, so
the receiver will have to "view source" or
something equivalent before sending the message
back to you, and (2) you have to take into
account the time zones of the mail servers
involved.

One thing to try is to use a
Yahoo/Hotmail/GMail/... account to send a test
message, since this will bypass your ISP's mail
server. If this is also delayed, then the
problem is likely to be on your client's side.

A more sophisticated approach is to set up your
own mail server; that way you can monitor it
closely and look at its logs, which can help
diagnosing the problem. Assuming you're on Mac
OS X, the software is built in, and there are a
number of articles that explain how to enable it.

--
Larry Rosenstein
lsralum.mit.edu

--On Friday, November 12, 2004 1:39:52 PM CST -0800 merry
<merriedial.pipex.com> wrote:

> I have been finding that mail I send to a major client is taking ages,
> sometimes several hours, while mail I receive from that company has
> (today at least) taken a minute or so to arrive on my desktop. I am not
> sure if the email problems I am having are caused by my ISP or the
> clients.

Just as a rough guess since mail to is slow while mail back is fast I would
guess spam filtering is the slow down. Spam filtering can be CPU intensive
and create backlogs of mail waiting to be processed. Before we started
using relay blocking lists to block a majority of spam before it hit the
spam filters, and beefed up the server doing our scanning, delays of 30
minutes were normal, and not unusaly to go up over an hour.

Kevin

At 1:39 PM -0800 2004/11/12, merry wrote:
>I know that by using apps such as Interarchy I can see web activity, but
>is there any way I can trace an email message from myself to someone on a
>second ISP?

        Not really. You might be able to figure out what the network
connection between your system and their mail server, but that does not
necessarily tell you what path your email message might take, or what the
computers that do the transfers are up to at any given time.

>
>I have been finding that mail I send to a major client is taking ages,
>sometimes several hours, while mail I receive from that company has (today
>at least) taken a minute or so to arrive on my desktop. I am not sure if
>the email problems I am having are caused by my ISP or the client’s.

        You might have some luck in using another outgoing SMTP server -
either run one locally from your computer or use .mac or some other
provider that you have a relationship with. If mail sent via this server
works fine, then you have some evidence that it is your ISP with troubles.

        You might be able to set your email client to use the client's SMTP
server. Typically SMTP servers cannot be used by someone outside of the
network, but since you are trying to deliver to an account on their network
the SMTP server might be ok with taking your email directly (because you
are not trying to "relay" email to someone outside their network).

At 15:59 -0800 12/11/04, Larry Rosenstein wrote:
>A more sophisticated approach is to set up your
>own mail server; that way you can monitor it
>closely and look at its logs, which can help
>diagnosing the problem. Assuming you're on Mac
>OS X, the software is built in, and there are a
>number of articles that explain how to enable it.

Hi Larry
Thank you very much for this information. Can you
point me in the direction of some "how to"
articles on the Web for setting up a mail server
on my own Mac?

Thanks

Merry

On 11/16/2004 13:18, "Merry" <merriedial.pipex.com> wrote:

> At 15:59 -0800 12/11/04, Larry Rosenstein wrote:
>> A more sophisticated approach is to set up your
>> own mail server; that way you can monitor it
>> closely and look at its logs, which can help
>> diagnosing the problem. Assuming you're on Mac
>> OS X, the software is built in, and there are a
>> number of articles that explain how to enable it.
>
> Hi Larry
> Thank you very much for this information. Can you
> point me in the direction of some "how to"
> articles on the Web for setting up a mail server
> on my own Mac?

Keep in mind, if you have a dialup connection or other connection with a
changing IP address, that many places refuse mail from such IP addresses
(we, instead, accept the messages and add a point to their Spam Assassin
score).

That would apply both to trying to configure your email program to use your
client's SMTP server, and to setting up your own mail server. You'll end up
learning how to configure Postfix (the server that comes with current Mac OS
X) to "send mail to this domain over there, and everything else here."

And, on top of that, your ISP may not allow you to use any SMTP server
except theirs to send mail, in which case all this is moot.

Oh...and your client's incoming mail server may not have the same IP address
as its outgoing server does.

I'd say to concentrate first on why there are delays sending to your client,
rather than how to work around them.

  --John

On Nov 16, 2004, at 4:09 PM, Kevin van Haaren wrote:

> Just as a rough guess since mail to is slow while mail back is fast I
> would
> guess spam filtering is the slow down. Spam filtering can be CPU
> intensive
> and create backlogs of mail waiting to be processed.

It's not just a CPU issue. On CommuniGate Pro, the spam filter license
is sold by speed -- the cheapest license handles 50 emails per minute,
and then just queues everything else. This on a server where it's not
uncommon to see twenty things logged every hundredth of a second. So
depending on what spam filter is being used, the bottleneck could be in
the software.

Best,
Jeff