SEO

Well maybe the subject got your attention but here is the problem as my
customer reported it and my apologies for the length. First some information
exaplanation and then I can tie it all together. I have a customer on a 5.0.7
and to my knowledge they do not have MP5 installed and we were not concerned
with the dates last year so in preparation for DST we simply changed the
/etc/TIMEZONE file as described in this group. Old line in this file was:

TZ='EST5EDT'

now

TZ='EST5EDT,M3.2.0/2,M11.1.0/2'

We then rebooted and logged on and checked the Environment and TZ was set to
the new form. System did change time on Sunday as expected.

This customer also has a process on their 5.0.7 system in their accounting
package where at a customers request they will Email them a copy of an invoice.
5.0.7 is using sendmail but while we are sending it out from the SCO machine
the actual from and the reply to email is set to an info@customer.com account
(which is an email account they have set up on ther outside world email
system). The SCO machine has no other email function than standard system mail
and then these outbound invoices. This works well most of the time but
occassionally they will get some bad address or for some reason undelivered
returns. I will post on this in another post with some examples.

While researching this I could find no reason for these sporadic failures but
the customer mentioned a while back they had had to change to the Bellsouth DNS
servers on their windows system (which is the main connection plus a router and
DSL modem) to the outside world). So in keeping in line we changed the
Bellsouth DNS server IPs in the SCO 5.0.7 /etc/resolv.conf file.

Now to tie this all together. They retrieve several files daily from the SCO
Machine to a Windows machine via and ftp script using Windows ftp. They did
this last on Thursday afternoon of last week. I made the change for the DNS
IPs in /etc/resolv.conf on Thrusday Night and they changed the /etc/TIMEZONE
and rebooted early Friday Morning. The IT type on site is the only one with an
ethernet connection (besides on demand inbound VPN connections through a
windows machine) and all others are Serial through a Digi. Since these two
events the FTP process has failed to function and telnet attempts to get a
login are taking an unusually long time. I have connected via VPN and have
noticed the long times from point of attach (Tiny Term) to a login prompt and
attempting to use his ftp script or manually connect via windows ftp have
failed. The best I have achieved is by using Cygwin FTP and it takes a long
time but does connect and if I use sftp it connects quit quickly. It also
seems using ssh to connect vs telnet is quicker as well although not as
noticable as the sftp vs ftp.

Since then in an attempt to diagnose on the SCO machine I put the original two
DNS servers back in the /etc/resolv.conf file but that has not helped. Pings
on the four different BellSouth DNS servers we had showed the response time
from the first two was much almost instantaneous vs the two they had me change
to which is why we tried all 4 but with the originals listed first. Last night
I removed the two new ones leaving just the originals and advised client a
reboot might again be in order.

I see no reason that either of these above should affect the login or the ftp
procedure but I am at a loss to come up with any other explanation. I thought
at one point maybe the TZ expansion was causing an issue when the environment
was being established for login but.... wouldn't something like that affect the
serial connections as well as the network.

Any thoughts - anyone seen anything like this. Thanks to all in advance.

bk

In article <VA.0000154e.00aa9ca2@thesoftwaresource.com>,
Brian Keener <bkeener@thesoftwaresource.com> wrote:

[much deleted only down to pertinent points - wjv]

>This customer also has a process on their 5.0.7 system in their
>accounting package where at a customers request they will Email
>them a copy of an invoice. 5.0.7 is using sendmail but while we
>are sending it out from the SCO machine the actual from and the
>reply to email is set to an info@customer.com account (which
>is an email account they have set up on ther outside world
>email system). The SCO machine has no other email function than
>standard system mail and then these outbound invoices. This
>works well most of the time but occassionally they will get some
>bad address or for some reason undelivered returns. I will post
>on this in another post with some examples.

The returned mail should have a great deal of info that you can use
to diagnose the problem. Without seeing the error messages you can
tear your hair out trying to figure out the problem. [I go through
this quite often maintaining emails for an ISP and also for a few
outside machines]

