Activity for E-MailRelay
-
Graeme Walker committed [9ba221] on Git
fix address verifier abort
-
multiple --port values
-
fix network verifier abort
-
v2.6.1 baseline, reverting 7ed8fc6
-
github/sourceforge merge
-
v2.6.1 fixes for address verifier exit 100 etc
-
v2.6.1
-
v2.6b
-
DavidM created ticket #45
Offer more logging strategies
-
Doh! That's why I could not get it to work! Thanks - now works fine. Great SMTP server.
-
v2.6.1 fixes for address verifier exit 100 etc
-
(I shouldn't post code off the top of my head -- in the original version the dots in the address would match any character in the address, not just a literal dot. I've changed it to use an exact match.) To allow a handful of addresses you could just extend the "test" expression with "-o": if test "$ip" = "10.0.0.1" -o "$ip" = "192.168.1.1" -o ...etc... or iterate through a list: whitelist="10.0.0.1 192.168.1.1" for w in $whitelist; do test "$ip" = "$w" && allow=y; done if test "$allow" = "y" then...
-
Since you asked about using the address-verifier to authorise the IP address I was going to suggest a script like this (or equivalent in JScript): #!/bin/sh ip=`IFS=: ; set -- $3 ; echo $1` if test "$ip" = "10.0.0.1" then echo "" echo "$1" exit 1 else exit 100 fi Unfortunately the connection-abort feature is broken in v2.6.x -- the protocol stops but the connection persists. The alternative is to reject all recipient addresses with an error message. The remote client cannot then submit the e-mail...
-
Thanks - good pointers - much appreciated. Is whitelist comma separated or something else? (CDIR perhaps?)
-
Since you asked about using the address-verifier to authorise the IP address I was going to suggest a script like this (or equivalent in JScript): #!/bin/sh whitelist="10.0.0.1" if echo "$3" | grep -q "^$whitelist:" then echo "" echo "$1" exit 1 else exit 100 fi Unfortunately the connection-abort feature is broken in v2.6.x -- the protocol stops but the connection persists. The alternative is to reject all recipient addresses with an error message. The remote client cannot then submit the e-mail...
-
FWIW... In our dev set up I have set up plain text authentication which works for us as we only have one real world box connecting to our site. So connections which are not authnticated fail like this: emailrelay: 20260317.144321.786: info: 18.209.86.113;4843: smtp connection from 18.209.86.113:4843 emailrelay: 20260317.144322.385: info: dnsbl: address [18.209.86.113] allowed by [spam.dnsbl.example.com] emailrelay: 20260317.144322.385: info: dnsbl: address [18.209.86.113] allowed by [block.dnsbl.example.com]...
-
I'll respond on your ticket https://sourceforge.net/p/emailrelay/support-requests/134
-
Can you expand on this a bit please - possibly with more details on the address verifier..? Thanks.
-
Can you expand on this a bit please - possibly with more details on the address verifier..? Thanks.
-
How to only allow connections from approved/trusted real world IPs
-
Thanks for the extra information. There is nothing unusual in that log snippet or command-line and it does agree with the suggestion that the fault was while instantiating the client secret. I have reviewed the code and re-run unit tests, but I can't see anything suspicious. I note that the log is not showing the secrets file being re-read at that time ("re-reading secrets file"), but that might be one thing to keep an eye on. For future releases I will add the map file to the output from the GitHub...
-
Michael J posted a comment on ticket #133
emailrelay: 20260307.112801.264: info: smtp connection from <IP1> emailrelay: 20260307.112801.264: info: tx>>: "220 <domainname> -- E-MailRelay V2.4.1 -- Service ready" emailrelay: 20260307.112801.264: info: rx<<: "EHLO <hostname>" emailrelay: 20260307.112801.264: info: tx>>: "<domainname> says hello\r\n250-AUTH CRAM-MD5 CRAM-SHA1 CRAM-SHA256 PLAIN LOGIN\r\n250-STARTTLS\r\n250-VRFY\r\n250 8BITMIME" emailrelay: 20260307.112801.265: info: rx<<: "AUTH login [not logged]" emailrelay: 20260307.112801.265:...
-
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...
-
APPCRASH
-
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...
-
Arjan Anthonisse created ticket #132
Allow specific remote clients
-
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...
-
Hello, Thanks for the the example, this worked in our test environment however in our prod we still use Version 2.4.1 which doesnt seem to include multiple configs. Do you have any best practices or tips on how to update to 2.6.1? Kind regards
-
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.
-
Listening on ports 25 and 587
-
Thaht worked great, Thank you.
-
E-MailRelay updated /emailrelay/readme.md
-
-
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)...
-
So to use the latest version of EMailrelay do we have to exchange the exe files an put ":b" to the secret files again? Another question: We use the software to forward Mails from many different devices like inverter, printers, iot devices etc. For now we had for each device a different mail address like dev1@domain.com oder mymail@iot-domain.com. As the mails are forwarded to MS365 the service user in the secret file is sending the mails. Is there a secure way to continue using the existing device...
-
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.
-
I think I got it. I deleted the ":b" from the "oauth" parameter and the Connection was successful now. I will continue to monitor the behavior and then provide feedback on whether this was the final solution. Thank you for your help so far.
-
Maybe our configuration in the batch file isn't correct? it worked on port 25 before. Can you see any failures? start "emailrelay" "C:\Program Files (x86)\E-MailRelay\emailrelay.exe" --poll 3600 --client-tls --close-stderr --forward-on-disconnect --forward-to smtp.office365.com:587 --log --log-file C:\ProgramData\E-MailRelay\log\emailrelay-log-%%d.txt --log-time --pid-file C:\ProgramData\E-MailRelay\emailrelay.pid --remote-clients --client-auth C:\ProgramData\E-MailRelay\emailrelay.auth --spool-dir...
-
The secret file has only 4 fields for any entry. We have a "server plain" entry and one "client oauth:b name@domain.de ZETUDFTG887...." entry. I cannot see the error in here.
-
Maybe our configuration in the batch file isn't correct? Can you see any failures? start "emailrelay" "C:\Program Files (x86)\E-MailRelay\emailrelay.exe" --poll 3600 --client-tls --close-stderr --forward-on-disconnect --forward-to smtp.office365.com:587 --log --log-file C:\ProgramData\E-MailRelay\log\emailrelay-log-%%d.txt --log-time --pid-file C:\ProgramData\E-MailRelay\emailrelay.pid --remote-clients --client-auth C:\ProgramData\E-MailRelay\emailrelay.auth --spool-dir C:\ProgramData\E-MailRelay\spool...
-
Also check that the "client oauth" line only has four space-delimited fields. A fifth field would be interpreted as a client selector and that in that case the secret would be ignored with nothing in the log file.
-
The immediate problem is that emailrelay cannot find a suitable secret in the secrets file. The MS server has said that it can authenticate with two mechanisms, LOGIN and XOATH, but emailrelay cannot find a plaintext password (for LOGIN) or an OAuth token (for XOAUTH) in its secrets file. There are no line length limits in reading the secrets file. Any parsing errors will be logged in the emailrelay log file and you can find those by searching for the secrets filename (typically "emailrelay.auth")....
-
Sorry, my mistake. Actually, "oauth" is entered in the file. The token is converted into base64 and over has over 2800 characters. Can this be a problem?
-
That should be "oauth:b", not "auth:b". The idea of adding a blank line was just to update the file timestamp. If that made no difference then your problem is not a race condition on the file's contents. The error message ("check for a compatible secret") comes from emailrelay when first talking to the MS server. It is unlikely that MS will check with spamhaus at that point.
-
Hello, In the ermailrelay.auth file, we have a line with the following structure, which is assigned a new token by the task scheduler every 45 minutes. The token is generated by the ps1 script. client auth:b name@domain.com DHFUAZDH.... Every time the taks is running, a new token is generated and the secret file ist updated. We even created a blank file with a blank line an without it. The result is always the same. Unfortunately, yesterday SPAMHAUS has listed our IP as a "spammers" and currently...
-
Does the secrets file look properly formatted with a "client oauth" line? What happens if you just do another token update? Or use a text editor to add a blank line to the file? You should check whether your update script does an atomic update to the emailrelay secrets file, typically by writing to a new file with a temporary name and then renaming it. Otherwise there can be a race condition where emailrelay sees the file before it has been fully updated.
-
FYI: we use Version 2.4.1
-
Authentication MS365 Problem - compatible client secret
-
Steve Ricketts posted a comment on ticket #129
Your quick response is very much appreciated. I put the two .exe's in and sent a couple of emails to the troublesome server and they were accepted... but then again, a lot of them from that company were on Monday. There will be another big mailing on Friday so that will be a much better test. But so far, so good!! Thanks again for your great support!
-
It's strange to have inconsistent behaviour. Could there be load-balancing or A/B testing that is directing you do different servers? I have managed to update the TLS libraries and windows build scripts on github so there are now some new binaries that you might want to try out. Just extract the emailrelay.exe and/or emailrelay-textmode.exe files from the "Artifacts" zip file. There are no emailrelay code changes so the error messages in the envelope file might still be a little unhelpful.
-
Tried tls-config=mbedtls,tlsv1.2 and it worked. Tried with that and config-tls both in the config file but got the error again.
-
Waiting with bated breath… 😉
-
Waiting with baited breath… 😉
-
Actually it's likely to be just that the server requires TLS v1.3. I will endeavour to update the emailrelay-build repository on GitHub to get a build against LibreSSL v4.x and/or MbedTLS v3.6.x.
-
So there's still scope for improving the error in the envelope file! I would use wireshark to examine the TLS handshake to see what the problem is. It might be some new feature of the TLS protocol that did not make it into LibreSSL v3.8.2. As an experiment you could try switching to MbedTLS with --tls-config=mbedtls. The 'invalid record' is what I would expect when using --client-tls-connection because that is the TLS library getting confused as it receives the plaintext SMTP greeting from the remote...
-
I'm not sure if this is the change you were talking about: X-MailRelay-Reason: routing filter failed: failed: failed X-MailRelay-ReasonCode: But now I'm also getting this and I'm not sure what it means: X-MailRelay-Reason: tls error: mbedtls_ssl_handshake(): mbedtls [SSL - The requested feature is not available] X-MailRelay-ReasonCode: I switched from client-tls to client-tls-connection and got a slightly different error: error: mbedtls_ssl_handshake(): mbedtls [SSL - An invalid SSL record was received]...
-
I’m not sure if this is the change you were talking about: X-MailRelay-Reason: routing filter failed: failed: failed X-MailRelay-ReasonCode: But now I’m also getting this and I’m not sure what it means: X-MailRelay-Reason: tls error: mbedtls_ssl_handshake(): mbedtls [SSL - The requested feature is not available] X-MailRelay-ReasonCode: I switched from client-tls to client-tls-connection and got a slightly different error: error: mbedtls_ssl_handshake(): mbedtls [SSL - An invalid SSL record was received]...
-
Awesome! I'll download it and give it a go. Thanks for the heads-up and all the good work! Sr
-
Alexander Süß posted a comment on ticket #120
checked: Think about a /silent switch for updating as well ;-) Did not found any option running /? or /help - might help for automated rollout ;-) Mit freundlichen Grüßen Alexander Süß ------ Originalnachricht ------ Von "Graeme Walker" graeme_walker@users.sourceforge.net An "[emailrelay:support-requests]" 120@support-requests.emailrelay.p.re.sourceforge.net Datum 05.02.2026 14:19:04 Betreff [emailrelay:support-requests] #120 Instant spool processing on startup Are you looking at the "w64" zip file,...
-
🙂 Thanks for reply, I used the sourceforce linked info which ran to xp download 8-) NOW I found the folder structure ;-) THANKS! and sorry - I really tried to find it before ;-) Mit freundlichen Grüßen Alexander Süß ------ Originalnachricht ------ Von "Graeme Walker" graeme_walker@users.sourceforge.net An "[emailrelay:support-requests]" 120@support-requests.emailrelay.p.re.sourceforge.net Datum 05.02.2026 14:19:04 Betreff [emailrelay:support-requests] #120 Instant spool processing on startup Are...
-
Are you looking at the "w64" zip file, or "winxp"? The w64 zip file has emailrelay-setup.exe, surely? In any case, if you are upgrading from 2.6 you can just copy the executables from the "programs" sub-directory within the zip file into %ProgramFiles%/emailrelay. Also, for the 2.7 release I am considering modifing the "--poll" option to allow two values: an 'initial' time and a 'subsequent' time period, like "--poll=1ms,60". The motivation comes from a new "--poll-run" feature, but it is relevant...
-
Hello ;-) Today I found the new build 2.6.1 - but unfortunately in the zip the windows-installer is missing: But while it is still mentioned in the documentatiuon: Please verify and let me know, when the new download becomes available... Mit freundlichen Grüßen Alexander Süß ------ Originalnachricht ------ Von "Graeme Walker" graeme_walker@users.sourceforge.net An "[emailrelay:support-requests]" 120@support-requests.emailrelay.p.re.sourceforge.net Datum 03.02.2026 20:46:44 Betreff [emailrelay:support-requests]...
-
Awesome! I'll download it and give it a go. Thanks for the heads-up and all the good work! Sr From: support-requests@emailrelay.p.re.sourceforge.net support-requests@emailrelay.p.re.sourceforge.net On Behalf Of Graeme Walker Sent: Tuesday, February 3, 2026 3:08 PM To: [emailrelay:support-requests] 129@support-requests.emailrelay.p.re.sourceforge.net Subject: [emailrelay:support-requests] #129 Bad mail best practice and volume expectations FYI the new 2.6.1 release improves the "Reason" string written...
-
Docker file?
-
Create arm emailrelay_x.x_arm64-deb12.deb
-
verifying sender domains
-
For the new 2.6.1 release I have tried to make the example scripts more prominent in the sourceforge website, which is now generated with sphinx rather than doxygen.
-
Network filter abandon result
-
This is fixed in the new 2.6.1 release.
-
emailrelay-keygen.exe flagged as suspicious by AV and VirusTotal
-
FYI the new 2.6.1 release uses executables built by the GitHub Actions CI/CD server so you can check their provenance with SHA256 hashes.
-
FYI the new 2.6.1 release improves the "Reason" string written into the envelope file when a "mx:" filter fails.
-
Sending some emails fine, others having some issue
-
Can't get it to relay using the token updater
-
.content, .envelope stuck in spool
-
--Domain not setting EHLO/HELO name
-
I have improved the option parsing in the new 2.6.1 release to give better error reporting in this situation.
-
split: filter errors
-
Multiple Client Connections
-
having trouble setting up
-
Instant spool processing on startup
-
Mails are getting sent directly instead of one per minute when using --client-filter exit:102 and --poll 60
-
This is fixed in v2.6.1.
-
Testing E-MailRelay
-
Send via MX
-
Throughput and ClientAccountSelector
-
about NDR
-
Reducing permissions as a Windows service
-
Removing commas from outbound email message
-
HP iLo 4
-
Microsoft 365 (Exchange Online) "addon" for E-MailRelay
-
Cannot get address verifier to execute
-
emailrelay does not send messages introduces by emailrelay-submit
-
make fails: openssl too old
-
No directory examples on GitHub for emailrelay-client-filter
-
Using ncat.exe to connect to emailrelay is abnormal
-
1 >
