Hi all 
It’s been a while… lots of Real Life.
I’m diagnosing some further issues, newly cropped up between a couple of years ago and now. (This ties back to this Dec 2021 post )
SYMPTOM: I can’t send messages to the spamtrap/hamtrap aliases anymore.
[UPDATE: I have a workaround for some issues]
CONTEXT:
- I have a primary virtual server, using a domain name that exists but NEVER sends or receives email as itself. It IS our MX. (my.example.com) (Why? Among other things it’s a perfect honeytrap. Any email to or from that domain is, by definition, bad
) - I have an alias of that server that’s used for most of our email (aliasdomain.net)
- I forward spamtrap/hamtrap emails to the appropriate email alias using an actual user on the host system, sent via an SSH tunnel to server submission port 587 (from my workstation on the local LAN (192.168.1.*)
- Here’s the return path header on the forwarded email
Return-Path: <MyName@aliasdomain.net>
DIAGNOSIS:
- First item, easily fixed, was a permission issue. Don’t know why but the receiving files had 0x660 permission. Changed to 0x666 and all was well.
- Then it got a lot harder. (I had to reinstall Data::Dumper::HTML to work this out. I’ve updated my instructions at the above link to match current/future reality…)
Bottom line, a few things have changed in Virtualmin/Webmin… and I don’t know how to reconfigure nor how to patch code to work around them. I see the following issues, one way or another (with $debug enabled in spamtrap.pl):
- In virtual server configuration for the aliasdomain.net alias, there’s no entry for spam filtering so spamtrap.pl complains “spam filtering is not enabled” for aliasdomain.net – that’s not really true however!
- I also have not found a way to properly set up spamtrap aliases for the aliasdomain.net alias, and spamtrap complains about that as well. (“missing spamtrap aliases”)
- [UPDATE: I have a workaround but not resolution for this item. See below.] Spamtrap also complains about the Received header, saying “Invalid received …” because it came from the local LAN and not the Virtualmin server itself. (I would think spamtrap.pl should pay attention to the list of approved “local” IP nets/hosts?)
UPDATE: A viable workaround for this aspect: connect to the server using an SSH tunnel, with port 587 (submission) forwarded. This way, the email appears to come from the webmin/virtualmin server itself. It’s still true that emails to spamtrap from the local LAN are not accepted. 
Now, since aliasdomain.net is simply an alias for the actual virtual server my.example.com – it appears there is code in spamtrap.pl to make use of the alias domains ($aliasdoms), which partly works. The correct user is found even if associated with alias.
- But the return-path header says it was sent by user@aliasdomain.net – and that fails the return path test. (“Bad return path aliasdomain.net”)
Put all of those together and I have four (bolded above) non-fixable challenges in the spamtrap/hamtrap system, with my setup.
RESOLUTION GUESSES:
- Is there a way to treat any trusted LAN IP address as local? That might solve quite a lot of this. Perhaps it would even modify the return path to claim the server as the originating source.
- Could it be that the
$aliasdomscode needs to be expanded so the parent domain info is used as needed when examining email from an $aliasdoms domain?
Any help, hints or questions mucho appreciated!
| SYSTEM INFORMATION | |
|---|---|
| Operating system | Debian Linux 11 |
| Webmin version | 2.302 |
| Usermin version | 2.202 |
| Virtualmin version | 7.30.4 * |