I'm a little confused by your post. We are using 1.8.9.5. I have smtp authentication checked, and "use pop3 usernames...". If someone from outside (non-local from address) was to send an email to our server, where one or more of the "to" email addresses are not local, it fails because they did not authenticate.

Did you say that your email account does not have a password? I'd suspect that you're having a problem because you never set up passwords on the server. Authentication implies a userid AND a password. If you have no password, there is no reason to authenticate, because the server is effectively "open"..

Set passwords everywhere they should be, and see if that resolves the issue.

HTH

Oh, another thing.. under sender rules, check "relay only if sender has an account on this server".. that should stop the issue you're seeing...

HTH

Ok, I've been at this same problem for days now and must conclude that there in fact *is* a problem with unauthorized sending of email.
I've setup smtp authentication for sending email using pop3 accounts, used the sender rules, used ptr lookup protectio, spamhouse and what not. It all seems to work: as long as you use POP3 protocol or target non-local emailaddresses! In the log I see traces of colleagues logging in with Outlook and sending email, but also ip-addresses from Brazil and Poland sending email to local users without authentication.
As a test I used telnet and was able to successfully send mail to users of the domains within the mailserver *without any authentication*.
telnet mail.myserver.com 25
ehlo google.com
mail from: eric@google.com
Nothing to say......
.

And voila: message sent.

So you are saying that your email server is working as it should, right? Outside servers must be able to send an email to internal users without authenticating... After all, that's how your server is able to send an email to someone else.....(do any of these outside servers know what usernames/passwords are set on your server?)

What is important, is that outside servers cannot pretend to be a local user, relaying email to somewhere else. That's where the authentication comes in.

Rules:

1) If an outside server is sending to a local address, no authentication will occur...

2) if a local address is sending to another local address, no authentication needs to occur..(this is a spam problem)..

3) if a local address is sending to a non-local address, authentication MUST occur...

If you have sender rules set to only "relay only if sender has an account on this server", and smtp authentication set to use pop3 accounts/passwords, you will be properly protected.

HTH

Thank you for clearing things up Matt: much appreciated!

Thanks for your help everybody - unfortunately I've not been able to repeat the behavior. I understand SMTP authentication is not required for inbound SMTP traffic (otherwise we'd receive no incoming email whatsoever LOL). It seems I was able to get email out to a (my) yahoo account one time by including a local recipient in the To: field (ahead of the yahoo one) to get the server to accept it, and simply ignored the authentication prompt from my Outlook when it popped up (watching the server log, I see #### bytes had already been accepted at that point, which means it had made it to the server, something that wouldn't have happened in the first place if there'd been no local recipient specified). In cleaning up the numerous test emails it looks like I turned bonehead and inadvertently deleted the email that had made it through so I have nothing to work off of, diagnose, etc.

As far as checking to allow only relay if the sender has an account, the version we're using doesn't have that option - I'm guessing because of its age. I'm using SMTP authentication (POP3 names & passwords, and in NO case to I allow passwords to match the user names...a security issue on one prior occasion.) And all the issues I've had along these lines also originate off-shore - my latest batch tracked to a Polish IP address, and interestingly enough TARGETED predominantly foreign TLD's (it, fr, cn, br, jp, etc.)

Also, while I DO suspect compromised account credentials on another issue (and am logging all SMTP commands and exchanges), it is a separate matter from this one.

Eh...as I said...thank you all once again for your help and efforts. We will eventually be migrating our email duties over to a new server, and most likely coming up to speed with the latest version of the email server (if only to get the ability to save sent emails at the server level, something that is becoming more of an issue for off-site people using the web interface) - it is still far-and-away my favorite one.

Jeff