Some places will refuse email if they can not resolve the machine's
name given in the mail vs the IP it came from and can reject it or
treat it as a forged address.

>While researching this I could find no reason for these sporadic
>failures but the customer mentioned a while back they had had
>to change to the Bellsouth DNS servers on their windows system
>(which is the main connection plus a router and DSL modem) to the
>outside world). So in keeping in line we changed the Bellsouth
>DNS server IPs in the SCO 5.0.7 /etc/resolv.conf file.

>Now to tie this all together. They retrieve several files daily
>from the SCO Machine to a Windows machine via and ftp script
>using Windows ftp. They did this last on Thursday afternoon of
>last week. I made the change for the DNS IPs in /etc/resolv.conf
>on Thrusday Night and they changed the /etc/TIMEZONE and rebooted
>early Friday Morning. The IT type on site is the only one with an
>ethernet connection (besides on demand inbound VPN connections
>through a windows machine) and all others are Serial through
>a Digi. Since these two events the FTP process has failed to
>function and telnet attempts to get a login are taking an
>unusually long time. I have connected via VPN and have noticed
>the long times from point of attach (Tiny Term) to a login prompt
>and attempting to use his ftp script or manually connect via
>windows ftp have failed. The best I have achieved is by using
>Cygwin FTP and it takes a long time but does connect and if I use
>sftp it connects quit quickly. It also seems using ssh to connect
>vs telnet is quicker as well although not as noticable as the
>sftp vs ftp.

It depends on the FTP package but many will totally refuse
connections if they can not resolve the name/IP combination from
the incoming IP address. I used to see this problem when I was
on an IP from an ISP that would give me IP addresses anywhere in
two differernt /24 blocks. The cure to make things go fast
was to add all the IP/name combinations to the /etc/hosts. And I
had this problem connecting to machines at the ISP I maintain so I
put those IP/name combinations in the /etc/hosts there too, and
connections went from as long as 2 minutes to almost instantly.

I suspect you have DNS problems. Will the machines resolve
correctly on both side from the DNS you are using. If not try
adding things to /etc/hosts. Messy but it works. I beleive it
is lmhosts in MS [at least it used to be].

>Since then in an attempt to diagnose on the SCO machine I put the
>original two DNS servers back in the /etc/resolv.conf file but
>that has not helped.

It's the machine you are connecting to that needs to be able to
resolve the name/address combination from the incoming IP it sees.

>Pings on the four different BellSouth DNS servers we had
>showed the response time from the first two was much almost
>instantaneous vs the two they had me change to which is why we
>tried all 4 but with the originals listed first. Last night I
>removed the two new ones leaving just the originals and advised
>client a reboot might again be in order.

Pings are usually only good for checking connectivity - unless some
un-informed but well-meaning admin has blocked all ICMP messages -
which I see far too often.

And you really don't need to reboot. Just restart the TCP
services. It saves a lot of time and keeps customers happy as
their machines don't go down.

>I see no reason that either of these above should affect the
>login or the ftp procedure but I am at a loss to come up with any
>other explanation. I thought at one point maybe the TZ expansion
>was causing an issue when the environment was being established
>for login but.... wouldn't something like that affect the serial
>connections as well as the network.

>Any thoughts - anyone seen anything like this. Thanks to all in
>advance.

Again - both machines must be able to resolve and I suspect that if
you check on the target machine it won't resolve the SCO machine -
or vice-versa if the connection is going the other way.

Bill

--
Bill Vermillion - bv @ wjv . com

Bill Vermillion wrote:
> The returned mail should have a great deal of info that you can use
> to diagnose the problem. *Without seeing the error messages you can
> tear your hair out trying to figure out the problem. [I go through
> this quite often maintaining emails for an ISP and also for a few
> outside machines]

