Email w/ auth enabled not working

[sdepner]

Hello,

 

I have been keeping up with the various email notification threads however I am still experiencing email notification issues. This is on an xServe running retro 8.0 and NO local mail server running on this system (else I would use localhost and be done).

 

This is the error I receive in the retro log:

 

smtpOpen: connection established "mailserver.blah"

smtpSend: "EHLO mailserver.blah"

smtpWait: "250 DSN"

smtpSend: "AUTH LOGIN"

smtpWait: "530 5.7.0 Must issue a STARTTLS command first"

smtpReset: AUTH LOGIN expected 334, response 530

smtpSend: "QUIT"

smtpWait: "221 2.0.0 Bye"

soccRecv: connection closed cleanly

soccRecv: connection unexpectedly closed

soctPreDispose: maximum queue depth was 3

 

I do not "require" SSL for SMTP login (Obvious reasons) so it should be able to negotiate with the mail server anyway. I have allowed "cram-md5" and "login" types of smtp auth. I will not allow plain text.

 

I'm assuming retrospect is having an issue with SMTP auth here which I do require but I have set retrospect to use smtp auth as well. Disabling smtp auth is not an option and results in helo, you are not me failures with on mailserver.

 

I hazard a guess that retrospect email notifications just need to provide more user configurable options about how it performs mail server negotiation (Similar to a standard email client).

 

Then again I don't think it is even sending the auth "login" command correctly because I can use "login" from our windows laptops and macs too without any issues on this mail server (In addition to cram-md5). So it isn't my mail server that is failing the auth negotiation here...

 

Can I modify the email notification settings in some ini file or something for now?

 

edit:

 

testing against another departments email server which requires smtp auth but does not allow "login" auth and requires "cram-md5" I receive this:

 

smtpOpen: connection established "smtpserver.blah"

smtpSend: "EHLO server.blah"

smtpWait: "250 HELP"

smtpSend: "AUTH LOGIN"

smtpWait: "504 5.3.3 AUTH mechanism LOGIN not available"

smtpReset: AUTH LOGIN expected 334, response 504

smtpSend: "QUIT"

soccRecv: connection unexpectedly closed

soctPreDispose: maximum queue depth was 2

 

So obviously the only auth type retrospect is using is "Login" which is somewhat inflexible... can we get some cram-md5 auth in retrospect?

 

 

Edited April 8, 2009 by Guest

[sdepner]

Any ideas such as ini file edit in order to specify auth settings or plans for a fix/improvement?

[Mayoff]

From the Retrospect KB:

 

An advanced Retrospect log for email notification may report the error:

 

530 5.7.0 Must issue a STARTTLS command first

 

To fix this issue make sure your email server is not using STARTTLS authentication

 

The STARTTLS command is part of TLS encryption.

 

From http://www.tech-faq.com/tls-transport-layer-security.shtml:

"TLS (Transport Layer Security), defined in RFC 2246, is a protocol for establishing a

secure connection between a client and a server. TLS (Transport Layer Security) is

capable of authenticating both the client and the server and creating a encrypted

connection between the two."

 

Although Retrospect does support authentication to SMTP servers, we don't support TLS encryption of the SMTP session.

 

If you do require STARTTLS authentication you can work around this issue in a variety of ways:

- Run another SMTP server that doesn't require TLS and listens only to Retrospect

- Configure the SMTP server to no longer require TLS

- Configure the SMTP server to make an exception to the TLS requirement for Retrospect (based perhaps on IP address or on "From" email address)

- Set up a TLS proxy between Retrospect and the SMTP server

 

 

[sdepner]

Hi Robin,

 

Thanks for the response. I understand that however I don't think that addresses the issue. For example, I just tested on a mail client with the following smtp settings:

auth type: login

ssl: not enabled

 

This email was able to send fine and I can see it pass through the mail logs without engaging the TLS engine at all (And that's what SSL is going to do). On this same client, I now enable the following settings:

auth type: login

ssl: enabled

Email still sends without me adjusting the email server settings at all. This time with TLS engine engaged.

 

So while I understand that you're saying retrospect won't work with a server that requires TLS, it also is not working in my situation where the server allows one to use TLS but does not require it.

 

Considering my client behavior, that pretty much indicates the mail server is not requiring TLS but can use it when a client properly communicates it.

 

In addition, it also doesn't address this log error when I tested on a university mail server that does not require TLS:

 

smtpOpen: connection established "smtpserver.blah"

smtpSend: "EHLO server.blah"

smtpWait: "250 HELP"

smtpSend: "AUTH LOGIN"

smtpWait: "504 5.3.3 AUTH mechanism LOGIN not available"

smtpReset: AUTH LOGIN expected 334, response 504

smtpSend: "QUIT"

soccRecv: connection unexpectedly closed

soctPreDispose: maximum queue depth was 2

 

So am I correct in thinking that retrospect only allow auth type "login" in which case I ask are we going to see improvements here.

 

TLS and the ability to select auth types would be a welcome change as a lot of orgs use TLS for internal mail too as it is no longer safe to only encrypt outside transmissions.

 

In any case, I could do without using TLS for this since it would be an internally generated email from the backup server but I don't think retrospect is functioning properly in recognizing whether TLS is required.

 

 

Edited April 9, 2009 by Guest

[Mayoff]

I am not an SMTP expert, so I can not offer more suggestions based on your findings. Maybe someone else in the forum will have a suggestion.

 

I have logged a bug for investigation to make sure Retrospect is doing the right thing. It is bug 21850

[rhwalker]

Act like an STMP server, see what your server is replying, by telnet to port 25 (your stuff is in red):

 

$ [color:red]telnet mail.example.com 25[/color]

Trying aaa.bbb.ccc.ddd...

Connected to mail.example.com.

Escape character is '^]'.

220 mail.example.com ESMTP Postfix

[color:red]ehlo your.machinename.com[/color]

250-mail.example.com

250-PIPELINING

250-SIZE 31457280

250-ETRN

250-STARTTLS

250 8BITMIME

$ [color:red]quit[/color]

221 Bye

Connection closed by foreign host.

Full command details here:

RFC 2821

 

The EHLO command returns the supported options.

 

Russ

[sdepner]

Trying 123.123.123.123...

Connected to mailserver.blah.

Escape character is '^]'.

220 mailserver.blah ESMTP Postfix

ehlo mailserver.blah

250-mailserver.blah

250-PIPELINING

250-SIZE 15728640

250-ETRN

250-AUTH LOGIN CRAM-MD5 GSSAPI

250-STARTTLS

250-ENHANCEDSTATUSCODES

250-8BITMIME

250 DSN

 

I was already aware of this though because I do "allow" SSL but do not "require" it which is a common smtp setup so naturally STARTTLS is seen as a supported option when you perform a telnet smtp test.

 

I can still send email to this mail server without using SSL (In which case starttls is not called) and if the server were in fact requiring SSL then my users wouldn't be receiving all that much mail from the outside

 

Just to reenforce this statement, here is the entry from my etc/postfix/main.cf:

 

smtpd_use_tls = yes

smtpd_enforce_tls = no

 

FYI: I'm loving the new interface overall Robin. So far, so good on my test backup server though there are various minor issues. A lot of the major problems I faced were resolved in the latest build. Keep up the good work! I still want my email notifications to work though along with more consistent discovery of clients without inputting IP manually

Edited April 10, 2009 by Guest

[Mayoff]

We could not reproduce the problem with exchange. What is your mail server and version? What OS?

[sdepner]

10.5.6 server which uses Postfix (2.4.3).

 

Thank you.

Edited April 10, 2009 by Guest