I need to check whether an Email path is working or not ! So I am
looking for a way of automating sending a test mail from one machine to
another machine and having the receiving machine send a mail back in
response.

I know that I can use cron to send a fixed message via smtp and that I
can ask for a MDN if that hasn't been turned off. But I haven't a clue
how to get an automatic response or how to make a mail client do that.

I'm using Open SuSE 10.2, 10.3 and 11.0 KDE 3 DE.

Thanks in advance.

--
Best Regards:
Baron.

Baron wrote:
> I know that I can use cron to send a fixed message via smtp and that I
> can ask for a MDN if that hasn't been turned off. But I haven't a clue
> how to get an automatic response or how to make a mail client do that.
>
> I'm using Open SuSE 10.2, 10.3 and 11.0 KDE 3 DE.

Take a look at procmail/ You will need to make a file ~/.procmailrc that
looks at the sender or the subject or whatever and send it back.

houghi
--
Dr. Walter Gibbs: Won't that be grand? Computers and the programs
will start thinking and the people will stop.
-- Tron (1982)

The carbonbased lifeform Baron inspired alt.os.linux.suse with:
> I need to check whether an Email path is working or not ! So I am
> looking for a way of automating sending a test mail from one machine to
> another machine and having the receiving machine send a mail back in
> response.

As houghi said: procmail.
See specifically: procmailex(5)
Look for "autoreply recipy"

Theo
--
theo at van-werkhoven.nl ICQ:277217131 SuSE Linux
linuxcounter.org: 99872 Jabber:muadib at jabber.xs4all.nl AMD XP3000+ 1024MB
"ik _heb_ niets tegen Microsoft, ik heb iets tegen
de uitwassen *van* Microsoft"

Baron wrote:

> I need to check whether an Email path is working or not ! So I am
> looking for a way of automating sending a test mail from one machine
> to another machine and having the receiving machine send a mail back
> in response.
>
> I know that I can use cron to send a fixed message via smtp and that I
> can ask for a MDN if that hasn't been turned off. But I haven't a
> clue how to get an automatic response or how to make a mail client do
> that.
>
> I'm using Open SuSE 10.2, 10.3 and 11.0 KDE 3 DE.
>
> Thanks in advance.

Hey Guys Thanks. "procmail" I learnt something new today !
I'm going to spend some time reading and playing with it !

*************************************************
Just in case anybody wants to know why I want to test Email paths, it is
because my ISP keeps turning the smtp and pop off. I get regular
periods where I can be without Email for a couple of hours at a time.
The servers don't respond to pings even when they are working and mail
both ways just disappears into a black hole.

I can send mail via another ISP during these outages and can access
webmail but nothing comes in from anywhere via pop.

So I want to set up a method of testing that I can record and log the
times and duration of the outages ! Then I have something that I can
prove it is happening. The ISP of course denies that it happens.
*************************************************

If anyone knows a better way please shout.
Thanks once again.

--
Best Regards:
Baron.

Baron wrote:
> The servers don't respond to pings even when they are working and mail
> both ways just disappears into a black hole.

Ping is only good if it gives an answer and if you maintain the machines
yourself. Otherwise it is a pretty lousy thing to check.
The best way is first to do a traceroute. This will determine wether DNS
is working and if network is working.

If that is (partly) successfull, do a `telnet smtp.example.com 25` or
`telnet server port` to see if the service is up and running.

> I can send mail via another ISP during these outages and can access
> webmail but nothing comes in from anywhere via pop.

A lot depends on how the system is set up. Normaly one would expect that
if mail is accesible via webmail, it is available via pop3 as well.
Obviously the pop3 should be up and running.

> So I want to set up a method of testing that I can record and log the
> times and duration of the outages ! Then I have something that I can
> prove it is happening. The ISP of course denies that it happens.

You arleady have something like that: the headers.
However I can imagine that the ISP is saying such a thing. The thing you
are going to do will meaqn absoluetly nothing to them. What they see is
this:
1) Mail comes in
2) Mail is put in your mailbox.

As webmail works the only two things that could be causing a problem is
either on your side or on their side.

When you are the only person who has problems, the chances are extremely
high the problem is on your side.

So how to test? First realize that sending and recieving mail are two
completely different things. The fact that they are both not working at
the same tine tells me that the likelyhood of something wrong on your
side are much higher.

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
..

And the 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.

Now when you have this information, you will most likely already know
what the problem is and perhaps even what the solution is. That way you
can tell them in more detail what is going on or solve it at your side.


houghi
--
You are about to enter another dimension, a dimension not only of
sight and sound but of mind. A journey into a wondrous land of
imagination. Next stop, Usenet!

Baron wrote:
> So I want to set up a method of testing that I can record and log the
> times and duration of the outages ! Then I have something that I can
> prove it is happening. The ISP of course denies that it happens.


Try Nagios.
http://nagios.sourceforge.net/docs/3...cservices.html
discusses the monitoring of SMTP, POP, and IMAP.

houghi wrote:

> Baron wrote:
>> The servers don't respond to pings even when they are working and
>> mail both ways just disappears into a black hole.
>
> Ping is only good if it gives an answer and if you maintain the
> machines yourself. Otherwise it is a pretty lousy thing to check.
> The best way is first to do a traceroute. This will determine wether
> DNS is working and if network is working.

I hadn't thought of "traceroute" !

> If that is (partly) successfull, do a `telnet smtp.example.com 25` or
> `telnet server port` to see if the service is up and running.

See further down.

>> I can send mail via another ISP during these outages and can access
>> webmail but nothing comes in from anywhere via pop.
>
> A lot depends on how the system is set up. Normaly one would expect
> that if mail is accesible via webmail, it is available via pop3 as
> well. Obviously the pop3 should be up and running.
>
>> So I want to set up a method of testing that I can record and log the
>> times and duration of the outages ! Then I have something that I can
>> prove it is happening. The ISP of course denies that it happens.
>
> You arleady have something like that: the headers.
> However I can imagine that the ISP is saying such a thing. The thing
> you are going to do will meaqn absoluetly nothing to them. What they
> see is this:
> 1) Mail comes in
> 2) Mail is put in your mailbox.
>
> As webmail works the only two things that could be causing a problem
> is either on your side or on their side.
>
> When you are the only person who has problems, the chances are
> extremely high the problem is on your side.

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.

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.

> So how to test? First realize that sending and recieving mail are two
> completely different things. The fact that they are both not working
> at the same tine tells me that the likelyhood of something wrong on
> your side are much higher.
>
> 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"

> And the 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"

> Now when you have this information, you will most likely already know
> what the problem is and perhaps even what the solution is. That way
> you can tell them in more detail what is going on or solve it at your
> side.
>
>
> houghi

--
Best Regards:
Baron.

Gary Gapinski wrote:

> Baron wrote:
>> So I want to set up a method of testing that I can record and log the
>> times and duration of the outages ! Then I have something that I can
>> prove it is happening. The ISP of course denies that it happens.
>
>
> Try Nagios.
> http://nagios.sourceforge.net/docs/3...cservices.html
> discusses the monitoring of SMTP, POP, and IMAP.

Thanks. I will go and have a look at that.

--
Best Regards:
Baron.

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.

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 peolle then send it again, because
they do not read.

Now imagine somebody actualy not re-sending it and thuis 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 happend, 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.

>> 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.

>> And the 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"

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.

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.

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

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.

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?)

houghi
--
You are about to enter another dimension, a dimension not only of
sight and sound but of mind. A journey into a wondrous land of
imagination. Next stop, Usenet!

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.