Most of the form spam that’s slipped by my filters for the past few days used bogus email addresses on the sites’ own domains, probably assuming (correctly) that that would prevent the spam from being filtered after the form sends it.
The simple solution, if there’s no legitimate reason whatsoever for someone on the same domain to use the form, is to test for the domain in the “from” address (for example, using preg_match in PHP) and trashing the mail if there’s a match.
I’m just guessing but this only applies to PHP - yes?
All “Web forms” on our (all NodeJS) sites are handled by “POST” controllers.
So this doesn’t apply to us (or does it?) - one of our Vmin sites does seem to get a lot of attack from a certain ru “free” email provider/bot though nothing seems to get through.
preg_match is PHP-specific, if that’s what you mean. To my knowledge it’s not used in any other scripting language.
Sorry, but beyond vaguely knowing what it is, I’m not familiar with Node.js, don’t use it, and don’t know what the equivalent statement or function would be.
The email address that they enter becomes the “Reply to” address in the mail that’s sent to the recipient. Unless I’m mistaken, if any address in the header matches a whitelisted domain, SpamAssassin will allow the message through without filtering.
SpamAssassin isn’t involved at all. If your form is sending the mail via local sendmail or library that sends via local sendmail, then you’re getting dropped straight into the queue, you are not being processed by the rest of the stack. Local mail doesn’t go through spam/AV scanning.
Edit: This is wrong. I’m not thinking clearly. It does not get processed on entry (so greylisting, any RBLs in postfix, etc. do not apply), but it does get processed on delivery via procmail, so anything handled via procmail (spamassassin and clamav in the Virtualmin default config) will be processed.
Er, actually, I guess I’m wrong about this. It’s processed on delivery via procmail. So…nevermind. It does go through SpamAssassin, but still, it should always be From: an address you control, but I guess you could make it a specific address that isn’t included in your whitelist.
Okay, that’s what I thought. I was already composing a response deferring to your knowledge, however, since you co-wrote the thing. I have no problems acknowledging my lack of omniscience.
All of the mail is sent from an address on the domain reflecting what it’s sending. So one that sends assignments to technicians might be assignments@domain.tld.
But my understanding is that SpamAssassin also whitelists mail that has the whitelisted domain in any address in the header; and because the address the visitor enters become the “Reply-to” address, entering a bogus address on the site’s own domain would circumvent the spam filtering.
That wouldn’t happen if the form script drops the mail before it’s sent. It would never be processed as mail.
An outright discard would require a very high probability evaluation based on multiple tests built into the script itself. Merely questionable mail is tagged as such and sent.
For example, placing a URL in the name box would assign points, filling out the form more quickly than any human could would assign more points, certain words or phrases would assign points, etc. The point total then determines the disposition.
Yeah, I’d think if you simply dropped mail with a Reply-to in your own domain (obviously your own domain users don’t need to use a mail form), you’d solve that.
