SMTP No suitable authentication method found

Hi,
I am using local SMTP server which doesn’t request any login/pass, authentication is done by source IP. I can confirm that it works by sending email directly from command line using the same server sentry is running.
Now when I am trying to use this SMTP server in sentry I receive following exception:

       17:36:03 [ERROR] celery.worker.job: Task sentry.tasks.email.send_email[2701bb6d-14cf-46c2-ade3-df422d3f8769] raised unexpected: SMTPException('No suitable authentication method found.',) (data={u'hostname': 'celery@90cf836d209e', u'name': 'sentry.tasks.email.send_email', u'args': '[]', u'internal': False, u'kwargs': "{'message': <django.core.mail.message.EmailMultiAlternatives object at 0x7f800f439350>}", u'id': '2701bb6d-14cf-46c2-ade3-df422d3f8769'})
    Traceback (most recent call last):
      File "/usr/local/lib/python2.7/site-packages/celery/app/trace.py", line 240, in trace_task
        R = retval = fun(*args, **kwargs)
      File "/usr/local/lib/python2.7/site-packages/celery/app/trace.py", line 438, in __protected_call__
        return self.run(*args, **kwargs)
      File "/usr/local/lib/python2.7/site-packages/sentry_sdk/integrations/celery.py", line 118, in _inner
        reraise(*exc_info)
      File "/usr/local/lib/python2.7/site-packages/sentry_sdk/integrations/celery.py", line 113, in _inner
        return f(*args, **kwargs)
      File "/usr/local/lib/python2.7/site-packages/sentry/tasks/base.py", line 54, in _wrapped
        result = func(*args, **kwargs)
      File "/usr/local/lib/python2.7/site-packages/sentry/tasks/email.py", line 76, in send_email
        send_messages([message])
      File "/usr/local/lib/python2.7/site-packages/sentry/utils/email.py", line 436, in send_messages
        sent = connection.send_messages(messages)
      File "/usr/local/lib/python2.7/site-packages/django/core/mail/backends/smtp.py", line 87, in send_messages
        new_conn_created = self.open()
      File "/usr/local/lib/python2.7/site-packages/django/core/mail/backends/smtp.py", line 54, in open
        self.connection.login(self.username, self.password)
      File "/usr/local/lib/python2.7/smtplib.py", line 619, in login
        raise SMTPException("No suitable authentication method found.")
    SMTPException: No suitable authentication method found.
    17:39:30 [ERROR] celery.worker.job: Task sentry.tasks.email.send_email[4c6a2dad-d8cc-41c8-a605-7293153a733a] raised unexpected: SMTPException('No suitable authentication method found.',) (data={u'hostname': 'celery@90cf836d209e', u'name': 'sentry.tasks.email.send_email', u'args': '[]', u'internal': False, u'kwargs': "{'message': <django.core.mail.message.EmailMultiAlternatives object at 0x7f800f3e4150>}", u'id': '4c6a2dad-d8cc-41c8-a605-7293153a733a'})

My configuration is the following:

SENTRY_EMAIL_HOST: **.**.**.**
SENTRY_EMAIL_PORT: 25
SENTRY_EMAIL_PASSWORD: ''
SENTRY_EMAIL_USER: ''
SENTRY_EMAIL_USE_TLS: 'false'

docker-compose run --rm worker config get mail.password
type: STRING
from config:
current: ‘’

docker-compose run --rm worker config get mail.username
type: STRING
from config:
current: ‘’

Does anyone have an idea what could be wrong?
Thanks in advance!

Do your workers also have their own SMTP servers inside? If not, I’d bet your SMTP server only allows unauthenticated usages from the very same host and since your workers are not on the same machine, they cannot use it.

Hi @BYK,

Thanks a lot for the reply.
There is an SMTP container running as part of docker-compose configuration if you mean this but I doubt this is the root cause as I use different server controlled by our IT:

docker ps
CONTAINER ID        IMAGE                  COMMAND                  CREATED             STATUS              PORTS                    NAMES
90cf836d209e        onpremise_worker       "/entrypoint.sh run …"   3 days ago          Up 3 days           9000/tcp                 onpremise_worker_1
179c1fa88c16        onpremise_web          "/entrypoint.sh run …"   3 days ago          Up 3 days           0.0.0.0:9000->9000/tcp   onpremise_web_1
02bbe4d18c59        onpremise_cron         "/entrypoint.sh run …"   3 days ago          Up 3 days           9000/tcp                 onpremise_cron_1
135bea1289ea        tianon/exim4           "docker-entrypoint.s…"   5 days ago          Up 4 days           25/tcp                   onpremise_smtp_1
2a7cd968572a        postgres:9.5           "docker-entrypoint.s…"   5 days ago          Up 4 days           5432/tcp                 onpremise_postgres_1
a17c12659d54        memcached:1.5-alpine   "docker-entrypoint.s…"   5 days ago          Up 4 days           11211/tcp                onpremise_memcached_1
e0727694c7d9        redis:3.2-alpine       "docker-entrypoint.s…"   5 days ago          Up 4 days           6379/tcp                 onpremise_redis_1