Trying to gather some sample of the failures now. Should be easy right now to
check his connection and DNS since the guy withthe ftp is the only ethernet
besides the inbound vpn though a windows machine. Right now its his local
ethernet I am concerned with - we'll just make sure name/ip address
combinations for his and the sco machine are in each hosts file.

Once again thanks for all the input.

Bill Vermillion wrote:
> The returned mail should have a great deal of info that you can use
> to diagnose the problem. *Without seeing the error messages you can
> tear your hair out trying to figure out the problem.

Bill,

As to the issue with the telnet becoming slow and ftp failing - we added and or
verified the ip addresses and names of the workstation(s) and the sco machine
and that they existed in the respective hosts files. Client reported the
telnet sessions are back to the connect/login speed they were at previously and
while ftp connects are still a little slow it is functioning and so they're not
complaining.

As to my mention as well about the email issues and returned mail I almost
forgot I intended to follow up on this until today. One returned mail example
they sent me looked like this - in the below example the x and y's are my
custopmers system and their SCO machine is set up as the .local - the .com
addresses are the outside world which actually goes to an ISP - the
cst@customercompany is their client they were trying to email to.

**********************

From: "xxxxsco.yyyyyyyyyyyyy.local MMDF Mail System" <mmdf@yyyyyyyyyyyyy.com>
To: <xxxx@yyyyyyyyyyyyy.com>
Subject: Failed mail *(msg.aa28987)
Date: Tue, 6 Mar 2007 15:37:12 -0500

Your message could not be delivered to
'cst@customercompany.org (host: customercompany.org) (queue: smtp)'
for the following reason:
Remote host responded: *5.7.1 <cst@customercompany.org>... Relaying denied.
Proper authentication required.

****Your message follows:

To: cst@customercompany.org
From: xxxx@xxxxsco.yyyyyyyyyyyyy.local
Subject: INVOICE
Reply-To: xxxx@xxxxsco.yyyyyyyyyyyyy.local
Content-Type: text/html
Date: Tue, 6 Mar 2007 15:36:39 -0500 (EST)
Sender: xxxx@xxxxsco.yyyyyyyyyyyyy.local
Message-ID: *<200703061536.aa28987@xxxxsco.yyyyyyyyyyyyy.local >

*********************

Another example similar to this I found in root's mailbox on their system was
like the following. I add this one because of the orphanage in the header - no
clue what that is and because this one was on their sco machine and the
previous actually came back to the xxxx@yyyyyyyyyyyyy.com account at the ISP
but I could not find it in roots mailbox.

*************************

From root Tue Feb 6 15:00:31 2007
Date: Tue, 6 Feb 2007 15:00:31 -0500 (EST)
From: "xxxxsco.yyyyyyyyyyyyy.local MMDF Mail System"
<mmdf@xxxxsco.yyyyyyyyyyyyy.local>
Sender: root@xxxxsco.yyyyyyyyyyyyy.local
Subject: Failed mail (msg.aa25635)
To: Orphanage <root@xxxxsco.yyyyyyyyyyyyy.local>
Message-ID: <200702061500.aa25644@xxxxsco.yyyyyyyyyyyyy.loca l>
MIME-Version: 1.0
Status: RO

Your message could not be delivered to
'frank@anaccountoftheirsxxx.net (host: anaccountoftheirsxxx.net) (queue: smtp)'
for the following reason:
Remote host responded: 5.7.1 Unable to relay for
frank@anaccountoftheirsxxx.net

*************************

Another form of failures that I have seen I actually located in roots mailbox
on the SCO machine and those reference alias failures as follows - in the
following the info@yyyyyyyyyyyyy.com is the address they have setup on their
ISP for if the customer tries to reply then it will go to that address - there
is no alias file on their system (as I recall).

****************

From root Wed Jan 31 13:18:29 2007
Date: Wed, 31 Jan 2007 13:18:29 -0500 (EST)
From: "xxxxsco.yyyyyyyyyyyyy.local MMDF Mail System"
<root@xxxxsco.yyyyyyyyyyyyy.local>
Subject: Bad address in alias
To: root@xxxxsco.yyyyyyyyyyyyy.local
Message-ID: <200701311318.aa09336@xxxxsco.yyyyyyyyyyyyy.loca l>
MIME-Version: 1.0
Status: O

