EMAIL provider - stalling connect

Question

EMAIL provider - stalling connect

cherusk opened this issue 5 years ago · 9 comments

Describe the bug
Various SMTP(EMAIL) providers, even local happen to stall in SMTP server connection phase when interacted by with notifiers. Could be down to/linked to or caused underlying SMTP library issue reported earlier (https://bugs.python.org/issue37572).

It was made sure not underlying, ostensible networking culprit is in way. The transport flow path is reported open by e.g. nmap.

To Reproduce
On pristine runtime with freshly installed notifiers via cli, with dbg traces activated in notifiers:


# notifiers email notify
        --from testing@mail.de
        --to   testing@mail.de
        --subject "TEST"
        --host smtp.mail.de
        --port 465
        --username <YOUR_USR>@mail.de
        --password <YOUR_PW> 
        "SOME"

Does end in stalling at:
[...]
connect: ('smtp.mail.de', 465)
connect: to ('smtp.mail.de', 465) None

Expected behavior
Swift delivery of msg, without hanging/stalling.

Additional context
Python version: 3.6-3.7
OS: latest fedora/ubuntu

liiight commented 5 years ago

Not yet

Answer 1 · 2019-08-27T06:36:59.000Z

Thanks for opening your first issue here! Be sure to follow the issue template! 👋🐞👋

Answer 2 · 2019-08-27T07:30:49.000Z

Thanks for reporting this issue! Unfortunately I cannot think of anything other than looking at logs, which I have not enabled via the CLI (I'll make sure to add a verbosity option for that).

If it's possible, please try to reproduce via the pyrhon API with logging enabled. I hope there's sufficient logging in place, and if not, I'll add them

Answer 3 · 2019-08-27T07:40:15.000Z

Thanks for coming back so swiftly.

I might kindly refer you to my fork in the light you said as to logging. Here I've placed dedicated tracing required to distill the python issue mentioned initially:
cherusk@94afb21

Further, please find the script I attached to https://bugs.python.org/issue37572. It's running the API for interacting with a smtp server locally, with similar symptoms. I'm bedazzled to find same with a public smtp provider.

Nigh, I can come forth with API traces for the specific upstream provider interaction also, in case needed in case you think it's non-generic an issue.

Answer 4 · 2019-09-08T07:05:24.000Z

@liiight or in general, any progress, please?

Answer 5 · 2020-05-14T07:30:30.000Z

A general question related to that topic: Are the notifications be buffered and sent in a separate thread? Imagine, that the service provider is currently unreachable, would that block the main programm for the request's timeout period? Would be nice if there wouldn't be an influence on the applications repsonsiveness.

Answer 6 · 2022-02-09T14:08:53.000Z

@cherusk is this issue still relevant?

@mahadi I agree that using this with threading would be beneficial, but I believe it's the clients' decision to do (or not) do this

Answer 7 · 2022-02-09T14:12:22.000Z

Not necessarily, @liiight I solved this with another mailing framework, containerized.

Answer 8 · 2022-02-09T14:20:46.000Z

Ok, I guess I'll close then