Menu
▾
▴
#118 Testing E-MailRelay
open
nobody
5
2025-09-22
2025-09-15
No
Good afternoon,
I am attempting to get an older configuration of E-MailRelay to work with the latest (2.6) software version. Ultimately this configuration will integrate into Microsoft SharePoint SE.
I would like to set up a test environment and watch the mail go from sent, to spool, to forward outside of SharePoint and via the E-MailRelay command-line. I am attempting to use emailrelay-textmode.exe to configure the relay and PowerShell to send the email. Should I use the -admin setting? I cannot use Telnet.
I used the following command for configuration (filter is omitted, I just want to send mail and forward in steps):
emailrelay-textmode.exe --log --no-daemon --port 25 --spool-dir [path]\E-MailRelay\spool
I then used PowerShell to send an email to the mail endpoint. I never saw it spool. The email was sent right away. How do I slow things down? I need to eventually test a server-side filter script written in C#. But, I am still learning how the E-MailRelay software works. Any help is appreciated!
Thanks,
M.
By default there is no forwarding (you do not have "--as-client" or "--forward-to" on your command line) so it just spools up whatever is submitted by the remote client. Forwarding can be done by running "emailrelay --as-client ...." separately, or add "--forward-to ..." to the server command line with "--poll" or "--forward-on-disconnect".
You should check that nothing else is listening on port 25 ("netstat -an -p tcp") that might be confusing things.
If anything connects to your emailrelay server on port 25 you should see "connection from" in the log output on stderr.
I use the "--admin" interface in some of my tests to trigger forwarding and to terminate the server, but using a perl script rather than telnet as the client. Telnet is useful as an initial sanity check, but not much more.
Thank you for responding so quickly.
The forwarding configuration is in my configuration file. I now see that running the service and the command line result in two different instances of the relay. I stopped the service and would like to issue the process via commands via the CMD window. This is the old configuration via the start batch file:
start "emailrelay" w:\work\E-MailRelay\emailrelay.exe -e -p 25 -o [mail host]:25 -l -i w:\work\E-MailRelay\emailrelay.pid -O 0 -r -s w:\work\E-MailRelay\spool -k -v -z w:\work\E-MailRelay\filters[script].vbs .
In the new configuration, I removed the poll=0 and used "--forward-to" for testing and will be using "--forward-on-disconnect" in the final configuration.
What I am looking for are the individual commands to walk the process.
1) simplified relay configuration --> start "emailrelay" emailrelay.exe -e -p 25 -o [mail host]:25 -l
-i emailrelay.pid -s w:\work\E-MailRelay\spool (will add script in later tests)
2) send email via PowerShell
3) then forward command from the spool location --> emailrelay --as-client [mail host]:587 --spool-dir W:\Work\E-MailRelay\spool
4) view the email content before the message update --> via the spool directory
5) view the email content after the message update --> via the spool directory
6) mail delivery to the recipient-- unsure what this would be
Somewhere between all that I need to see what the script is doing. I may have to go find the source code for that or figure out how to connect to the process on the server. We did not write the script and it is compiled into an exe.
Will the above commands attain my goals. I am not seeing consistency using the above commands.
Lastly can I alter the content of the message client side using JavaScript as opposed to using server side code?
I think I have figured out the manual command line execution steps:
Step 1 - configure relay to store e-mail to spool dir (must use relay server FQDN to see content as it is relayed)
Step 2 - send email via PS (From PS send to relay server FQDN)
Step 3 - examine email content and envelope and manually change content or email envelope as a test
Step 4 - use relay as client and forward updates mail to host that actually delivers email (From CMD issue--> emailrelay --as-client [host:port] --spool-dir [spool directory])
I'm glad you're making progress. To see what your compiled filter "script" is doing I would just run it from visual studio, without any involvement from emailrelay -- just configure debuggee command-line in visual studio to have the full path of the envelope and content files, but note that prior to version 2.1 emailrelay put only the content file on the filter command-line.
I suppose to make the same point more generally, you should be able to do some regression testing of your filter against different versions of emailrelay without actually running an emailrelay server; just use emailrelay-submit (for example) to create files in the spool directory and pass the filenames on the filter command-line. Envelope and content files created by old versions of emailrelay and emailrelay-submit should be usable by newer versions.
Got it!
On Wed, Sep 17, 2025 at 5:44 PM Graeme Walker
graeme_walker@users.sourceforge.net wrote:
Related
Support Requests: #118
Question. Is my configured relay server acting as a server and client
if I have to forward mail to another virtual server acting on behalf
of my actual mail server?
On Wed, Sep 17, 2025 at 5:44 PM Graeme Walker
graeme_walker@users.sourceforge.net wrote:
Related
Support Requests: #118
I don't understand your distinction between virtual and actual, but email is a store-and-forward messaging system so an email message can go through any number of "transfer agents" where each transfer agent acts as a server to accept incoming messages and also acts as a client to forward them on. E-MailRelay is normally used as a simple store-and-forward relay that does not do any routing itself, so it typically forwards to a dedicated "smarthost" that does routing directly to the recipients' servers.
I think I am ok based on your first response. I forgot to add --forward-on-disconnect to my final e-mailrelay configuration (I don't think the filter program returns the right code on exit). So no forwarding was happening.
We have ServerA setup as a relay forwarding to ServerB to send mail. So I was wondering if I should think of ServerA (and configure) as a server and a client like I did for my manual test? I don't think I need to when using --forward-to and --forward-on-disconnect. I read somewhere that using both was redundant.
Lastly, if the emails contain anything other than plain text or HTML, do I need to use MimeKit/BouncyCastle? Emails coming from SP will contain all kinds of stuff.
Configuring emailrelay as a server is a no-op since by default it listens on port 25 and spools to the standard spool directory.
To configure as a long-lived client you need to disable port 25 with "no-smtp", define the "forward-to" address and provide some way to trigger forwarding, typically with "admin" or "poll".
For a short-lived, one-shot client you need to disable all network serving with "dont-serve" and enable forwarding at startup with "forward" and also define the "forward-to" address -- or just use "--as-client".
For a long-lived relay the server side is enabled by default, and on the client side you must choose when to forward with some combination of "poll", "forward-on-disconnect", "admin", and also define the "forward-to" address.
I hope that indirectly answers your first question.
As for your second question, if your filter edits message bodies (ie. anything after the content headers) then in the general case you will need help from libraries that know about MIME formatting and various compression schemes and text-y content-types (exotic character sets, HTML, docx, etc).
So are using this scenario:
For a long-lived relay the server side is enabled by default, and on the client side you must choose when to forward with some combination of "poll", "forward-on-disconnect", "admin", and also define the "forward-to" address.
Relay is working. Filter is failing. It looks like it fails due to email content-transfer-encoding. It works when sending email in plain text.
The only changes that could affect a filter when upgrading to a new version of emailrelay are (1) the command-line now has two arguments (content and envelope) and (2) the fields in the envelope file will be different. The transfer encoding is part of the content file and emailrelay does not know anything about message content (except that it adds a Received header) -- it treats the message content as an opaque string of bytes.
You should run your filter test first with just the content file on the command-line, and then with an old-style envelope file, keeping the content file the same.