houghi wrote:

> Baron wrote:
>> I agree ! However I didn't know that I had problems until someone
>> that
>> needed a document from me phoned to ask where it was. I checked and
>> it
>> had been sent over an hour earlier. So I resent the mail whilst I
>> was
>> on the phone.... Nothing ! Nothing from his end either. No failure
>> message, nothing at all.
>
> Kids these days. Thinking that Email must arrive instantly.

I'm well aware that it can take from seconds to days for mail to be
transported through the system.

> Email is not a direct form of communication as people think it is.
>
>> We kept trying for over an hour. Then suddenly he said that he had
>> got my mail. The re-send from two minutes before. He sent me one
>> from his end and seconds later it dropped into my mailbox.
>
> Pretty normal and standard. I do not see this as a problem. The
> problem is your perception of email, not email itself.
>
> So what happens with email as a standard is the following. You write
> it, then send it to your providers smtp server(A). He accepts it, so
> you do not get an error.
> After accepting, it will look as to where it needs to go and tries to
> deliver it. That other machine(B) accepts it adn looks where it should
> be placed. Then the other side will look if it s there.
>
> This is the very basic setup. Often there are some other machines in
> between there. Now what can happen is that between (A) and (B) there
> can be some delays for several reasons. One is a spam attack, or any
> other problem.
>
> So what happens when the one machine can not send it to the other is
> wait and try again. First a minute then a few minutes, then an hour
> then 4 hours. After 4 hours or so if delivery is still not done will
> it send you a warning that the mail has not yet been deliverd, but
> PLEASE DO NOT SEND IT AGAIN. What happens is that people then send it
> again, because they do not read.
>
> Now imagine somebody actualy not re-sending it and thus letting a
> potential overloaded server do its job and not add more load to it, it
> will try for up to 4 days and only then tell you that delivery is not
> possible.
>
> As long as that has not happened, the mail is not 'gone' it is still
> on the SMTP sever who is trying to send it. It is in a queue.
>
> Now each message gets a new time and time gets longer over time for a
> very good reason. So this will mean that once a message gets through,
> it is highly likely that a message you send later will arrive earlier.

Yes I agree ! I have had messages turn up out of order a number of
times.

>>> First test the smtp with telnet and see if you can send mail there:
>>> telnet server.example.com 25
>>> mail from: houghi
>>> rcpt to: user@example.com
>>> data
>>> test
>>
>> Nothing only "?Invalid command"
>
> Huh? No 'telnet'? I thought that was installed on every machine as a
> standard. If not, please install it. You can not do any network
> testing without it.

Yes its installed. When the server is working I get quite different
responses.

>>> And then see what happens.
>>>
>>> To test the pop3, you do
>>> telnet server.example.com 110
>>> user login
>>> pass password
>>> list
>>> last
>>> top 0 0
>>> quit
>>>
>>> And see that there is mail in there.
>>
>> Same here "Name or service not known"

If I do the same to my own server I get the expected response !
Actually I get "ogin" the "L" is missing.

> That is not the same. That is different. One tells me that telnet is
> not installed, the other tells me that port 110 is not known there.
>
> I hope you understand that the domain names are not real. I do have NO
> idea what they must be in your case.

Yes I do. The DNS lookup works fine. When the server is working it
come back with the dotted quad.

> I find it odd that first the command telnet does not exist and in the
> second part it does. Please copy and paste whatever you did. Do not
> change server names (I can look it up anyway, but I am too lazy) Just
> change the emailadress, if possible by just adding .invalid to it.

When the service disappears telnet fails with "?Invalid command"
Otherwise I get expected responses.

> And again, I think your provider (and theirs) where right in saying
> there was no problem. If you want direct communication, right away
> instantly, email is NOT the correct tool.

No I am not looking for instant communication. I have voice and FAX
services for that.

> The reason for delay can be various and are to be expected. That is
> why SMTP has these delays build into it. I have seen mail pass 7 or 8
> different servers and between each one there was a delay. The more
> machines are used, the more can go wrong.
>
> Where things go wrong is something you can see in the headers. The
> most common reason for a delay nowadays is a LOT of spam arriving at
> the same time at the provider, so that there are delays and even
> timeouts.

I couldn't agree more !

> And as you recieved your mail as it was supposed to, I would say the
> system worked as expected. (Did I mention that email wasn't direct
> communication?)

You did ! But mail was not received as it was supposed to ! So there
are no headers to show. I wish there were ! As you say the path can
be traced through those. But since the mail just disappears, and from
both ends, I've nothing to track anything with.

> houghi

I do understand and agree that a problem at my end could explain what is
happening ! If so why does everything work properly when I switch
ISP ? Web mail works either way. The only difference there is the use
of a browser and protocol. I can send or rather try to send a mail via
SMTP using my ISP's server and be watching the receiving machine via
web mail and nothing ever arrives.

--
Best Regards:
Baron.