Re: [cobalt-users] problems with Qube3 (was Macintosh, AppleShare IP Users)

["Graphics 800" <graphics@xxxxxxxxxxxxxx>]

Thanks to Rodolfo, Gary and all another postings

Like a Gary, sysadmin isn't my direct job, and because I'm novice in Linux,
I  didn't manage changes in hosts file so far.
And it is not so bad because SUN resolve my problem:) - the latest Qube's
rpm update fix SMTP delaying.

> Try the following from your Qube, assuming you (the mail client) are
> joe.domain.com and 111.222.333.444:
>
> [qube]# host joe.domain.com
> [qube]# host 111.222.333.444

Both of them gived an error  message. I added my host to Qube's DNS server
(A and PTR records).
Both commands now see me, but SMTP delaying remains the same then.


>Touching on a comment made recently (not sure whether by you or someone
>else), which said "I sure hope Cobalt issues fixes for this and other
>issues soon," I'd like to suggest that, although Cobalt does need to
>improve, it is usually (a) beneficial and/or (b) educational to investigate
>the crap out of anything you find. You'll either fix it yourself or learn a
>lot while doing it. And some things *aren't* their fault.

Yep. I'm digging in the Linux:)

Thanks
Arnis


----- Original Message -----
From: "Rodolfo J. Paiz" <rpaiz@xxxxxxxxxxxxxx>
To: <cobalt-users@xxxxxxxxxxxxxxx>
Sent: Thursday, April 05, 2001 8:35 PM
Subject: Re: [cobalt-users] problems with Qube3 (was Macintosh, AppleShare
IP Users)


> At 4/5/01 08:45 PM +0200, you wrote:
> > > This may or may not apply to you, but the most frequently seen cause
of
> > > this problem is improper reverse DNS resolution. If you do not know
what
> > > this is, can't figure it out, or need more help, post again (can't
give
> > > more detail 'cause I'm late for a deadline).
> > >
> > > Most common symptom is that mail goes through perfectly but after a
long
> > > delay, like 90 seconds. (To most people that feels like a long time.)
> > >
> >
> >Exactly. However symptoms remain even if SMTP server is specified by IP
> >number.
> >
> >Can you in simple words tell what can be wrong with reverse DNS resolutio
n?
>
> (Throughout this discussion, I'm going to assume that reverse DNS is in
> fact your problem. It may not be, but this is the only way we're going to
> find out.)
>
> What you're avoiding by inputting the IP address is one name->number
> conversion done by DNS. However, your problem lies with sendmail, who is
> trying to protect you from spammers who send to you and spammers who want
> to use your server to send their shit everywhere, probably crippling your
> server in the process.
>
> Sendmail can do several checks; like hosts.allow and hosts.deny, some
> checks are to see if it should specifically allow the mail to be relayed,
> and some are to see whether it should specifically reject the mail.
>
> So, sendmail gets your IP address from the packet headers (not from
> anything you tell it), and does a reverse-DNS lookup on it (number->name).
> Why? It's trying to see whether this IP address belongs to a domain that
it
> *is* allowed to relay for, and this is one of the things it checks (an
> allow check).
>
> Note that the *absence* of reverse DNS is the problem here. If you had
> reverse DNS properly set up, and the server was allowed to relay from
> domain.com, and the reverse DNS converted 111.222.333.444 ->
> joe.domain.com, then sendmail would allow the relay.
>
> But since you don't have any, sendmail is waiting for the reverse-DNS
query
> to time out, at which point it shrugs and goes on to another check. Since
> your mail is going through, it means one of those checks is being passed.
>
> Try the following from your Qube, assuming you (the mail client) are
> joe.domain.com and 111.222.333.444:
>
> [qube]# host joe.domain.com
> [qube]# host 111.222.333.444
>
> The host command will convert name->number or number->name (depending on
> what you give it) using the Qube's default nameservers. Also read the man
> pages for nslookup and dig, they're useful tools too.
>
> Both of these queries should give answers quite quickly. In your case, I'm
> guessing that the second will not return an answer quickly, but rather
will
> time out and say something nasty.
>
> Try this, and let's see what happens. Post the results (but change the
> domain and IP info to bogus stuff).
>
>
> --
> Rodolfo J. Paiz
> rpaiz@xxxxxxxxxxxxxx
>
> _______________________________________________
> cobalt-users mailing list
> cobalt-users@xxxxxxxxxxxxxxx
> To Subscribe or Unsubscribe, please go to:
> http://list.cobalt.com/mailman/listinfo/cobalt-users
>