You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
airflow/utils/email.py def send_mime_email doesn't take all values from connection #34554
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.
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.
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.
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.
@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.
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.
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.
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"]
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)
Activity
boring-cyborg commentedon Sep 22, 2023
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.
eladkal commentedon Sep 22, 2023
@hussein-awala is working on the smtp migration from core to smtp provider
github-actions commentedon Oct 4, 2024
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.
scottlimmer commentedon Oct 25, 2024
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?
potiuk commentedon Oct 25, 2024
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.
potiuk commentedon Oct 25, 2024
It might depend. Make your PR and a reviewer will find it much easier to discuss details over the code that you will propose.
scottlimmer commentedon Oct 26, 2024
@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.
potiuk commentedon Oct 26, 2024
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.
potiuk commentedon Mar 2, 2026
@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.
Honor SMTP connection host/port and extra in send_mime_email
Honor SMTP connection host/port and extra in send_mime_email
stark256-spec commentedon Aug 5, 2026
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 fromconf.get*("smtp", …). When aconn_idresolves a connection, onlyloginandpasswordare read from it; the connection'shost,port, andextraare ignored. So configuring an SMTP connection still silently takes host/port/TLS from global config.Plan — make
send_mime_emailprefer 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.portsmtp_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 scopefrom_emailout of this change — in the current code it's resolved insend_email_smtp, notsend_mime_email, so it belongs to a separate fix. Unit tests to be added inairflow-core/tests/unit/utils/test_email.pycovering 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)