Hi People,

I have a very strange error (well to me it is strange anyway).

We have a problem sending email via our domain which is hosted remotely on a dedicated server (which we are responsible for maintaining) but it only happens in specific situations.

To simplify the story, here is the setup:

A laptop roaming and using an internet connections at an-isp.com can send and receive email. It sends email using our dedicated server's SMTP without a problem.

A desktop in the office connected to another-big-isp.com cannot send an email using our server's SMTP, it receives an error like this : "5.7.1 <recipient@somewhere.co.uk>... Relaying denied. IP name possibly forged [xxx.xxx.xxx.xxx]".

Of course, the desktop can send email using the SMTP servers of another-big-isp.com.

The dedicated server is running Fedora 5 and Sendmail.

One strange symptom is that the desktop can send and email using our dedicated server SMTP provided it is destined for an email address at another-big-isp.com.

The only common denominator seems to be another-big-isp.com who are telling us that there are no blocked ports or anything else.

Has anybody got any ideas ?

I would greatly appreciate a clue or two.

You're probably getting greylisted. Basically that just means that there is a problem with your server settings somewhere that's annoying the SMTP server on the other end. Usually this turns out to be a hostname or mangled headers problem.

Usually the maillog has something helpful or try 'sendmail -q -v' to see exactly what the server is doing.

That error makes me think that there is a DN issue with the sent mails. Take a good look at the sender in mailq, there might be a hint there.

Thanks for taking the time to reply kolodz1.

Unless I misunderstand, (which wouldn't surprise me) the sender is not getting as far as the SMTP server accepting the email. This looks like an authentication issue.

Is there some way I can confirm this ?

Thanks for reading.

There's always the Fun-fun telnet way. This should work in any linux terminal or XP terminal. If you use vista, telnet might not be installed depending on the version.

The from and to can be the same. Though that makes for a pretty thin test. The two periods at the end depend on the SMTP server you use, it may be one it may be to. You should see a "250 OK - something" for each line, except data which should be a 354. Once your done type This is basically what email clients do when they send mail, so you can tell where the problem is by what line you end at.

If its an authentication issue, you'll get asked for credentials or told whats missing.

If it fails at the Helo, you probably have a DN issue.

If its something else you're in for some fun.
A good example here, plus helpful info : http://www.netadmintools.com/art276.html

Yes it is.

The client computer has got a wrong smtp server address.
When you sending e-mail through smtp you need to login to that server whatever is an ISP or local server. The sender client needs to be authenticated or it has to be on the relay list in sendmail.

Eg.:

/etc/mail/relay:

Connect: 192.168.10.1 RELAY
Connect: MY.LOCAL.PC.ADDRESS RELAY

Another way as I mentioned it above the client authentication.
Setup on the mail reader client that "My outgoing server(SMTP) requires authentication with user name and password.

Laz.

Many thanks for your suggestions people.

The telnet session to the server does work.

Further digging around suggests that this is just an authentication issue. I think the problem is with SASL so I am hunting around for some guidance with testing that.

I will get back when I get somewhere.

Thanks for your patience