Found bad address in alias 'xxxx'.
The alias was 'info@yyyyyyyyyyyyy.com'.

There were problems with:
info@yyyyyyyyyyyyy.com

The remaining addresses in the alias were used for submission.

**************

Any thoughts on this - I'm sure I either have something setup wrong or they
just have a flaky connection.

thanks for all the assistance

bk

In article <VA.00001562.01226212@thesoftwaresource.com>,
Brian Keener <bkeenerReMoVeAnTiSpAm@thesoftwaresource.com> wrote:
>Bill Vermillion wrote:
>> The returned mail should have a great deal of info that you can use
>> to diagnose the problem. *Without seeing the error messages you can
>> tear your hair out trying to figure out the problem.
>
>Bill,
>
>As to the issue with the telnet becoming slow and ftp failing - we added and or
>verified the ip addresses and names of the workstation(s) and the sco machine
>and that they existed in the respective hosts files. Client reported the
>telnet sessions are back to the connect/login speed they were at previously and
>while ftp connects are still a little slow it is functioning and so they're not
>complaining.
>
>As to my mention as well about the email issues and returned mail I almost
>forgot I intended to follow up on this until today. One returned mail example
>they sent me looked like this - in the below example the x and y's are my
>custopmers system and their SCO machine is set up as the .local - the .com
>addresses are the outside world which actually goes to an ISP - the
>cst@customercompany is their client they were trying to email to.
>
>**********************
>
>From: "xxxxsco.yyyyyyyyyyyyy.local MMDF Mail System" <mmdf@yyyyyyyyyyyyy.com>
>To: <xxxx@yyyyyyyyyyyyy.com>
>Subject: Failed mail *(msg.aa28987)
>Date: Tue, 6 Mar 2007 15:37:12 -0500
>
>Your message could not be delivered to
>'cst@customercompany.org (host: customercompany.org) (queue: smtp)'
>for the following reason:
>Remote host responded: *5.7.1 <cst@customercompany.org>... Relaying denied.
>Proper authentication required.
>
>****Your message follows:
>
>To: cst@customercompany.org
>From: xxxx@xxxxsco.yyyyyyyyyyyyy.local
>Subject: INVOICE
>Reply-To: xxxx@xxxxsco.yyyyyyyyyyyyy.local
>Content-Type: text/html
>Date: Tue, 6 Mar 2007 15:36:39 -0500 (EST)
>Sender: xxxx@xxxxsco.yyyyyyyyyyyyy.local
>Message-ID: *<200703061536.aa28987@xxxxsco.yyyyyyyyyyyyy.local >
>
>*********************
>
>Another example similar to this I found in root's mailbox on their system was
>like the following. I add this one because of the orphanage in the header - no
>clue what that is and because this one was on their sco machine and the
>previous actually came back to the xxxx@yyyyyyyyyyyyy.com account at the ISP
>but I could not find it in roots mailbox.
>
>*************************
>
>From root Tue Feb 6 15:00:31 2007
>Date: Tue, 6 Feb 2007 15:00:31 -0500 (EST)
>From: "xxxxsco.yyyyyyyyyyyyy.local MMDF Mail System"
><mmdf@xxxxsco.yyyyyyyyyyyyy.local>
>Sender: root@xxxxsco.yyyyyyyyyyyyy.local
>Subject: Failed mail (msg.aa25635)
>To: Orphanage <root@xxxxsco.yyyyyyyyyyyyy.local>
>Message-ID: <200702061500.aa25644@xxxxsco.yyyyyyyyyyyyy.loca l>
>MIME-Version: 1.0
>Status: RO
>
>Your message could not be delivered to
>'frank@anaccountoftheirsxxx.net (host: anaccountoftheirsxxx.net) (queue: smtp)'
>for the following reason:
>Remote host responded: 5.7.1 Unable to relay for
>frank@anaccountoftheirsxxx.net
>
>*************************
>
>Another form of failures that I have seen I actually located in roots mailbox
>on the SCO machine and those reference alias failures as follows - in the
>following the info@yyyyyyyyyyyyy.com is the address they have setup on their
>ISP for if the customer tries to reply then it will go to that address - there
>is no alias file on their system (as I recall).
>
>****************
>
>From root Wed Jan 31 13:18:29 2007
>Date: Wed, 31 Jan 2007 13:18:29 -0500 (EST)
>From: "xxxxsco.yyyyyyyyyyyyy.local MMDF Mail System"
><root@xxxxsco.yyyyyyyyyyyyy.local>
>Subject: Bad address in alias
>To: root@xxxxsco.yyyyyyyyyyyyy.local
>Message-ID: <200701311318.aa09336@xxxxsco.yyyyyyyyyyyyy.loca l>
>MIME-Version: 1.0
>Status: O
>
>Found bad address in alias 'xxxx'.
>The alias was 'info@yyyyyyyyyyyyy.com'.
>
>There were problems with:
>info@yyyyyyyyyyyyy.com
>
>The remaining addresses in the alias were used for submission.
>
>**************
>
>Any thoughts on this - I'm sure I either have something setup wrong or they
>just have a flaky connection.

>thanks for all the assistance

It seems lately I've been living in sendmail as a client was
getting refused on EVERTHING with an error message something
like "content is SPAM" when it could only be 2 or 3 lines of text.

Took about 10 days and talking to more than one admin to get things
straightened out.

But - since you have obfuscated the names/domains of the
above all I can do is give you places to look.

If the SCO machine is supposed to be accepting mail for more
than one domain name you need to see if all the domain names,
including 'localhost'. The stock sendmail uses
the line Fw-o /etc/mail/local-host-names to point to
that file. Check your sendmail.cf for the exact name as I don't
have access to an SCO system at the moment.

As to relaying denied your obfuscation doesn't indicated whether
that is a local machine or a remote machine.

If the denied is for a machine on your local network, perhaps with
a different domain name, and the SCO system is being used to send
all the mail outbound, or you are permitting outside hosts
to send mail through your system then you have to add those
domains to the relay-domains file in /etc/mail

Look in your sendmail.cf file for the variable FR.
The line will look like FR-o /etc/mail/relay-domains.

I'm running sendmail 8.13.8 on about 8 different machines, and I
don't know the current version on SCO, but these changes do go back
quite aways.

Do not be afraid to edit those lines in the sendmail.cf, as in that
area of the file you can edit them without rebuilding the
sendmail.cf.

But it would have helped a lot more if for your obfuscated names
you indicated if they were the local SCO machine, machines on
your local LAN, machines you allow to use your mail server,
or machines you have no control over.

If the 'relaying denied' is coming from the far machine, the
information you gave was not enough to determine the problem.

It could be that you are being denied relaying because your
IP is in some RBL [Real-time Blackhole List] - and there are
several out there that are poorly maintained and will block HUGE
hunks of IP space when one person in a block sends spam.

They also tend to block IPs from DSLs that show the providers given
name for the IP and not yours.

Lots of luck.

Bill

--
Bill Vermillion - bv @ wjv . com

Bill Vermillion wrote:
> But it would have helped a lot more if for your obfuscated names
> you indicated if they were the local SCO machine, machines on
> your local LAN, machines you allow to use your mail server,
> or machines you have no control over.

the only local machine is the yyyyyy.local and all the yyyyy.com is there
domain provided by the ISP. All other systems would be external. The .local
machine is only an outbound which is why the reply to and from are achanged by
sendmail to the yyyy.com address thus allowing the my customers clients to
reply for some reason without getting a bounce back or invalid address.

Hope this clarifies it some.

bk