smtp auth

[pedromorgan]

Implement smtp auth and a config for smtp auth

[ian-kent]

Could you expand a bit please - support for SMTP AUTH (RFC4954) is already there. Authentication is essentially ignored, but it allows for testing of clients which are already configured to use authentication.

Do you mean there's an authentication mechanism missing that you need, or do you want to be able to configure valid users/passwords etc?

[pedromorgan]

I use python/pylons with turbomail
and a config similar to this

mail.on = 1
mail.manager = demand
mail.transport = smtp
mail.smtp.server = localhost:1025
mail.smtp.username = www4@mydomain.com
mail.smtp.password = test123
mail.smtp.debug = 1

When i send email, I get error

17:42:08,826 INFO  [turbomail.transport] Authenticating as www4@mydomain.com.
17:42:08,826 ERROR [turbomail.manager] Delivery of message <20141115174208.23056.35984@zee> failed.
Traceback (most recent call last):
...<snipped>
  File "/usr/lib/python2.7/smtplib.py", line 578, in login
    raise SMTPException("SMTP AUTH extension not supported by server.")
SMTPException: SMTP AUTH extension not supported by server.

Am confused as I can see in the code it checks for credentials, but what are the "credentials".. ie user/pass

[pedromorgan]

It would be fantastic is the user/pass was configurable eg -u mail@user.com -p secret

[ian-kent]

Any chance you could provide log output from Go-MailHog when you try? Sounds like a bug!

SMTP AUTH should be supported, once EHLO/HELO is received Go-MailHog is in MAIL state, which should accept the AUTH command, but I might have messed up the implementation!

There aren't any real credentials - Go-MailHog should accept any username/password combination for CRAM-MD5, PLAIN, LOGIN and EXTERNAL mechanisms, so it can be a drop-in replacement for any mail server without having to think about configuring authentication.

Adding support for setting a username and password would be relatively easy - but I'm not sure it would be all that useful?

[pedromorgan]

2014/11/16 19:02:41 [SMTP 127.0.0.1:60751, 0] Starting session
2014/11/16 19:02:41 [SMTP 127.0.0.1:60751, 0] Sent 33 bytes: 'mailhog.example ESMTP Go-MailHog
'
2014/11/16 19:02:41 [SMTP 127.0.0.1:60751, 0] Received 18 bytes: 'ehlo [127.0.1.1]
'
2014/11/16 19:02:41 [SMTP 127.0.0.1:60751, 0] Processing line: ehlo [127.0.1.1]
2014/11/16 19:02:41 [SMTP 127.0.0.1:60751, 0] In state 0, got command 'ehlo', args '[127.0.1.1]'
2014/11/16 19:02:41 [SMTP 127.0.0.1:60751, 0] Got unknown command for ESTABLISH state: 'ehlo'
2014/11/16 19:02:41 [SMTP 127.0.0.1:60751, 0] Sent 21 bytes: 'Unrecognised command
'

and some turbo mail output with debug=on, different time, same error

19:06:47,472 INFO  [turbomail.manager] Attempting delivery of message <20141116190647.820.12425@zee>.
19:06:47,472 INFO  [turbomail.transport] Attempting delivery of message <20141116190647.820.12425@zee>.
19:06:47,472 INFO  [turbomail.delivery] <20141116190647.820.12425@zee> DELIVER
19:06:47,472 INFO  [turbomail.transport] Connecting to SMTP server localhost:1025.
connect: ('localhost', 1025)
connect: ('localhost', 1025)
reply: '220 mailhog.example ESMTP Go-MailHog\n'
reply: retcode (220); Msg: mailhog.example ESMTP Go-MailHog
connect: mailhog.example ESMTP Go-MailHog
send: 'ehlo [127.0.1.1]\r\n'
reply: '500 Unrecognised command\n'
reply: retcode (500); Msg: Unrecognised command
19:06:47,473 INFO  [turbomail.transport] TLS unavailable. Messages will be delivered insecurely.
19:06:47,473 INFO  [turbomail.transport] Authenticating as www4@geo.uk.com.
19:06:47,473 ERROR [turbomail.manager] Delivery of message <20141116190647.820.12425@zee> failed.

[pedromorgan]

Adding support for setting a username and password would be relatively easy - but I'm not sure it would be all that useful?

It would for me, even making it periodically fail to test connection, password et all in debugging.

[ian-kent]

thanks for the log output - bug is not accepting lowercase commands (e.g. "ehlo" instead of "EHLO") - should be an easy fix, I'll have a look today sometime

good point re auth config - i'll have a look as part of #8

[thaJeztah]

I like the authconfig, not convinced on randomly failing to authenticate. I think that's really not a responsibility of Mailhog and should be implemented via integration tests in the app that makes use of Mailhog

[ian-kent]

I think that's really not a responsibility of Mailhog and should be implemented via integration tests in the app that makes use of Mailhog

Wouldn't it be more difficult to get the mail client to simulate connection failures than have them simulated by the mail server? And client side code changes then become implementation specific (e.g., you might have to rewrite the same "connection failure simulation" code in 10 different application stacks)

If this was supported in MailHog, it would be consistent across all applications being tested, and would more closely simulate infrastructure failures rather than client library failures.

This discussion should probably be on #8 instead, but personally I quite like the idea.

[thaJeztah]

(You're right, I think this was mentioned in #8 and I mixed up the issues :))

Wouldn't it be more difficult to get the mail client to simulate connection failures

If I understand the use-case correctly, the idea was that Mailhog would randomly return "incorrect username/pass" errors. Imo, handling such errors could be tested by providing incorrect credentials. So if that is indeed the use-case, I don't think that's something Mailhog should do. Perhaps I misinterpreted the use case.

[ian-kent]

If I understand the use-case correctly, the idea was that Mailhog would randomly return "incorrect username/pass" errors. Imo, handling such errors could be tested by providing incorrect credentials

You're right, the client could just be given incorrect credentials, although for some platforms that might require reconfiguration and potentially redeployment of the app between credentials changes.

Having support for this in MailHog would give more flexibility (as mentioned in #8), e.g. adding lag, timeouts or dropped connections, which would be more difficult to achieve client-side.

If it is implemented it wouldn't affect the normal behaviour of MailHog anyway, by default MailHog would work as it currently does.

edit: this is sort of similar to the Netflix Chaos Monkey

[pedromorgan]

Wouldn't it be more difficult to get the mail client to simulate connection failures than have them simulated by the mail server? And client side code changes then become implementation specific (e.g., you might have to rewrite the same "connection failure simulation" code in 10 different application stacks)

That's precisely my use case, I got three applications, and I just want the "smtp server to fail" for testing. Otherwise I need to modify and test each client use case, which is very difficult sometimes, eg lags and timeouts.

[pedromorgan]

NOTE: the "fails" options need to optional, so users who dont want the "errors" can contunue as normal.

[thaJeztah]

OK, clear. I'm fine with that as long as it is indeed optional :)