I want to take this opportunity to raise awareness on email - core stuff again. Email integration should not be in core. We decided against removing it as part of Airflow 3.0 See related mailing list discussion [DISCUSS] Drop email integration from Airflow Core <https://lists.apache.org/thread/tbnf2rcrowrp3ktltrhrcjvc53k58oxx> https://lists.apache.org/thread/tbnf2rcrowrp3ktltrhrcjvc53k58oxx But since then this is stuck in limbo between core and smtp provider. Some email related features were blocked due to expected migration which never happened. If anyone in the community has the time to complete the extraction of email from core to SMTP provider I think that would really simplify things.
On Mon, Jul 20, 2026 at 2:23 PM Eugen Kosteev <[email protected]> wrote: > Thanks Amogh and Jarek for looking into this! > > Thank you Jarek for preparing PR to address this. If I understand > correctly, the change will go to some Airflow 3.3 (3.3.1?) version. > We will not backport it to 3.2 (e.g. 3.2.3?), right? > > - Eugene > > On Mon, Jul 20, 2026 at 12:55 PM Amogh Desai <[email protected]> > wrote: > > > Thanks, taking a look. > > > > (And thanks for clarifying on the AI triage, I have been out of sync on > > that lately) > > > > Thanks & Regards, > > Amogh Desai > > > > > > On Mon, Jul 20, 2026 at 4:21 PM Jarek Potiuk <[email protected]> wrote: > > > > > It was closed as it had "closes: #" - and the issue has been closed > > > automatically after merge - not an AI tooling (I missed that one when > > > merging it). The AI tooling never closes issues automatically. > > > > > > I already opened https://github.com/apache/airflow/pull/69877 drafted > to > > > address precisely that issue: adding common.compat > > > LegacyEmailBackendNotifier that wraps the original email_backend (I am > > > **just** re-reviewing it). Maybe you can take a look? > > > > > > J. > > > > > > > > > On Mon, Jul 20, 2026 at 12:14 PM Amogh Desai <[email protected]> > > > wrote: > > > > > >> Hello Eugene, > > >> > > >> Replying as the author of: > https://github.com/apache/airflow/pull/57354 > > . > > >> > > >> For context, PR: https://github.com/apache/airflow/pull/57354 rewrote > > >> the email sending helper to construct SmtpNotifier directly, > > >> instead of going through the utils module. That function is what > > >> previously read [email]email_backend and dispatched to whatever > > >> the backend was configured. > > >> > > >> There was a PR shortly after: #65072 which fixed the email_conn_id > half > > >> of #65012 but the issue was closed without the email_backend > > >> half being addressed (likely part of the AI triage tool - @Jarek > Potiuk > > >> <[email protected]> worth tweaking some instructions there). That was > an > > >> oversight, not a > > >> decision and nothing in the operator deprecation warnings or docs says > > >> custom email_backends stop working. So to answer your question > > >> directly: unintentional, not a documented breaking change. > > >> > > >> I plan to take a look in the email sending helper, and if a deployment > > >> has explicitly customized email_backend, restore the old send_email() > > >> dispatch > > >> for backward compatibility. > > >> > > >> I will get to it shortly. > > >> > > >> Thanks & Regards, > > >> Amogh Desai > > >> > > >> > > >> On Mon, Jul 20, 2026 at 2:54 PM Eugen Kosteev <[email protected]> > > wrote: > > >> > > >>> Hi. > > >>> > > >>> *tl;dr* In Airflow 3.2 a breaking change introduced with > > >>> [email]email_backend no longer respected. > > >>> Github issue: https://github.com/apache/airflow/issues/65012 > (closed, > > >>> but > > >>> it wasn't resolved) > > >>> > > >>> [email]email_backend Airflow configuration property should be one of > > the > > >>> most usable properties in Airflow 2 (prior to Airflow 3), > > >>> and it is likely not all (most of) Airflow users didn't yet migrate > to > > >>> SmtpNotifiers in Airflow 3.1 (since there was backward compatibility > > >>> maintained). > > >>> > > >>> What is the community's stance on this? Was this breaking change (in > > >>> minor > > >>> Airflow version) introduced accidentally? > > >>> If this was intended breaking change, should we then at least have a > > note > > >>> about it in Release Notes for Airflow 3.2.0 (currently there is no > > >>> mentioning of this)? > > >>> > > >>> > > > https://airflow.apache.org/docs/apache-airflow/stable/release_notes.html#airflow-3-2-0-2026-04-07 > > >>> > > >>> > > >>> *Background:* > > >>> In Airflow 3.0 email/email_on_retry/email_on_retry task parameters > were > > >>> deprecated (in favor of SmtpNotifier(s)), > > >>> DAGs using these parameters will have warning messages but still > > continue > > >>> to work using [email]email_backend and > > >>> [email]email_conn_id Airflow configuration properties to send emails: > > >>> > > >>> > > > https://github.com/apache/airflow/blob/3.0.6/task-sdk/src/airflow/sdk/bases/operator.py#L1048 > > >>> > > >>> > > > https://github.com/apache/airflow/blob/3.0.6/task-sdk/src/airflow/sdk/execution_time/task_runner.py#L1157 > > >>> > > >>> > > > https://github.com/apache/airflow/blob/3.0.6/airflow-core/src/airflow/utils/email.py#L72 > > >>> > > >>> Since Airflow 3.2.0, mails on email_on_retry and email_on_failure are > > >>> sent using > > >>> SmtpNotifier, bypassing the configured email_backend (and > > email_conn_id - > > >>> this was fixed later). > > >>> > > >>> > > > https://github.com/apache/airflow/blob/3.2.0/task-sdk/src/airflow/sdk/execution_time/task_runner.py#L1612 > > >>> https://github.com/apache/airflow/pull/65072 > > >>> > > >>> There was an open issue > https://github.com/apache/airflow/issues/65012 > > >>> about > > >>> this, and it was closed with partial fix "fix stmp email callback to > > use > > >>> email_conn_id". > > >>> Overall this change - stop respecting [email]email_backend in > > >>> email_on_retry/email_on_retry, forces Airflow users to update their > > Dags > > >>> to > > >>> use on_*_callback(s) before migrating. > > >>> > > >>> -- > > >>> Eugene > > >>> > > >> > > > > > -- > Eugene >
