Question : Relaying Denied

Hi
A couple of days ago a person from the staff of another IT department contact me to told me that he was having trouble while sending mail to my corporate email accounts.

The message he got was the following:

"   The following recipient(s) could not be reached:
[email protected] on 26/09/2005 08:35 a.m.
The e-mail system was unable to deliver the message, but did not report a specific reason.  
Check the address and try again.  
If it still fails, contact your system administrator.
barracuda.test.com #5.0.0 X-Spam-Firewall; host telenet.guate.net[200.12.XX.XX] said:  
 550 5.7.1 ... Relaying denied.

IP name possibly forged [216.230.155.146] (in reply to RCPT TO command)"

so... he told me that this was because of the configuration of my firewall, because it might be doing "reverse lookups" and it was blocking incoming SMTP.  
Well, I dont have a SMTP server in my company, The external email is provided by www.ipowerweb.net, so, i contacted them and they told me that this might be a problem on the sender's side (not on theirs).

How can I detect where the problem is actually being caused??? I think that the problem is on their outgoing smtp server and not on my hosting provider's SMTP server.

Thanks

Answer : Relaying Denied

The error is that "relaying" is denied; if SMTP is sendmail, this indicates that the SMTP does not consider camisas-arrow.com to be a "local" domain, it would need to "relay" the message on to another SMTP server. Relaying will invoke different rulesets than Accepting.  In general, default sendmail installations will use MX lookups to detrmine how to route mail for non-local domains.  For internet domains, the MX record(s) should be pointing to public IPs, preferably with a corresponding PTR records, of routers that forward email related ports to internal mail servers.  In any case, to work correctly the "hostname" is what is important.  If the MX for mydomain.com is smtp.mydomain.com and smtp.mydomain.com resolves to 12.201.14.201, whatever box is eventually accepting those SMTP connections, will want to think that it is smtp.mydomain.com, or at least that it should accept mail for that domain. Otherwise, it is being asked to "relay" the mail to a server that is responsible for that domain.  The fact that you are seeing "IP name possibly forged" indicates that a reverse DNS lookup for the sending host is not the same as its forward lookup for hostname/alias.  This is typical for ISP "dynamic" clients, i.e. dialup. cable modem. DSL. A business gets a DSL link and they get someone to point www.mydomian.com and mail.mydomain.com to that IP.  A PTR record lookup will return something like 12-201-14-201.dsl.swbell.net, so they don't match.  Many people base their access.db (sendmails "who-to-relay-for") list, on domain names, so any host whose forward IP-to-Name lookup returns a hostname with a specific domain name is allowed to relay. The problem arises when a forward lookup for say, mail.mydomain.com retruns a public IP and a reverse for that IP does not return mail.mydomain.com, but something like 12-201-14-201.dsl.swbell.net.  In this case, sendmail will not relay, because ti will first try to validate the origin IP address by doing a reverse lookup.
Hope this helps