I just did a new FC9 (fully updated) install, and it regularly rejects outgoing mail with the subject error message. The address does resolve, of course, so I'm not sure what it means instead of what it says.
The nameservers in /etc/resolv.conf are the authoritative DNS for the domain, both are up, etc.
Someone have a clue?
Check your samba filters.
Regards, Les H On Fri, 2008-11-14 at 09:55 -0500, Bill Davidsen wrote:
I just did a new FC9 (fully updated) install, and it regularly rejects outgoing mail with the subject error message. The address does resolve, of course, so I'm not sure what it means instead of what it says.
The nameservers in /etc/resolv.conf are the authoritative DNS for the domain, both are up, etc.
Someone have a clue?
-- Bill Davidsen davidsen@tmr.com "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot
Les wrote:
Check your samba filters.
Samba is not even installed, this is a non-Windows environment. The message is coming out of sendmail after submission of the mail via SMTP.
Regards, Les H On Fri, 2008-11-14 at 09:55 -0500, Bill Davidsen wrote:
I just did a new FC9 (fully updated) install, and it regularly rejects outgoing mail with the subject error message. The address does resolve, of course, so I'm not sure what it means instead of what it says.
The nameservers in /etc/resolv.conf are the authoritative DNS for the domain, both are up, etc.
Someone have a clue?
Bill Davidsen wrote:
I just did a new FC9 (fully updated) install, and it regularly rejects outgoing mail with the subject error message. The address does resolve, of course, so I'm not sure what it means instead of what it says.
The nameservers in /etc/resolv.conf are the authoritative DNS for the domain, both are up, etc.
Someone have a clue?
Do reverse lookups work?
Often, forward lookups work and reverse do not, ie:
host domain.name vs host NNN.NNN.NNN.NNN
Sendmail is trying to do a reverse lookup.
It will tell you in the error message which host name or IP does not resolve. Check it both ways.
Good luck!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Bill Davidsen wrote:
The nameservers in /etc/resolv.conf are the authoritative DNS for the domain, both are up, etc.
mind posting your /etc/resolv.conf - -- peace out.
tc,hago.
g .
in a free world without fences, who needs gates.
learn linux: 'Rute User's Tutorial and Exposition' http://rute.2038bug.com/index.html.gz 'The Linux Documentation Project' http://www.tldp.org/ 'LDP HOWTO-index' http://www.tldp.org/HOWTO/HOWTO-INDEX/index.html 'HowtoForge' http://howtoforge.com/
g wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Bill Davidsen wrote:
The nameservers in /etc/resolv.conf are the authoritative DNS for the domain, both are up, etc.
mind posting your /etc/resolv.conf
==========
# generated by NetworkManager, do not edit!
domain tmr.com
search tmr.com
nameserver 192.168.12.100 nameserver 192.168.12.101
==========
The machine is behind the firewall, everything gets NAT to one of the static IPs we use.
On Fri, 2008-11-14 at 15:07 -0500, Bill Davidsen wrote:
g wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Bill Davidsen wrote:
The nameservers in /etc/resolv.conf are the authoritative DNS for the domain, both are up, etc.
mind posting your /etc/resolv.conf
==========
# generated by NetworkManager, do not edit!
domain tmr.com
search tmr.com
nameserver 192.168.12.100 nameserver 192.168.12.101
This is actually pretty useless without seeing the named config file on 192.168.12.100 (and 101 I guess). As someone else already said, it's likely to be a reverse lookup failure.
poc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Patrick O'Callaghan wrote:
On Fri, 2008-11-14 at 15:07 -0500, Bill Davidsen wrote:
g wrote:
Bill Davidsen wrote:
The nameservers in /etc/resolv.conf are the authoritative DNS for the domain, both are up, etc.
mind posting your /etc/resolv.conf
# generated by NetworkManager, do not edit! domain tmr.com search tmr.com nameserver 192.168.12.100 nameserver 192.168.12.101
This is actually pretty useless without seeing the named config file on 192.168.12.100 (and 101 I guess). As someone else already said, it's likely to be a reverse lookup failure.
correct, you are.
[after posting, my dead ass crashed after 3 days and 2 sleep periods of less than 3 hours. fingers were not following thinking.]
should have been, "mind posting your /etc/resolv.conf of servers."
have a look at them to insure you are resolving correctly.
firewall making a change?
reboot of servers and your system, [i know, a lot of trouble, but.]
view returned message in full view and note headers to insure that proper address is being applied. also, note error number.
- -- peace out.
tc,hago.
g .
in a free world without fences, who needs gates.
learn linux: 'Rute User's Tutorial and Exposition' http://rute.2038bug.com/index.html.gz 'The Linux Documentation Project' http://www.tldp.org/ 'LDP HOWTO-index' http://www.tldp.org/HOWTO/HOWTO-INDEX/index.html 'HowtoForge' http://howtoforge.com/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
[resend]
Patrick O'Callaghan wrote:
On Fri, 2008-11-14 at 15:07 -0500, Bill Davidsen wrote:
g wrote:
Bill Davidsen wrote:
The nameservers in /etc/resolv.conf are the authoritative DNS for the domain, both are up, etc.
mind posting your /etc/resolv.conf
# generated by NetworkManager, do not edit! domain tmr.com search tmr.com nameserver 192.168.12.100 nameserver 192.168.12.101
This is actually pretty useless without seeing the named config file on 192.168.12.100 (and 101 I guess). As someone else already said, it's likely to be a reverse lookup failure.
correct, you are.
[after posting, my dead butt crashed after 3 days and 2 sleep periods of less than 3 hours. fingers were not following thinking.]
should have been, "mind posting your /etc/resolv.conf of servers."
have a look at them to insure you are resolving correctly.
firewall making a change?
reboot of servers and your system, [i know, a lot of trouble, but.]
view returned message in full view and note headers to insure that proper address is being applied. also, note error number.
- -- peace out.
tc,hago.
g .
in a free world without fences, who needs gates.
learn linux: 'Rute User's Tutorial and Exposition' http://rute.2038bug.com/index.html.gz 'The Linux Documentation Project' http://www.tldp.org/ 'LDP HOWTO-index' http://www.tldp.org/HOWTO/HOWTO-INDEX/index.html 'HowtoForge' http://howtoforge.com/
Bill Davidsen wrote:
I just did a new FC9 (fully updated) install, and it regularly rejects outgoing mail with the subject error message. The address does resolve, of course, so I'm not sure what it means instead of what it says.
Take the domain from the error message and run "host <domain>" on the command line, on the server that's rejecting the mail.
If you're sending mail from a host whose name does not resolve publicly, then the error that you're seeing is probably reported by mail servers outside your network that don't have access to your name servers.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Patrick O'Callaghan wrote:
On Sat, 2008-11-15 at 01:40 +0000, g wrote:
should have been, "mind posting your /etc/resolv.conf of servers."
I think you mean the /etc/named.conf file.
you may well be right. do not have it on this system. - -- peace out.
tc,hago.
g .
in a free world without fences, who needs gates.
learn linux: 'Rute User's Tutorial and Exposition' http://rute.2038bug.com/index.html.gz 'The Linux Documentation Project' http://www.tldp.org/ 'LDP HOWTO-index' http://www.tldp.org/HOWTO/HOWTO-INDEX/index.html 'HowtoForge' http://howtoforge.com/
Patrick O'Callaghan wrote:
On Fri, 2008-11-14 at 15:07 -0500, Bill Davidsen wrote:
g wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Bill Davidsen wrote:
The nameservers in /etc/resolv.conf are the authoritative DNS for the domain, both are up, etc.
mind posting your /etc/resolv.conf
==========
# generated by NetworkManager, do not edit!
domain tmr.com
search tmr.com
nameserver 192.168.12.100 nameserver 192.168.12.101
This is actually pretty useless without seeing the named config file on 192.168.12.100 (and 101 I guess). As someone else already said, it's likely to be a reverse lookup failure.
Actually a "I've been down with pneumonia for almost three weeks and tried to configure three servers in a day" error. No lookup issues, these are the IPs of my internal DNS for this (tmr.com) domain. And it works for ~12 other systems just fine.
What happened was that when I configured the system to accept mail on any IP, I whizzed thru sendmail.mc, changed a number of things, including LOCAL_DOMAIN, changing localhost.localdomain to tmr.com. After I noted with wireshark that it not only wasn't failing, but not even asking, the penny dropped. Stuck "dnl" at the start of the line, ran make, restarted sendmail, all works.
That's what comes from trying to do "something easy" when you are recovering from being sick, pure operator error. I only admit it in case someone else shoots themselves in the same foot.
Thanks for all of the fine suggestions and comments!
[snip]
I'm seeing a slightly different error:
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed:
philipp...@redfish-solutions.com (generated from xyzzy@users.sourceforge.net) SMTP error from remote mail server after RCPT TO:philipp...@redfish-solutions.com: host mail.redfish-solutions.com [66.232.79.143]: 553 5.1.8 philipp...@redfish-solutions.com... Domain of sender address philipp...@redfish-solutions.com does not exist
This is on an externally generated email that is coming into my domain (redfish-solutions.com). The mailbox name is valid (it's been munged here to protect against spam address harvesters).
Looked at the cf/cf/generic-linux.cf briefly, but it's been too long since I've munged .cf files (these days I cop out and us the .mc versions instead).
What's going on, and how do I fix it?
Thanks,
-Philip