As my customer says it is an odd problem - is it DST, DNS or what? (long) - SCO

This is a discussion on As my customer says it is an odd problem - is it DST, DNS or what? (long) - SCO ; 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 ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: As my customer says it is an odd problem - is it DST, DNS or what? (long)

  1. As my customer says it is an odd problem - is it DST, DNS or what? (long)

    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


  2. Re: As my customer says it is an odd problem - is it DST, DNS or what? (long)

    In article ,
    Brian Keener 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

  3. Re: As my customer says it is an odd problem - is it DST, DNS or what? (long)

    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.


  4. Re: As my customer says it is an odd problem - is it DST, DNS or what? (long)

    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"
    To:
    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 ... 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"

    Sender: root@xxxxsco.yyyyyyyyyyyyy.local
    Subject: Failed mail (msg.aa25635)
    To: Orphanage
    Message-ID: <200702061500.aa25644@xxxxsco.yyyyyyyyyyyyy.local>
    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"

    Subject: Bad address in alias
    To: root@xxxxsco.yyyyyyyyyyyyy.local
    Message-ID: <200701311318.aa09336@xxxxsco.yyyyyyyyyyyyy.local>
    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


  5. Re: As my customer says it is an odd problem - is it DST, DNS or what? (long)

    In article ,
    Brian Keener 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"
    >To:
    >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 ... 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"
    >
    >Sender: root@xxxxsco.yyyyyyyyyyyyy.local
    >Subject: Failed mail (msg.aa25635)
    >To: Orphanage
    >Message-ID: <200702061500.aa25644@xxxxsco.yyyyyyyyyyyyy.local>
    >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"
    >
    >Subject: Bad address in alias
    >To: root@xxxxsco.yyyyyyyyyyyyy.local
    >Message-ID: <200701311318.aa09336@xxxxsco.yyyyyyyyyyyyy.local>
    >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

  6. Re: As my customer says it is an odd problem - is it DST, DNS or what? (long)

    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


+ Reply to Thread