[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cobalt-users] RE: RaQ3i - Sendmail 8.9.3 configuration issues (was Sendmail upgrade to 8.12.8 issues?)
- Subject: Re: [cobalt-users] RE: RaQ3i - Sendmail 8.9.3 configuration issues (was Sendmail upgrade to 8.12.8 issues?)
- From: Goetz Lohmann <goetz.lohmann@xxxxxx>
- Date: Thu Apr 10 09:55:01 2003
- List-id: Mailing list for users to share thoughts on Sun Cobalt products. <cobalt-users.list.cobalt.com>
Barbara schrieb:
>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..
>
you may also try from a client PC
#> telnet yourdomain.com 25
#> telnet yourdomain.com 110
(leave both with "QUIT")
if your server respond correctly to the ports 25 (SMTP) 110 (POP3)
then login to your box and do:
#> mail -v -s test root < /dev/null
Null message body; hope that's ok
root... aliased to admin
admin... Connecting to local...
admin... Sent
which schould test to send from Server a local email to the user root
(admin)
then try to test to send email from the local Server to an external
email with:
#> mail -v -s test any.name@xxxxxx < /dev/null
Null message body; hope that's ok
any.name@xxxxxxxxx Connecting to mx0.gmx.net. via esmtp...
220 {mx019-rz3} GMX Mailservices ESMTP
>>> EHLO yourdomain.com
250-{mx019-rz3} GMX Mailservices
250 8BITMIME
>>> MAIL From:<admin@xxxxxxxxxxxxxx>
250 {mx019-rz3} ok
>>> RCPT To:<any.name@xxxxxx>
250 {mx019-rz3} ok
>>> DATA
354 {mx019-rz3} Go ahead
>>> .
250 {mx019-rz3} Message accepted
any.name@xxxxxxxxx Sent ({mx019-rz3} Message accepted)
Closing connection to mx0.gmx.net.
>>> QUIT
221 {mx019-rz3} GMX Mailservices
last but not least try running sendmail on an alternate port in debug mode,
do an SMTP session by hand, and examine the debug output carefully.
A typical command line would be|
#> sendmail -d21.15 -bd -OQueueDirectory=/tmp -ODaemonPortOptions=Port=2525
|Then you could telnet to port 2525 on your machine, type
MAIL FROM:foo@xxxxxxx**
(like in the example above) and examine the debug output to see just what
the rules are and aren't matching.
maybe also check the popip.db by typing
#>/usr/local/sbin/poprelayd -p
12.34.56.78
which should give you a list of IP adressess that had recently used POP
to connect to the server, which should be similar to the
in.qpopper[23667]: (v4.0.5) POP login by user "username" at
(12.34.56.78) 12.34.56.78
line of /var/log/maillog if the POPbeforeSMTP would work correctly.
to test it you may insert an IP manualy by typing
#>/usr/local/sbin/poprelayd -a <ip>
regards
--
¸,ø¤°`°¤ø,¸_¸,ø¤°`°¤ø,¸_¸,ø¤°°¤ø,¸_¸,ø¤°`°¤ø,¸_¸,ø¤°°¤ø,¸
Götz Lohmann | D-Mannheim | Web-Developer & Sys-Admin
---------------------------------------------------------
He's the fellow that people wonder what he does and why
the company needs him, until he goes on vacation.
¸,ø¤°`°¤ø,¸_¸,ø¤°`°¤ø,¸_¸,ø¤°°¤ø,¸_¸,ø¤°`°¤ø,¸_¸,ø¤°°¤ø,¸