How do you recommend that this be done when the mail is to a valid address?  I guess you could remove the capability of maiser ever sending any respones to non-list members or moderated lists but that to me does more harm than good.

If the list is small and relatively fixed you can copy the list addresses to a dist. list and then do a list scan filter and delete any mail from a non-subscriber. 

Personally, as recommended by David, I use POPFileD to catch the spam.  This catches 99.87% of the spam and moves it to a spam user account so it very seldom gets to any of the mailing lists.  ;-)

Spammers target mailing list names and even maiser. Mercury then sends an error message to the fake sender address. How is this NOT relaying spam?

I don't want Mercury to send ANY error messages off-site. How can I configure this?
 

If you are using MercuryS to receive mail, you can drop bad addresses with a 500 type error if you have 'Accept mail for invalid local addresses' unchecked in MercuryS configuration.

If you are using MercuryD, you may have to go to Configuration/Core module/Files and ensure the Delivery failure template doesn't exist.

[quote user="PaulW"]

If you are using MercuryS to receive mail, you can drop bad addresses with a 500 type error if you have 'Accept mail for invalid local addresses' unchecked in MercuryS configuration.

[/quote]

Been doing that for years. It doesn't stop the spammers who target mailing lists and maiser.

Mr. Spammer wants to target PaulW@YourDomain.com, so he sends an EMail to ListName@MyDomain.com spoofed to look like it came from you. You get back an error bounce that says "List is restricted and you are not a member", with the spam attached. I've just relayed spam to you for Mr. Spammer.

I posted this question because, while working on the server to try and get my earlier mailing list question sorted, I witnessed a connection to maiser, followed immediately by a series of spams targeting mailing lists, some coming from the same IP as the maiser connection and some targeting the same fake EMail used. When I hid all of the mailing lists, I later witnessed spam being relayed by targeting maiser@, which was returning an error to the effect of "not a valid command" with the spam attached. It's absolutely clear to me that someone has written a bot to search out and target Mercury servers to relay spam for them in this way.

When I looked at the MercE log, I was appalled. I was sending more "error bounces" (i.e. spam) than legitimate EMail. 

After posting this question I got fed up and created a couple general

rules that search the body for certain phrases in the error bounces,

and move them to user "Spam" if found, but that's not ideal. It kills

all error bounces, even for local users. I'd rather live with that for

now than the alternative.

Ah, I misunderstood your original question.

Yes, I have received spam of this type.  Your filtering may be one method.  You could also change the maiser name and stop listnames being displayed.

This is really bad. Wasn't aware of this "leak". Has anyone tested it thoroughly to stop moderated false replies?

[quote user="PTPhil"]

Mr. Spammer wants to target PaulW@YourDomain.com, so he sends an EMail to ListName@MyDomain.com spoofed to look like it came from you. You get back an error bounce that says "List is restricted and you are not a member", with the spam attached. I've just relayed spam to you for Mr. Spammer.

[/quote]

No, you haven't "relayed spam" - you've sent a delivery failure notification indicating that an apparently legitimate request has failed.

Let's be clear that generating DFNs is a fundamental aspect of a functional mail server - suggesting that it should be disabled because it might be getting abused in this way (and I have to say pretty uselessly abused too, because it's very hard to see how this type of "spam" could ever sell anything) is the original case of cutting off your leg to fix an ingrowing toenail.

There's a cause-and-effect issue here: the undesirable effect is that spam with bogus headers is reaching the delivery stage and being processed as if it were legitimate: the CAUSE, however, is that a spam message is not being detected as such at an earlier stage. Rather than turning off an essential mail server feature, it would be much more worthwhile to spend time tuning the extensive facilities Mercury provides for suppressing the spam in the first place. Even in v4.01, RBLs, SpamHalter and Content Control, combined with effective transaction filtering, can reduce spam to the level where it is little more than a fairly minor nuisance. Add the extended transaction filtering and GreyWall in v4.5, and it really is hardly even an issue (I see so little spam now that I barely even know it's there).

I'd make a further comment that much of what you're seeing here almost certainly isn't actually any kind of deliberate, concerted attempt to relay spam: it's just mail to arbitrary addresses with a routine range of forged headers that happens to bounce. It's unfortunate and not desirable, but it's also largely unavoidable.

Cheers!

-- David --

I can't believe you wrote four paragraphs to lecture me, but never bothered to answer the question.

I use a couple RBLs, but they only catch so much. I frankly quit using your other anti-spam mechanisms because I was having to tweak it every day to respond to some issue, mail that was blocked that shouldn't have been, etc, and I didn't have the time. We bitbucketed Pegasus and switched to Tbird and that deals with the spam at the user's desktop, does the job mostly without human intervention, and when it doesn't work the end-user can click a spam/not-spam button to fix it without any help. Perhaps it seems normal to you to tweak with this sort of stuff on a daily basis because you do it for a living, but it's not something most people want to mess with. I want the Mercury server to sit in the closet and do its job, and I don't want to mess with it.

Your opinion that these bounces are not spam relays seems defensive. My opinion is that I don't want to relay them. I guess I won't get any help with that here, though.

Does the entire message get bounced to the targeted spam recipient?
If this is the case then it is bad - if only the headers are attached then I see no harm.

We answer when a mail is targeting invalid users, or when a faulting command is creating an exception - since this is good practice.

I'm currently getting a number of messages daily that "requires verification". The content therein are only the headers of spam telling what the origin and actual recipient is. To me this is handy since I can track down where the faulty addressing comes from (like bad formed web pages), I also then have the possibility to block and/or report this address to RBLs thus helping others.