Graeme Walker

I don't have the build VM snapshot for 2.4.1 any more so I can't easily interpret that fault address. However, I have a contemporaneous snapshot on another VM so I have done a rebuild there in order to get a map file. So with low confidence I think that fault was while reading the secrets file to get the client-side secret. The code is relatively simple and I'm not smelling an obvious bug. If you want any more help please include a log file and configuration options, and also some background on how...

A firewall is ideal for blocking TCP connections of course, but it's not very helpful to the remote client or their confused network admin. It would be more friendly to use firewall port forwarding to redirect to something that would send back a SMTP greeting with a 5xx status. In emailrelay you could use the authentication bypass feature: maintain a whitelist in the authentication secrets file using "server none" lines and then anyone else will be required to authenticate but not have an account...

Ah yes, of course that's not going work for such an ancient version! You would need to run two separate processes. I have done the work for multiple "--port" values, so it will go into the next release. I have just pushed the changes to the github emailrelay-build repository so you could get new 2.6.1a binaries from there in an hour or so. When upgrading you should check the release notes in the NEWS file for all intervening versions. I've attached the 2.5 and 2.6 release notes. Also note that an...

You need to have multiple configurations "units", which are defined by adding arbitrary prefixes to every configuration item. For example, a-spool-dir c:\emailrelay\spool a-port 25 a-forward-to ... a-poll 60 b-spool-dir c:\emailrelay\spool b-port 587 b-forward-to ... b-poll 60 A unit name is "declared" via the "spool-dir" item and you can use an empty unit name as well as non-empty names. Using multiple "--port" values is not supported because no one has ever asked for it.

As to your question, you can use a "--filter" script to examine the submitter's IP address (stored in the envelope file's "Client" field) or the EHLO id (in the content file's top-most Received header). Then edit the "From", "Sender" and "Reply-To" headers in the content file and/or the "From" address in the envelope file to identify the originator. (There is also a "MailFromAuthOut" field in the envelope file to change the "MAIL ... AUTH=..." id but I'm not sure that will help you at all.) Service...

The reason you didn't get a warning for "oauth:b" is that the "type" field in the secrets file can be the name of a hash function used for CRAM-XXX authentication, but the set of usable hash functions is only available at run-time. The secrets file parsing code is quite liberal in that regard because you don't want the parsing to fail completely just because a particular hash function is no longer available. CRAM authentication is deprecated nowadays so for future releases I will be able to tighten...

In 2.6 the ":b" decoration on "oauth" is parsed out (unlike 2.4), but ignored. This whole area is a bit confusing because there might be a 'native' encoding of a token, like ASN.1-BER or UCS-4, which is then nearly always base64-encoded as a convenience so that it can be presented on a web page and manually copied into a configuration file. In principle the service provider's chosen presentation-layer encoding could be recorded in the secrets file with an "oauth" suffix (perhaps ":u" for uuencoding)...

Ah yes, in v2.4 the ":b" suffix (indicating base64 encoding rather than xtext) is only supported for "plain" password, not "oauth". I will work on improving the warnings in this area.