4 posts / 0 new
Last post
#1 Thu, 06/15/2006 - 18:53

SMTP Failing

All of a sudden our outgoing mail is failing. Client gets an error on password. We have traced down an odd item. Virtualmin Pro is creating 2 names for each new email address we create. It creates the normal name style: joel@abc.com and it creates joel-abc.com

If we change our SMTP authentication name to the second with a dash, we are allowed to login and send mail? What happenend. I dont think this is normal as we havent had to do this in the past? We are using the lates update of pro



Thu, 10/26/2006 - 17:03

At first I didnt think that smtp auth was working and I am still not sure that it was, but according to the FAQ's it should be working after install of virtualmin pro if install was recent, but I could not make it work with the domain I moved to virtualmin, so I went to each client and turned off the smtp in their client.

I then read and reread the FAQ on SMTP authentication and followed each step carefully. I noticed that the option smtpd_sasl_security_options = noanonymous was not in the postfic main.cf file, so I jumped up and down thinking I found the problem and added it and followed the rest of the directions. testing with telnet showed that smtp auth was working.

so what is the smtpd_sasl_security_options = noanonymous option and should I remove it, or should it be installed with virtualmin? Or should the FAQ just be updated not to show that option?

I then realized that if I change the smtp auth username to use the dash version of their name, then smtp auth works so user-domain.com will work, where user@domain.com wont.

Is there a way to make this work with the @ sign? thats what most users are used too. If not I can just tell them that they have to put the dash in place of the @ sign for it to work.

I would really like this option for users that are on laptops so they can send mail from their mail server without it getting marked as spam or not even sending.

Thu, 10/26/2006 - 17:13 (Reply to #2)
Joe's picture

Hey William,

The @ issue is another FAQ. ;-)


You probably need to edit /etc/sysconfig/saslauthd and add -r to the FLAGS= variable, and restart saslauthd:

service saslauthd restart

This is a newly discovered issue with some version os saslauthd...I'm currently researching which versions we need to make this change for, so it can be automated. It can't be applied universally, because not all versions support the option. Life is hard when you have to support a dozen different platforms.


Check out the forum guidelines!

Thu, 10/26/2006 - 17:43

Man, I read that too, but I guess I didnt understand that it was talking about smtp auth...

the -r option worked, but I tested it with sending from my mail server and using the isp mail server and when using a dynamic IP it pushes your spam number up unless you use the ISP mail server, so if I have users that dont understand how to send email, and maybe they type in all caps or something, they have a much higher chance of getting tagged as spam.

I know this has to do with orbs and dynamic IP's, but I just don't understand it, since my mail server is on a static T1, so why should it matter that a dynamic client at some ISP gets points against him like he is a spammer, just because he is sending mail, if the person logs in with smtp auth, that means they have the right username and passowrd, and that should be enough to show the emails came from a reliable non spammer source.

I wish I could make it show like those reliable clients are sending from the local T1 instead of their ISP.

atleast its working though:) thanks Joe!


Topic locked