...making Linux just a little more fun!
Joey Prestia [joey at linuxamd.com]
Hi all,
I am administering a e-mail server running RHEL 5 with sendmail 8.13 and using dovecot imap most of the users are going to need to be able to send mail from their laptops and i have no idea what network they will be utilizing. After looking at http://www.joreybump.com/code/howto/smtpauth.html and following the guide there I was able to get authenticated relay enabled.
I am using saslauthd and never created sasl passwords but following the guide at http://www.joreybump.com/code/howto/smtpauth.html was able to get it working. now after 6 months of no problem and then the other day changed my password to a stronger one now I cannot relay from anywhere.
[root@linuxamd ~]# sasldblistusers2 listusers failed [root@linuxamd ~]# [root@linuxamd ~]# testsaslauthd -u joey -p ****** 0: NO "authentication failed"
is this my problem?
All accounts are stored in /etc/passwd saslauthd is running and I performed a restart of saslauthd with out any errors.
I have tried with both kmail and thunderbird. My usual settings are tls if available and and smtp auth with username and password I thought at first that this was the problem it was using the old password so I removed the default smtp server settings and removed the passwords. So it would force me to manually enter the password again I did this while on another network and tried to send with no success. As soon as I disconnected from the neighboring lan and connected to the local lan it took and sent but I am unsure if it is using auth it seems like it is only sending because its on my lan how would I verify the authentication process is working at all? I am not certain exactly how saslauthd works and have seen nothing unusual in my logs. Thunderbird simply times out when I try to send from other networks and tells me to check my network settings.
Thanks in advance,
-- Joey Prestia L. G. Mirror Coordinator http://linuxamd.com Main Site http://linuxgazette.net
Joey Prestia [joey at linuxamd.com]
Joey Prestia wrote:
> Hi all, > > I am administering a e-mail server running RHEL 5 with sendmail 8.13 and > using dovecot imap most of the users are going to need to be able to > send mail from their laptops and i have no idea what network they will > be utilizing. After looking at > http://www.joreybump.com/code/howto/smtpauth.html and following the > guide there I was able to get authenticated relay enabled. > > I am using saslauthd and never created sasl passwords but > following the guide at http://www.joreybump.com/code/howto/smtpauth.html > was able to get it working. now after 6 months of no problem and then > the other day changed my password to a stronger one now I cannot relay > from anywhere. > > > [root@linuxamd ~]# sasldblistusers2 > listusers failed > [root@linuxamd ~]# > [root@linuxamd ~]# testsaslauthd -u joey -p ****** > 0: NO "authentication failed" > > is this my problem? > > All accounts are stored in /etc/passwd saslauthd is running and I > performed a restart of saslauthd with out any errors. > > I have tried with both kmail and thunderbird. My usual settings are tls > if available and and smtp auth with username and password I thought at > first that this was the problem it was using the old password so I > removed the default smtp server settings and removed the passwords. So > it would force me to manually enter the password again I did this while > on another network and tried to send with no success. As soon as I > disconnected from the neighboring lan and connected to the local lan it > took and sent but I am unsure if it is using auth it seems like it is > only sending because its on my lan how would I verify the authentication > process is working at all? I am not certain exactly how saslauthd > works and have seen nothing unusual in my logs. Thunderbird simply times > out when I try to send from other networks and tells me to check my > network settings. >
A little additional info. I have tried telnet from my lan to my mail server port 25 and no problem and when I try from outside it it just sits there until it times out. I thought this was weird, although all I did was change a password. On attempt to send mail from outside I see no activity in /var/log/maillog except my logging into dovecot imap no sendmail auth attempt at all.
-- Joey Prestia L. G. Mirror Coordinator http://linuxamd.com Main Site http://linuxgazette.net
Ben Okopnik [ben at linuxgazette.net]
On Sat, Jul 05, 2008 at 12:26:03PM -0700, Joey Prestia wrote:
> > A little additional info. I have tried telnet from my lan to my mail > server port 25 and no problem and when I try from outside it it just > sits there until it times out. I thought this was weird, although all I > did was change a password. On attempt to send mail from outside I see > no activity in /var/log/maillog except my logging into dovecot imap no > sendmail auth attempt at all.
This sounds like one of those times when you have to drop the "but I only changed X!" premise and start afresh, as if you didn't know anything about the causes of the problem.
The above telnet problem says, or strongly implies, that you've got something completely unrelated to passwords or SASL; perhaps you have a firewall running that blocks ports 23 and 25. Try that assumption, and see where that takes you. 'netcat' is your friend when it comes to troubleshooting this kind of problems.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *
Joey Prestia [joey at linuxamd.com]
Ben Okopnik wrote:
> On Sat, Jul 05, 2008 at 12:26:03PM -0700, Joey Prestia wrote: >> A little additional info. I have tried telnet from my lan to my mail >> server port 25 and no problem and when I try from outside it it just >> sits there until it times out. I thought this was weird, although all I >> did was change a password. On attempt to send mail from outside I see >> no activity in /var/log/maillog except my logging into dovecot imap no >> sendmail auth attempt at all. > > This sounds like one of those times when you have to drop the "but I > only changed X!" premise and start afresh, as if you didn't know > anything about the causes of the problem. > > The above telnet problem says, or strongly implies, that you've got > something completely unrelated to passwords or SASL; perhaps you have a > firewall running that blocks ports 23 and 25. Try that assumption, and > see where that takes you. 'netcat' is your friend when it comes to > troubleshooting this kind of problems. >
[joey@linuxamd ~]$ netstat -tuna
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address
State
tcp 0 0 127.0.0.1:2208 0.0.0.0:*
LISTEN
tcp 0 0 0.0.0.0:21 0.0.0.0:*
LISTEN
tcp 0 0 0.0.0.0:631 0.0.0.0:*
LISTEN
tcp 0 0 0.0.0.0:25 0.0.0.0:*
LISTEN
tcp 0 0 0.0.0.0:3551 0.0.0.0:*
LISTEN
tcp 0 0 127.0.0.1:2207 0.0.0.0:*
LISTEN
tcp 1 44 192.168.200.101:25 68.14.243.59:37435
CLOSING
tcp 0 0 :::993 :::*
LISTEN
I know I can and am still recieving mail as this is the machine i am using. I never made any changes to iptables. I would think that since telnet is not working to port 25 I shouldn't be receiving mail right at least from any where outside my lan?
-- Joey Prestia L. G. Mirror Coordinator http://linuxamd.com Main Site http://linuxgazette.net
René Pfeiffer [lynx at luchs.at]
On Jul 05, 2008 at 1756 -0400, Ben Okopnik appeared and said:
> [...] > The above telnet problem says, or strongly implies, that you've got > something completely unrelated to passwords or SASL; perhaps you have a > firewall running that blocks ports 23 and 25. Try that assumption, and > see where that takes you. 'netcat' is your friend when it comes to > troubleshooting this kind of problems.
Yes, and I'd add a healthy dose of tethereal/tshark/tcpdump to see what server and client are talking about. It's been ages since I did this configuration with Sendmail and unfortunately I cannot remember how I did this (my backups might, I'll have a look on Monday).
Best, René.
Ben Okopnik [ben at linuxgazette.net]
On Sat, Jul 05, 2008 at 03:17:52PM -0700, Joey Prestia wrote:
> Ben Okopnik wrote: > > On Sat, Jul 05, 2008 at 12:26:03PM -0700, Joey Prestia wrote: > >> A little additional info. I have tried telnet from my lan to my mail > >> server port 25 and no problem and when I try from outside it it just > >> sits there until it times out. I thought this was weird, although all I > >> did was change a password. On attempt to send mail from outside I see > >> no activity in /var/log/maillog except my logging into dovecot imap no > >> sendmail auth attempt at all. > > > > This sounds like one of those times when you have to drop the "but I > > only changed X!" premise and start afresh, as if you didn't know > > anything about the causes of the problem. > > > > The above telnet problem says, or strongly implies, that you've got > > something completely unrelated to passwords or SASL; perhaps you have a > > firewall running that blocks ports 23 and 25. Try that assumption, and > > see where that takes you. 'netcat' is your friend when it comes to > > troubleshooting this kind of problems. > > > > [joey@linuxamd ~]$ netstat -tuna > Active Internet connections (servers and established) > Proto Recv-Q Send-Q Local Address Foreign Address > State > tcp 0 0 127.0.0.1:2208 0.0.0.0:* > LISTEN > tcp 0 0 0.0.0.0:21 0.0.0.0:* > LISTEN > tcp 0 0 0.0.0.0:631 0.0.0.0:* > LISTEN > tcp 0 0 0.0.0.0:25 0.0.0.0:* > LISTEN > tcp 0 0 0.0.0.0:3551 0.0.0.0:* > LISTEN > tcp 0 0 127.0.0.1:2207 0.0.0.0:* > LISTEN > tcp 1 44 192.168.200.101:25 68.14.243.59:37435 > CLOSING > tcp 0 0 :::993 :::* > LISTEN > > I know I can and am still recieving mail as this is the machine i am > using.
I can easily visualize a situation in which this wouldn't mean much. E.g., if you have (as is often the case on large corporate networks) a mailhost sitting on your "border" and talking only to the hosts inside... oh, whoops - I just realized that I just strayed off into la-la land (blame this horrendous sinus infection that I'm battling as a result of having had a camera shoved what felt like several miles up my nose.) Didn't you mention SSL and IMAP? That would be either 465 for SMTP over SSL, or 993 (IMAP over SSL), not 25. What happens when you try to telnet to 993?
> I never made any changes to iptables. I would think that since > telnet is not working to port 25 I shouldn't be receiving mail right at > least from any where outside my lan?
993 is running; that's a route where mail can come in.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *
Joey Prestia [joey at linuxamd.com]
Ben Okopnik wrote:
> On Sat, Jul 05, 2008 at 03:17:52PM -0700, Joey Prestia wrote: >> Ben Okopnik wrote: >>> On Sat, Jul 05, 2008 at 12:26:03PM -0700, Joey Prestia wrote: >>>> A little additional info. I have tried telnet from my lan to my mail >>>> server port 25 and no problem and when I try from outside it it just >>>> sits there until it times out. I thought this was weird, although all I >>>> did was change a password. On attempt to send mail from outside I see >>>> no activity in /var/log/maillog except my logging into dovecot imap no >>>> sendmail auth attempt at all. >>> This sounds like one of those times when you have to drop the "but I >>> only changed X!" premise and start afresh, as if you didn't know >>> anything about the causes of the problem. >>> >>> The above telnet problem says, or strongly implies, that you've got >>> something completely unrelated to passwords or SASL; perhaps you have a >>> firewall running that blocks ports 23 and 25. Try that assumption, and >>> see where that takes you. 'netcat' is your friend when it comes to >>> troubleshooting this kind of problems. >>> >> [joey@linuxamd ~]$ netstat -tuna >> Active Internet connections (servers and established) >> Proto Recv-Q Send-Q Local Address Foreign Address >> State >> tcp 0 0 127.0.0.1:2208 0.0.0.0:* >> LISTEN >> tcp 0 0 0.0.0.0:21 0.0.0.0:* >> LISTEN >> tcp 0 0 0.0.0.0:631 0.0.0.0:* >> LISTEN >> tcp 0 0 0.0.0.0:25 0.0.0.0:* >> LISTEN >> tcp 0 0 0.0.0.0:3551 0.0.0.0:* >> LISTEN >> tcp 0 0 127.0.0.1:2207 0.0.0.0:* >> LISTEN >> tcp 1 44 192.168.200.101:25 68.14.243.59:37435 >> CLOSING >> tcp 0 0 :::993 :::* >> LISTEN >> >> I know I can and am still recieving mail as this is the machine i am >> using. > > I can easily visualize a situation in which this wouldn't mean much. > E.g., if you have (as is often the case on large corporate networks) a > mailhost sitting on your "border" and talking only to the hosts > inside... oh, whoops - I just realized that I just strayed off into > la-la land (blame this horrendous sinus infection that I'm battling as a > result of having had a camera shoved what felt like several miles up my > nose.) Didn't you mention SSL and IMAP? That would be either 465 for > SMTP over SSL, or 993 (IMAP over SSL), not 25. What happens when you try > to telnet to 993? > >> I never made any changes to iptables. I would think that since >> telnet is not working to port 25 I shouldn't be receiving mail right at >> least from any where outside my lan? > > 993 is running; that's a route where mail can come in. > >
[root@linuxamd ~]# telnet localhost 993 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. ehlo localhost Connection closed by foreign host.
When I went and changed the line in /etc/sysconfig/saslauthd that says AUTH=pam to AUTH=shadow and restarted saslauthd I was able to:
[root@linuxamd ~]# testsaslauthd -u joey -p ****** -s smtp 0: OK "Success."
After this I tried and got on another lan to try to send and failed several times. So I tried:
[root@linuxamd ~]# telnet localhost 25 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. 220 linuxamd.com ESMTP Sendmail 8.13.8/8.13.8; Sat, 5 Jul 2008 18:55:50 -0700 ehlo localhost 250-linuxamd.com Hello localhost.localdomain [127.0.0.1], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-STARTTLS 250-DELIVERBY 250 HELP help auth 214-2.0.0 AUTH mechanism [initial-response] 214-2.0.0 Start authentication. 214 2.0.0 End of HELP info starttls 220 2.0.0 Ready to start TLS auth plain am9leQ0k Connection closed by foreign host.
Which is kind of confusing so I changed the saslauthd parameter back to its original value not wanting to perhaps screw something up and restarted saslauthd and found out that
[root@linuxamd ~]# testsaslauthd -u joey -p ****** 0: NO "authentication failed" [root@linuxamd ~]# testsaslauthd -u joey -p ****** -s smtp 0: OK "Success."
I must specify the service (these little things are real important!) So I am back to the drawing board or to scouring search engines and finding very little out there.
-- Joey Prestia L. G. Mirror Coordinator http://linuxamd.com Main Site http://linuxgazette.net
Ben Okopnik [ben at linuxgazette.net]
On Sat, Jul 05, 2008 at 07:05:01PM -0700, Joey Prestia wrote:
> > > > 993 is running; that's a route where mail can come in. > > [root@linuxamd ~]# telnet localhost 993 > Trying 127.0.0.1... > Connected to localhost.localdomain (127.0.0.1). > Escape character is '^]'. > ehlo localhost
No point in that, since you didn't see a welcome banner. Since I don't have any experience troubleshooting IMAP over SSL, I'm going to put 'telnet' in a box marked "maybe or maybe not", and suggest switching over to a tool designed for the job - 'swaks'. Note that you'll also need to install 'libnet-ssleay-perl' if you want to do TLS.
ben@Tyr:~$ swaks -a -tls -q HELO -s linuxgazette.net -au ben -ap '<>' === Trying linuxgazette.net:25... === Connected to linuxgazette.net. <- 220 genetikayos.com ESMTP Sendmail 8.12.11.20060308/8.12.11; Sat, 5 Jul 2008 21:20:05 -0700 -> EHLO localhost <- 250-genetikayos.com Hello 83.sub-70-220-99.myvzw.com [70.220.99.83], pleased to meet you <- 250-ENHANCEDSTATUSCODES <- 250-PIPELINING <- 250-8BITMIME <- 250-SIZE <- 250-DSN <- 250-ETRN <- 250-AUTH GSSAPI <- 250-STARTTLS <- 250-DELIVERBY <- 250 HELP -> STARTTLS <- 220 2.0.0 Ready to start TLS === TLS started w/ cipher DHE-RSA-AES256-SHA ~> EHLO localhost <~ 250-genetikayos.com Hello 83.sub-70-220-99.myvzw.com [70.220.99.83], pleased to meet you <~ 250-ENHANCEDSTATUSCODES <~ 250-PIPELINING <~ 250-8BITMIME <~ 250-SIZE <~ 250-DSN <~ 250-ETRN <~ 250-AUTH GSSAPI LOGIN PLAIN <~ 250-DELIVERBY <~ 250 HELP ~> QUIT <~ 221 2.0.0 genetikayos.com closing connection === Connection closed with remote host.
You should be able to do something similar and see what's going on.
> When I went and changed the line in /etc/sysconfig/saslauthd that says > AUTH=pam to AUTH=shadow and restarted saslauthd I was able to: > > > [root@linuxamd ~]# testsaslauthd -u joey -p ****** -s smtp > 0: OK "Success."
So, it seems like you had/have two problems going at the same time - some sort of networking issue (as demonstrated by the connection timeouts) and an authentication issue (as demonstrated by the auth failure with 'testsaslauthd'.)
> After this I tried and got on another lan to try to send and failed > several times. So I tried: > > [root@linuxamd ~]# telnet localhost 25 > Trying 127.0.0.1... > Connected to localhost.localdomain (127.0.0.1). > Escape character is '^]'. > 220 linuxamd.com ESMTP Sendmail 8.13.8/8.13.8; Sat, 5 Jul 2008 18:55:50 > -0700 > ehlo localhost > 250-linuxamd.com Hello localhost.localdomain [127.0.0.1], pleased to > meet you > 250-ENHANCEDSTATUSCODES > 250-PIPELINING > 250-8BITMIME > 250-SIZE > 250-DSN > 250-ETRN > 250-STARTTLS > 250-DELIVERBY > 250 HELP
[blink] Pardon me... but where is your '250-AUTH DIGEST-MD5 GSSAPI etc' line? This server is very loudly NOT saying "I support the AUTH command." So you can't use one. See the LG example, above, for what I mean.
> help auth > 214-2.0.0 AUTH mechanism [initial-response] > 214-2.0.0 Start authentication. > 214 2.0.0 End of HELP info > starttls > 220 2.0.0 Ready to start TLS > auth plain am9leQ0k > Connection closed by foreign host.
Perhaps giving it a command that it explicitly said it can't handle caused it to give up?
> Which is kind of confusing so I changed the saslauthd parameter back to > its original value not wanting to perhaps screw something up and > restarted saslauthd and found out that > > [root@linuxamd ~]# testsaslauthd -u joey -p ****** > 0: NO "authentication failed" > [root@linuxamd ~]# testsaslauthd -u joey -p ****** -s smtp > 0: OK "Success."
That may be saying "I can connect via SMTP - which doesn't require an authentication method - but I can't via SMTP-AUTH, which does." Which we already knew.
> I must specify the service (these little things are real important!)
I wonder what the default service is? Whatever it is, it's clearly failing.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *
Joey Prestia [joey at linuxamd.com]
Ben Okopnik wrote:
> ``` > ben@Tyr:~$ swaks -a -tls -q HELO -s linuxgazette.net -au ben -ap '<>' > === Trying linuxgazette.net:25... > === Connected to linuxgazette.net. > <- 220 genetikayos.com ESMTP Sendmail 8.12.11.20060308/8.12.11; Sat, 5 Jul 2008 21:20:05 -0700 > -> EHLO localhost > <- 250-genetikayos.com Hello 83.sub-70-220-99.myvzw.com [70.220.99.83], pleased to meet you > <- 250-ENHANCEDSTATUSCODES > <- 250-PIPELINING > <- 250-8BITMIME > <- 250-SIZE > <- 250-DSN > <- 250-ETRN > <- 250-AUTH GSSAPI > <- 250-STARTTLS > <- 250-DELIVERBY > <- 250 HELP > -> STARTTLS > <- 220 2.0.0 Ready to start TLS > === TLS started w/ cipher DHE-RSA-AES256-SHA > ~> EHLO localhost > <~ 250-genetikayos.com Hello 83.sub-70-220-99.myvzw.com [70.220.99.83], pleased to meet you > <~ 250-ENHANCEDSTATUSCODES > <~ 250-PIPELINING > <~ 250-8BITMIME > <~ 250-SIZE > <~ 250-DSN > <~ 250-ETRN > <~ 250-AUTH GSSAPI LOGIN PLAIN > <~ 250-DELIVERBY > <~ 250 HELP > ~> QUIT > <~ 221 2.0.0 genetikayos.com closing connection > === Connection closed with remote host. > ''' > > You should be able to do something similar and see what's going on. > > [blink] Pardon me... but where is your '250-AUTH DIGEST-MD5 GSSAPI > etc' line? This server is very loudly NOT saying "I support the AUTH > command." So you can't use one. See the LG example, above, for what I > mean.
Oh, I had it configured to use tls then auth I got the system to authenticate by this means http://qmail.jms1.net/test-auth.shtml once again on the local network though and could not reproduce it elsewhere here is what transpired with some details obscured
[joey@linuxamd ~]$ openssl s_client -starttls smtp -crlf -connect 127.0.0.1:25 [truncated] --- 220 linuxamd.com ESMTP Sendmail 8.13.8/8.13.8; Sat, 5 Jul 2008 20:05:27 -0700 ehlo localhost 250-linuxamd.com Hello localhost.localdomain [127.0.0.1], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH LOGIN PLAIN 250-DELIVERBY 250 HELP auth plain XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 235 2.0.0 OK Authenticated
It will authenticate on the local network but should every where and I have tried 3 e-mail clients in numerous configurations to try to get it working and still cant send but from the local network?
-- Joey Prestia L. G. Mirror Coordinator http://linuxamd.com Main Site http://linuxgazette.net
Ben Okopnik [ben at linuxgazette.net]
On Sun, Jul 06, 2008 at 10:29:58AM -0700, Joey Prestia wrote:
> Ben Okopnik wrote: > > > [blink] Pardon me... but where is your '250-AUTH DIGEST-MD5 GSSAPI > > etc' line? This server is very loudly NOT saying "I support the AUTH > > command." So you can't use one. See the LG example, above, for what I > > mean. > > Oh, I had it configured to use tls then auth I got the system to > authenticate by this means > http://qmail.jms1.net/test-auth.shtml once again on the local network > though and could not reproduce it elsewhere here is what transpired with > some details obscured > > [joey@linuxamd ~]$ openssl s_client -starttls smtp -crlf -connect > 127.0.0.1:25 > > [truncated] > > --- > 220 linuxamd.com ESMTP Sendmail 8.13.8/8.13.8; Sat, 5 Jul 2008 20:05:27 > -0700 > ehlo localhost > 250-linuxamd.com Hello localhost.localdomain [127.0.0.1], pleased to > meet you > 250-ENHANCEDSTATUSCODES > 250-PIPELINING > 250-8BITMIME > 250-SIZE > 250-DSN > 250-ETRN > 250-AUTH LOGIN PLAIN > 250-DELIVERBY > 250 HELP > auth plain XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > 235 2.0.0 OK Authenticated
OK, so it looks like you've got the authentication part nailed down. What remains is for you to snoop the bits going down the wire when you connect from an outside host, just as René suggested. 'tcpdump' or anything similar should help.
> It will authenticate on the local network but should every where and I > have tried 3 e-mail clients in numerous configurations to try to get it > working and still cant send but from the local network?
Years ago, I used to do PC hardware repair seminars. We used a very simple technique to figure out where the problem was: basically, we disconnected everything (cards, drives, memory, etc.) from the motherboard, then plugged it back in one item at a time (obviously, powering down in between) and listening for the POST error beeps.
Stripping the problem down to its essentials is still an excellent approach - so don't create problems for yourself by adding too much stuff at once. Mail clients aren't the tool you need when you're still having timeout issues.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *
Joey Prestia [joey at linuxamd.com]
Ben Okopnik wrote:
> Stripping the problem down to its essentials is still an excellent > approach - so don't create problems for yourself by adding too much > stuff at once. Mail clients aren't the tool you need when you're still > having timeout issues. > >
Yes you are right I tried swaks and it worked from the lan but not anywhere else as you can see below
[root@station1 ~]# perl swaks -a -tls -q HELO -s linuxamd.com -au joey -ap xxxxxxxx === Trying linuxamd.com:25... * Error connecting 0.0.0.0 to linuxamd.com:25: * IO::Socket::INET: connect: timeout
From what I am seeing I am wondering what I am missing its obviously something at the network level restricting me from authenticating from anywhere else my sendmail.mc is nothing unusual all I changed were the lines:
define(`confAUTH_OPTIONS', `A p')dnl TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl define(`CERT_DIR', `/etc/pki/tls/certs')dnl define(`confCACERT_PATH', `CERT_DIR')dnl define(`confCACERT', `CERT_DIR/sendmail.pem')dnl define(`confSERVER_CERT', `CERT_DIR/sendmail.pem')dnl define(`confSERVER_KEY', `CERT_DIR/sendmail.pem')dnl define(`confCLIENT_CERT', `CERT_DIR/sendmail.pem')dnl define(`confCLIENT_KEY', `CERT_DIR/sendmail.pem')dnl dnl #DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl
my access contains only these lines from what I've been reading I am not sure I really need a relay line for anything else in there some sendmail doc says I may need a relay for auth users but my failure seems to be at the authentication level.
Connect:localhost.localdomain RELAY Connect:localhost RELAY Connect:127.0.0.1 RELAY
-- Joey Prestia L. G. Mirror Coordinator http://linuxamd.com Main Site http://linuxgazette.net
Ben Okopnik [ben at linuxgazette.net]
On Sun, Jul 06, 2008 at 07:58:48PM -0700, Joey Prestia wrote:
> > Yes you are right I tried swaks and it worked from the lan but not > anywhere else as you can see below > > [root@station1 ~]# perl swaks -a -tls -q HELO -s linuxamd.com -au joey > -ap xxxxxxxx > === Trying linuxamd.com:25... > * Error connecting 0.0.0.0 to linuxamd.com:25: > * IO::Socket::INET: connect: timeout
That's really interesting. Why is it saying '0.0.0.0' in the error line? Is your remote host misconfigured? The above connection works just fine for me when I try it.
ben@Tyr:~$ swaks -a -tls -q HELO -s linuxamd.com -au joey -ap '<>' === Trying linuxamd.com:25... === Connected to linuxamd.com. <- 220 linuxamd.com ESMTP Sendmail 8.13.8/8.13.8; Mon, 7 Jul 2008 06:13:24 -0700 -> EHLO localhost <- 250-linuxamd.com Hello 190.sub-70-220-252.myvzw.com [70.220.252.190], pleased to meet you <- 250-ENHANCEDSTATUSCODES <- 250-PIPELINING <- 250-8BITMIME <- 250-SIZE <- 250-DSN <- 250-ETRN <- 250-STARTTLS <- 250-DELIVERBY <- 250 HELP -> STARTTLS <- 220 2.0.0 Ready to start TLS === TLS started w/ cipher DHE-RSA-AES256-SHA ~> EHLO localhost <~ 250-linuxamd.com Hello 190.sub-70-220-252.myvzw.com [70.220.252.190], pleased to meet you <~ 250-ENHANCEDSTATUSCODES <~ 250-PIPELINING <~ 250-8BITMIME <~ 250-SIZE <~ 250-DSN <~ 250-ETRN <~ 250-AUTH LOGIN PLAIN <~ 250-DELIVERBY <~ 250 HELP ~> QUIT <~ 221 2.0.0 linuxamd.com closing connection === Connection closed with remote host.
> From what I am seeing I am wondering what I am missing its obviously > something at the network level restricting me from authenticating from > anywhere else my sendmail.mc is nothing unusual all I changed were the > lines:
Again, since this is at the network level, it doesn't have anything to do with your mail system. I can connect to linuxamd.com and send mail via telnet (you'll see a test message from me in your in-box); that's not the issue. Again, it may be your remote host - especially if you've been using the same "outside" machine for all your testing.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *
Joey Prestia [joey at linuxamd.com]
Ben Okopnik wrote:
> Again, since this is at the network level, it doesn't have anything to > do with your mail system. I can connect to linuxamd.com and send mail > via telnet (you'll see a test message from me in your in-box); that's > not the issue. Again, it may be your remote host - especially if you've > been using the same "outside" machine for all your testing.
That must be it I have been using the same system here I will be able to use a different machine in a couple of hours. The system I have been using is my laptop and it does have a rather strange adaptive firewall enabled on it. I have seen your telnet email in my inbox. I never suspected it to be my laptop. Although I will test it further at the college. Thanks you have been a great help. I will let you know what happens both when from a different machine and with my firewall rules flushed.
Best,
-- Joey Prestia L. G. Mirror Coordinator http://linuxamd.com Main Site http://linuxgazette.net
Ben Okopnik [ben at linuxgazette.net]
On Mon, Jul 07, 2008 at 06:45:57AM -0700, Joey Prestia wrote:
> Ben Okopnik wrote: > > > > > Again, since this is at the network level, it doesn't have anything to > > do with your mail system. I can connect to linuxamd.com and send mail > > via telnet (you'll see a test message from me in your in-box); that's > > not the issue. Again, it may be your remote host - especially if you've > > been using the same "outside" machine for all your testing. > > That must be it I have been using the same system here I will be able to > use a different machine in a couple of hours. The system I have been > using is my laptop and it does have a rather strange adaptive firewall > enabled on it. I have seen your telnet email in my inbox. I never > suspected it to be my laptop. Although I will test it further at the > college. Thanks you have been a great help. I will let you know what > happens both when from a different machine and with my firewall rules > flushed.
I'd also look very carefully at what your laptop uses as its IP address; that '0.0.0.0' as the source address made me very suspicious.
Glad to have been of help, Joey!
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *
Joey Prestia [joey at linuxamd.com]
Ben Okopnik wrote:
> On Mon, Jul 07, 2008 at 06:45:57AM -0700, Joey Prestia wrote: >> Ben Okopnik wrote: >> >>> Again, since this is at the network level, it doesn't have anything to >>> do with your mail system. I can connect to linuxamd.com and send mail >>> via telnet (you'll see a test message from me in your in-box); that's >>> not the issue. Again, it may be your remote host - especially if you've >>> been using the same "outside" machine for all your testing. >> That must be it I have been using the same system here I will be able to >> use a different machine in a couple of hours. The system I have been >> using is my laptop and it does have a rather strange adaptive firewall >> enabled on it. I have seen your telnet email in my inbox. I never >> suspected it to be my laptop. Although I will test it further at the >> college. Thanks you have been a great help. I will let you know what >> happens both when from a different machine and with my firewall rules >> flushed. > > I'd also look very carefully at what your laptop uses as its IP address; > that '0.0.0.0' as the source address made me very suspicious. > > Glad to have been of help, Joey!
Well I'm wondering if this is due to http://www.sendmail.org/tips/pathmtu the MTU packet size being a possible problem. Here at the school we have a real rack mount router and the wireless networks at home are all on those linksys wrt54G's plastic toys the wireless access points we use here are the same but we use them buy plugging them in as a switch to utilize our own DHCP server to hand out IP's so they're not doing any routing. So I am having no problem relaying from here and telnet works fine again. I'm still intrigued by what would cause such a thing. Thanks again.
Best,
-- Joey Prestia L. G. Mirror Coordinator http://linuxamd.com Main Site http://linuxgazette.net
René Pfeiffer [lynx at luchs.at]
On Jul 07, 2008 at 1021 -0700, Joey Prestia appeared and said:
> [...] > Well I'm wondering if this is due to=20 > http://www.sendmail.org/tips/pathmtu the MTU packet size being a=20 > possible problem.
You can check this (or look for MTUs on a specific path) by using the tracepath tool.
nightfall:~# tracepath -h Usage: tracepath [-n] <destination>[/<port>] nightfall:~#
On Debian-based systems it's the iputils-tracepath package. However TCP usually detects the path MTU and adapts accordingly.
Best, René.
Ben Okopnik [ben at linuxgazette.net]
On Mon, Jul 07, 2008 at 10:21:45AM -0700, Joey Prestia wrote:
> > Well I'm wondering if this is due to > http://www.sendmail.org/tips/pathmtu the MTU packet size being a > possible problem.
Unless you have a specific reason for suspecting the MTU, I'd stick with tracking down and solving the problems you already know about. Besides, here's what MTU discovery looks like for your host:
ben@Tyr:~$ sudo hping2 --icmp --count 5 --data 1472 --dontfrag linuxamd.com HPING linuxamd.com (ppp0 70.167.208.132): icmp mode set, 28 headers + 1472 data bytes 1500 bytes from 70.167.208.132: icmp_seq=0 ttl=48 id=17868 rtt=449.6 ms 1500 bytes from 70.167.208.132: icmp_seq=1 ttl=48 id=17870 rtt=452.2 ms 1500 bytes from 70.167.208.132: icmp_seq=2 ttl=48 id=17872 rtt=509.1 ms 1500 bytes from 70.167.208.132: icmp_seq=3 ttl=48 id=17874 rtt=506.1 ms 1500 bytes from 70.167.208.132: icmp_seq=4 ttl=48 id=17876 rtt=498.0 ms --- linuxamd.com hping statistic --- 5 packets tramitted, 5 packets received, 0% packet loss round-trip min/avg/max = 449.6/483.0/509.1 ms Press any key to continue... ben@Tyr:~$ sudo hping2 --icmp --count 5 --data 1473 --dontfrag linuxamd.com HPING linuxamd.com (ppp0 70.167.208.132): icmp mode set, 28 headers + 1473 data bytes --- linuxamd.com hping statistic --- 5 packets tramitted, 0 packets received, 100% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms
Your routers pass 1500-byte packets - which is a standard MTU. Don't go
chasing ghosts. 
> Here at the school we have a real rack mount router > and the wireless networks at home are all on those linksys wrt54G's > plastic toys the wireless access points we use here are the same but we > use them buy plugging them in as a switch to utilize our own DHCP server > to hand out IP's so they're not doing any routing. So I am having no > problem relaying from here and telnet works fine again. I'm still > intrigued by what would cause such a thing. Thanks again.
Perhaps misconfigured network settings on the laptop? Sounding more and more like it all the time.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *
Ben Okopnik [ben at linuxgazette.net]
On Mon, Jul 07, 2008 at 08:28:39PM +0200, René Pfeiffer wrote:
> On Jul 07, 2008 at 1021 -0700, Joey Prestia appeared and said: > > [...] > > Well I'm wondering if this is due to > > http://www.sendmail.org/tips/pathmtu the MTU packet size being a > > possible problem. > > You can check this (or look for MTUs on a specific path) by using the > tracepath tool. > > nightfall:~# tracepath -h > Usage: tracepath [-n] <destination>[/<port>] > nightfall:~# > > On Debian-based systems it's the iputils-tracepath package. However TCP > usually detects the path MTU and adapts accordingly.
As I recall, MTU discovery 1) is done via ICMP and 2) uses the "don't fragment" flag. The problems appear when intermediate routers have a too-small MTU set. The only reason I remember this is because I ran into it just as cheap user-end routers started appearing on the market - and one of them (Cisco, maybe? I don't recall exactly) gave me a nightmarishly-hard time at a client's place. I could ping between the two hosts, I could telnet from one to the other... but their security camera feed wouldn't work. I thought I was going to lose my mind on that job.
(I realize that there will be the inevitable "So when did it happen?" questions, but I'll save that story for another day.)
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *