1. go-smtp is replaced by a fork that reverts StartTLS removal.
2. SASL LOGIN is no longer supported by upstream go-sasl, readded disabled by default.
3. Updated endpoint code to match new go-smtp authentication interfaces.
4. certmagic repo had some renames
5. Minimum Go version increased to 1.23 to match dependencies.
smtp.ConnectionState is no longer a thing and sessions are initialized
early so we can move more processing early. One such change is
in DNSBL - run the check before EHLO completes. Some further optimizations
are possible there - e.g. start DNSBL check once we get EHLO and have
the result ready once we receive MAIL FROM and act accordingly.
Hi!
I've removed some unused params. But if they where needed for e.g. interface type I've simply `_` them. Also I have to instances to fix tests params, whereby they were passed but not initialized at all, they are in`internal/target/remote/remote_test.go` and `internal/modify/dkim/dkim_test.go`. All test are still passing so it seems like I didn't break anything.
I might've refactored some code away that actually is used but wasn't implemented correctly, but as far as I see their is nothing wrong or erroring going on.
Regressed in 1c42a70533.
It truncates messages to I/O buffer size (4096 bytes).
If first 4096 bytes cover head then it causes "unexpected EOF" (see
#300), otherwise it silently breaks the message.
Several comments were removed since they are not worth the trouble.
A few minor issues were addressed.
Most of remaining comments got corresponding GitHub issues assigned.
The authentication provider can now provide multiple authorization
identities associated with credentials. Protocols that support that
(e.g. JMAP, SASL) can let the client select the wanted identity.
Set of flow restrictions is represented as a "limits" module instance
that can be either created inline via "limits" directive in some modules
(including "remote" target and "smtp" endpoint) or defined globally and
referenced in configuration of modules mentioned above.
This permits a variety of use cases, including shared and separate
counters for various endpoints and also "modules group" style sharing
described in #195.
runtime/trace together with 'go tool trace' provides extremely powerful
tooling for performance (latency) analysis. Since maddy prides itself on
being "optimized for concurrency", it is a good idea to actually live up
to this promise.
Closes#144. No need to reinvent the wheel. The original issue
proposed a solution to use in production to detect "performance
anomalies", it is possible to use runtime/trace in production too, but
the corresponding flag to enable profiler endpoint is hidden behind the
'debugflags' build tag at the moment.
For SMTP code, the basic latency information can be obtained from
regular logs since they include timestamps with millisecond granularity.
After the issue is apparent, it is possible to deploy the server
executable compiled with tracing support and obtain more information
... Also add missing context.Context arguments to smtpconn.C.
It is useful to define background tasks lifetimes more precisely,
especially involving timeouts and other cancellation methods.
On top of that, several tracing facilities are context-based (e.g.
runtime/trace), so it is possible to use them now.
Allow to override DNS resolver address via the -debug.dnsoverride flag
and SMTP port via -debug.smtpport.
All flags are not available unless maddy is built using the 'debugflags'
tag.
The intention is to keep to repo root clean while the list of packages
is slowly growing.
Additionally, a bunch of small (~30 LoC) files in the repo root is
merged into a single maddy.go file, for the same reason.
Most of the internal code is moved into the internal/ directory. Go
toolchain will make it impossible to import these packages from external
applications.
Some packages are renamed and moved into the pkg/ directory in the root.
According to https://github.com/golang-standards/project-layout this is
the de-facto standard to place "library code that's ok to use by
external applications" in.
To clearly define the purpose of top-level directories, README.md files
are added to each.
