[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [cobalt-users] RE: RaQ3i - Sendmail 8.9.3 configuration issues
- Subject: RE: [cobalt-users] RE: RaQ3i - Sendmail 8.9.3 configuration issues
- From: "Dave Reid" <daver1@xxxxxxxxxxxxxxx>
- Date: Thu Mar 27 14:56:02 2003
- List-id: Mailing list for users to share thoughts on Sun Cobalt products. <cobalt-users.list.cobalt.com>
|> -----Original Message-----
|> From: cobalt-users-admin@xxxxxxxxxxxxxxx
|> [mailto:cobalt-users-admin@xxxxxxxxxxxxxxx] On Behalf Of Barbara
|> Sent: Thursday, March 27, 2003 12:03 PM
|> To: cobalt-users@xxxxxxxxxxxxxxx
|> Subject: [cobalt-users] RE: RaQ3i - Sendmail 8.9.3
|> configuration issues (was Sendmail upgrade to 8.12.8 issues?)
|>
|>
|> Hi,
|>
|> I suspect your issues have -nothing- to do with "POP
|> before Relay/SMTP". I'm not trying to be harsh, but in
|> your post you state:
|>
|> >I had replied in a previous message that "POP
|> >before SMTP" is installed but has never worked
|> >properly, The first time I turned the feature
|> >on and tried to access my email, portsentry locked
|> >me out (I did not have a static IP at the time to
|> >add to the hosts.allow file).
|>
|> First, the "POP before Relay/SMTP" has -nothing- to do
|> with Portsentry, nor a static IP, nor the hosts.allow
|> file what so ever.. Nor does portsentry have anything
|> to do with the hosts.allow file, unless of course
|> you've configured it to add any dropped hosts to the
|> hosts.allow file when scanned. But even then, the host.allow
|> file is only read after the hosts.deny file and should -not-
|> be blocking (locking) out your connection while attempting
|> to check mail from the server.
|>
|> The fact that you locked yourself out of the machine
|> when trying to check mail indicates some misconfigured
|> elements of your setup. Meaning, (again) portsentry
|> should -NOT- be blocking (locking) out a connection
|> when trying to pop the mail server. If it is, then
|> there lies your first problem. You can't possibly
|> check mail off a system -and hence have pop before
|> SMTP work properly if you can't even pop the server
|> correctly. If Portsentry blocked (locked out) that
|> connection for what-ever reason, you need to resolve
|> that issue first.
|>
|> My advice would be to first disable (turn-off) your
|> Portsentry, remove any entries from your hosts.allow
|> and hosts.deny files if you currently have entries
|> there -and start fresh. I really wouldn't go messing
|> around with the redhat.mc file at this time, as it
|> truly is not the problem... Madam Cleo sees great
|> ugliness in your future if you start playing with that
|> file.. Turn off Portsentry, clear your
|> hosts.allow/deny files, make sure your POP before
|> Relay option is checked via the GUI, make sure your
|> "allow authentication" is enabled in your MTU (Outlook
|> or what ever) and start from there. ;-)
|>
|> Good luck to ya..
|>
|> Barbara
************************* reply ********************
I appreciate your suggestions, but Pop before SMTP was not my original
issue, I had only mentioned it because someone had suggested I use it
and I am aware that port sentry has nothing to do with pop before relay
per se. As to disabling port sentry, that would be catastrophic judging
by the thousands of hack attempts per day it stops. The reason I have my
IP number in the hosts.allow file is that in case I have an oops, I
don't get locked out of my server. As for the order of when hosts.allow
and hosts.deny are processed, on this box anyway, the hosts.allow is
read first - I have tested this by adding a test IP to both files, and
the fact that I still have access, that means the hosts.allow is being
processed first. Also, I have no problem getting normal POP3 mail, it
only stops working when I turn pop before SMTP on, and I had the outlook
set as you suggest.
All this aside, I have another more pressing issue that I need to solve
first and was the original issue I sent in a question about. For those
who missed it, here is the issue at hand I am trying to resolve. When I
or another client we host tries to send an email to a domain we do not
host they get a "Relaying Denied" error, adding that domain to the
"Allowed Host Relay section" in the gui allows the mail to go through,
but I should not have to do this to have email go through, and of course
it makes my server more vulnerable to SPAMMERS raping my server for
every relay I add (which I recently experienced, prompting me to seek
help here). Theoretically sendmail should allow any domain we host to
send email to any emailadress@xxxxxxxxxx they want to without me having
to explicitly allow that domain in the relay section. We run our own
DNS, and for every domain we host I have 3 basic entries in the DNS
settings in the gui (aside from SOA) for example;
============ example of virtual domain ==================
hieto.com -> 64.27.106.203 (A Record)
www.hieto.com -> 64.27.106.203 (A Record)
www.hieto.com mail is sent to the high priority mail server hieto.com
(MX Entry)
I included the redhat.mc file in the previous email to see if anyone
could spot something amiss, and to confirm if it should have the
relay_based_on_MX feature in there. I can include the sendmail.cf file
any anyone wants to see it. It seems to me that it would have to either
a DNS issue or a sendmail configuration issue. I just don't know enough
about it to know for sure. I have been suffering with this for years,
before I had the RaQ3, I had a RaQ2 which had the same issue, so I
though it was a quirk of the Cobalt boxes, but as I have been informed
recently - this should not be the case. Please, someone - HELP! I have
about 100 clients affected by this issue. Thanx everyone for all the
comments and assistance so far, it has been very helpful in me getting a
handle on my server.
*************************************************
* Regards, Dave Reid - President *
* dave@xxxxxxxxxxxxxx, www.gia-online.net *
* Ph: 780-513-8918, Fax: 780-402-7171 *
* High Speed Web Hosting - Corporate Web Design *
* On-Line Databases - E-Commerce *
* Flash, Animation, Graphics *
*************************************************