Currently I believe that Sentry does not support anonymous relay. You can find reply of mail server below:

250-SIZE 31457280
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-AUTH
250-8BITMIME
250-BINARYMIME
250 CHUNKING

And right after this Sentry throws an exception from my previous message.
I hoped there is some property in Sentry which disables SMTP authentication but I didn’t find it. Any thoughts on workaround for such case?

Ah, I just realized we already ship with an SMTP server. Sorry, I’m still getting my bearings. I think we should add the proper defaults into the on-premise repo. Anyway, doing a bit more research around this, here are my findings:

  1. If you are using our on-premise repo (looks like you do), you should not need to set SENTRY_EMAIL_HOST as we set it to the tianon/exim4 SMTP server’s address during docker-compose up step
  2. If you are using a different SMTP host, your issue might be the same with: https://serverfault.com/a/585778 – Which means, you probably need SENTRY_EMAIL_USE_TLS: 'true' as your SMTP server does not allow authenticating over plaintext connection (which makes sense TBH).

What do you think?

Hi @BYK,
I use different SMTP host, it’s Microsoft Exchange which allows sending e-mail without any authentication.
Just tried with SENTRY_EMAIL_USE_TLS: ‘true’, got following exception:

SMTPException('STARTTLS extension not supported by server.'

Thank you.

@antonro that simply means your MS Exchange server does not support TLS which doesn’t have anything to do with Sentry?

Hi @BYK,
My initial issue does not refer to TLS.
MS Exchange allows sending e-mail without TLS via 25 port, I have reproduced this via telnet successfully.
On the contrary Sentry does not support sending e-mail without authentication.
Thank you.

@BYK if someone on sentry team cares about this, this is deeply related to the issue I had, where perfect working Zimbra SMTP and Postfix/Exim CPanel failed to work with Sentry docker on premise. You said youre not keen on SMTP, I see people running in circle, and since weeks will pass i bet more people will hit same TLS/SMTP AUTH issues on Docker Sentry. Someone who knows SMTP should check the default templates, or update documentation. Something is wrong a glitch a misscponfiguration does not allow any other AUTH to SSL/TLS secure servers not normal behaviour. And so Microsoft exchange is not working, default ZImbra wont work, Cpanel default mails wont work, Gmail works. Great!

1 Like

Okay, looking at this again, have you tried setting these values to simply None in your sentry.conf.py file and see what happens?

Also, it is possible that you may be hitting this issue which is now resolved on master: https://github.com/getsentry/sentry/issues/14086 (not very likely tho since your docker-compose run --rm worker config get mail.password results were simply empty strings).

If setting these to None also doesn’t work, we may add a new setting, mail.no-auth or something like that, forcing None for username and password fields, which should work.

Hello

During SMTP connection setup, upon the SMTP server is connected, client will send an “EHLO” command to SMTP server, and SMTP server will response with all its capability together with the authentication method it accepts.

Normally such response will look like
250-AUTH LOGIN PLAIN
250-AUTH=LOGIN PLAIN
where the authentication method is specified as “PLAIN”, which means the username/password method.
The SMTP client then use a desired authentication mode to start the authentication. In case “PLAIN” mode, we can see following

-> PMAUTH LOGIN
<- PM 334 xxxxxxxxxxx
-> yyyyyyyyyyyyyyyy
<- PM 334 xxxxxxxxxxxx
-> yyyyyyyyyyyyyyy
<- PM235 Authentication successful

In your case, EHLO the response on authentication method is
250-AUTH
You can see that there is no authentication method specified, so it is upon to the client to choose a default method in case the server failed to indicate.

So my personal suggestion is try to upgrade your mail server, to have a correct EHLO response on AUTH.

While for sentry, I would rather recommend to have a new setting of
mail.default-authentication =plain
to force use plain mode, but rather this is an issue of mailserver response not the client. The SMTP client response is correct to tell the user that “No suitable authentication method found” from the server’s EHLO reponse

1 Like