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
This change makes no sense to me? It hard-codes port to 25 for non-TLS connections, it seems to me? There is no way to set `fallbackPort`?
Previous behavior made more sense to me. With TLSOpportunistic, I want to connect to port X, if it supports STARTTLS, use TLS, otherwise, use the same port, but just do not use TLS. Currently, if I use SetTLSPortPolicy(TLSOpportunistic), if the server does not support STARTTLS on port X, it tries to connect to port 25 on that server - which might not even be available (or accessible - firewalls and stuff).
I do not get issue #105 either. Is this about behavior if one does not call WithPort? I think if WithPort is not made, then default should be to connect to port 25 (or 587?) and try STARTTLS on it, if it fails and TLSOpportunistic is set, use no TLS on same port. The behavior to try different ports makes no sense to me. You use one port, but potentially negotiate different configuration of how you use it. And WithPort is then used to configure which port is the one the client uses.
Luckily, WithTLSPolicy still works and if I use WithTLSPolicy it is exactly how I would want. Maybe just remove deprecation on it?
But I do think that connecting to multiple ports is a strange approach. That might be done by some higher-level library to auto-detect configuration of an unknown SMTP server. But not by a low-level library like this one where you generally know the server you are connecting to.
This works as intended (trying to connect to localhost:1025), because WithTLSPortPolicy(mail.NoTLS) sets port to 25, and then WithPort rewrites it back to 1025. But if you swap the options around it obviously fails.
The update modifies the client's handling of port selection when configuring SSL/TLS connections. The clients' functions `WithSSLPort`, `WithTLSPortPolicy`, `SetTLSPortPolicy`, and `SetSSLPort` are revised to avoid overriding previously set ports. Additionally, the deprecation notes have been removed and replaced with notes on best-practice recommendations, referring the new *Port*() methods. This change revises #105 and takes the comments made in #181 into account.
Previous behavior made more sense to me. With
TLSOpportunistic
, I want to connect to port X, if it supportsSTARTTLS
, use TLS, otherwise, use the same port, but just do not use TLS. Currently, if I useSetTLSPortPolicy(TLSOpportunistic)
, if the server does not supportSTARTTLS
on port X, it tries to connect to port 25 on that server - which might not even be available (or accessible - firewalls and stuff).I do not get issue #105 either. Is this about behavior if one does not call
WithPort
? I think ifWithPort
is not made, then default should be to connect to port 25 (or 587?) and try STARTTLS on it, if it fails andTLSOpportunistic
is set, use no TLS on same port. The behavior to try different ports makes no sense to me. You use one port, but potentially negotiate different configuration of how you use it. AndWithPort
is then used to configure which port is the one the client uses.Luckily,
WithTLSPolicy
still works and if I useWithTLSPolicy
it is exactly how I would want. Maybe just remove deprecation on it?But I do think that connecting to multiple ports is a strange approach. That might be done by some higher-level library to auto-detect configuration of an unknown SMTP server. But not by a low-level library like this one where you generally know the server you are connecting to.
Originally posted by @mitar in #170 (comment)
The text was updated successfully, but these errors were encountered: