Skip to content

airflow/utils/email.py def send_mime_email doesn't take all values from connection #34554

Open

Description

Apache Airflow version

2.7.1

What happened

When defining an SMTP connection only the user and password are taken from the connection. The host, port, starttls, start_ssl, from_email, timeout and retry are all taken from the configuration and not from the connection. Although the smtp provider (https://airflow.apache.org/docs/apache-airflow-providers-smtp/1.0.0/index.html) provides all these fields.

What you think should happen instead

The following lines should be included in airflow/utils/email.py around line 246:

if conn_id is not None:
    try:
        from airflow.hooks.base import BaseHook

        airflow_conn = BaseHook.get_connection(conn_id)
        smtp_user = airflow_conn.login
        smtp_password = airflow_conn.password
        smtp_host = airflow_conn.host
        smtp_port = airflow_conn.port

        extra = json.loads(airflow_conn.extra)

        smtp_starttls = not extra["disable_tls"]
        smtp_timeout = int(extra["timeout"])
        smtp_retry_limit = int(extra["retry_limit"])
        smtp_ssl = not extra["disable_ssl"]

The from_email should be retrieved from the connection earlier in the call stack.

How to reproduce

Install the SMTP provider:
pip install apache-airflow-providers-smtp

Create an SMTP connection in the UI
Set the AIRFLOW__EMAIL__EMAIL_CONN_ID environment variable to the connection id of the SMTP connection

Use the EmailOperator (from airflow.operators.email import EmailOperator) in a DAG.

Check the values that are used in send_mime_email.

Operating System

Ubuntu

Versions of Apache Airflow Providers

apache-airflow-providers-smtp==1.3.2

Deployment

Docker-Compose

Deployment details

No response

Anything else

No response

Are you willing to submit PR?

  • Yes I am willing to submit a PR!

Code of Conduct

Activity

  1. boring-cyborg commented on Sep 22, 2023

    @boring-cyborg

    Thanks for opening your first issue here! Be sure to follow the issue template! If you are willing to raise PR to address this issue please do so, no need to wait for approval.

  2. eladkal commented on Sep 22, 2023

    @eladkal
    Contributor

    @hussein-awala is working on the smtp migration from core to smtp provider

  3. linked a pull request that will close this issueUsing settings from connection #34556on Sep 22, 2023
  4. github-actions commented on Oct 4, 2024

    @github-actions
    Contributor

    This issue has been automatically marked as stale because it has been open for 365 days without any activity. There has been several Airflow releases since last activity on this issue. Kindly asking to recheck the report against latest Airflow version and let us know if the issue is reproducible. The issue will be closed in next 30 days if no further activity occurs from the issue author.

  5. scottlimmer commented on Oct 25, 2024

    @scottlimmer
    Contributor

    What's the status of this issue? I've just wasted too much time as a result of this and I'd like to see it fixed.

    Is it actively being worked on? Will a PR be considered? Is there a reason why https://github.com/apache/airflow/blob/main/airflow/utils/email.py#L247,L255 doesn't include other SMTP params?

  6. potiuk commented on Oct 25, 2024

    @potiuk
    Member

    What's the status of this issue? I've just wasted too much time as a result of this and I'd like to see it fixed.

    Is it actively being worked on? Will a PR be considered? Is there a reason why https://github.com/apache/airflow/blob/main/airflow/utils/email.py#L247,L255 doesn't include other SMTP params?

    The status is that it waits for someone to fix. As usual. And if you want to volunteer to fix it - we can assign it to you and you might lead it to completion @scottlimmer - otherwise it will have to wait for one of the > 3000 contributors to volunteer and implement it. That's how open-source development works, in case you were not aware.

    Generally contributing it back and fixing is a great way to give back for the absolutely free softwre that you can use and get without any guarantees if you read the licence. And contributing a fix back might be great way to help others people like you who might have struggled with it - or might struggle with it in the future. So I heartily recommend it. It's also great way to feel good that you don't just "get" from the community, but you also "give".

    Second best - if you do not feel skilled enough to contribute back - is to find someone who you encourage (or sometimes pay if you have a company or just want to help the community in monetary, rather than engineering time ways. This happens a lot - many people who contribute here are paid individually to contribute features or fixes that are needed by those who decide to pay them.

    Eventually, you might simply wait until someone picks an interest and fixes it. This might be helped by marking the issue as "good first issue" - which I just did. Then you contribute nothing, but also your expectations here "it happens when it happens".

    So .. pick your favourite way how you might (or might choose not) want to contribute to fix the issue.

  7. potiuk commented on Oct 25, 2024

    @potiuk
    Member

    Is there a reason why https://github.com/apache/airflow/blob/main/airflow/utils/email.py#L247,L255 doesn't include other SMTP params?

    It might depend. Make your PR and a reviewer will find it much easier to discuss details over the code that you will propose.

  8. scottlimmer commented on Oct 26, 2024

    @scottlimmer
    Contributor

    @potiuk Apologies, my ealier initial comment sound grumpier than I'd intended. I was really looking to clarify if there is already an existing larger body of work (as suggested by #34554 (comment)) that might explain why the existing PR went stale.

    Happy to have a go at fixing this.

  9. potiuk commented on Oct 26, 2024

    @potiuk
    Member

    my ealier initial comment sound grumpier than I'd intended.

    Or I am oversensitive :). Generally speakong - this is open-source.

    But just to let you know - the "status" of the issue is exactly as described in the issue. Chance that there is "more" information than in the issue or linked to the issue is really small. And you would be extremely lucky to get someone response that would know more than what you can find int the issue - or by searching.

    So asking "what's the status" is basically moot - the status is what you see here - there is no hidden status elsewhere or in any source that cannot be queried elsewhere. You might ask a person that is mentioned in other issues if you suspect that they might now more - but askign a general question "what is the status" is a bit ("is there anyone else who can ask the person mentioned in the previous issue what is the status of their work" - especially if you mention #34554 (comment)

    But you could ask the person yourself. Or even better - start fixing it. There is no problem in duplication of work if you see someone stalling or not responding. Worst thing - there will be a duplicated effort, but more often than not, best of both changes will be merged together and people will discuss on "competing" solutions.

    So ... go ahead and change the world.

  10. potiuk commented on Mar 2, 2026

    @potiuk
    Member

    @shivannakarthik We are unassigning you from this issue as part of our updated assignment policy.

    This is not meant to discourage your contribution — quite the opposite! You are still very welcome to work on this issue and submit a PR for it. Simply comment that you are working on it and open a PR when ready.

    We found that formal assignments were not working well, as they often prevented others from contributing when the assignee was not actively working on the issue.

  11. added a commit that references this issue on May 13, 2026
    dbbc5b3
  12. added a commit that references this issue on Jun 14, 2026
    971d5e2
  13. stark256-spec commented on Aug 5, 2026

    @stark256-spec

    I'd like to take this one. Confirmed it still reproduces on current main.

    In send_mime_email (airflow-core/src/airflow/utils/email.py), the transport settings — smtp_host, smtp_port, smtp_starttls, smtp_ssl, smtp_retry_limit, smtp_timeout — are all read from conf.get*("smtp", …). When a conn_id resolves a connection, only login and password are read from it; the connection's host, port, and extra are ignored. So configuring an SMTP connection still silently takes host/port/TLS from global config.

    Plan — make send_mime_email prefer the connection's values, each falling back to the existing config value when the connection doesn't provide it (so behavior is unchanged for anyone not populating these fields):

    • host ← conn.host, port ← conn.port
    • smtp_starttls ← not extra["disable_tls"], smtp_ssl ← not extra["disable_ssl"]
    • smtp_timeout ← extra["timeout"], smtp_retry_limit ← extra["retry_limit"]

    Key names and negation semantics are taken from SmtpHook (providers/smtp/.../hooks/smtp.py) so the two paths stay consistent. I'll scope from_email out of this change — in the current code it's resolved in send_email_smtp, not send_mime_email, so it belongs to a separate fix. Unit tests to be added in airflow-core/tests/unit/utils/test_email.py covering both connection-provided and config-fallback cases.

    Will open a PR shortly following the PR template.


    Drafted-by: @stark256-spec; reviewed by: Claude Code (Opus 4.8)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions