Mailer-Daemon as spam sender?

[Steve St-Laurent]

Running Tiger Server 10.4.7. I have five users enabled for e-mail accounts. They are all outside my network. IOW, they use their own ISP’s SMPT to send. SMTP is limited to the local network and is password-authenticated.
But I’m seeing a 20-30 messages a day — any is too much — passing through the system. In the queue, the sender shows as Mailer-Daemon. Lists are disabled. When I check the SMTP log, I see the sender showing as “<>” yet Postfix accepts it for delivery.
One user was showing an unusually high number in quota used, so she changed her password to a healthy mix of numbers and letters. But the nonsense continues.
I thought I had done everything required to prevent unauthorized relaying. It would certainly be embarrassing to have my mail server blacklisted as an open relay.
Any suggestions here on where I should be looking to plug this hole?

[krok]

I have the exactly same problem. But my mail server tries to send a mail every minut…. The problem is solved by refusing mails being relayed from 127.0.0.1
So now I get a log entry every minut that looks like this:
[b]Oct 27 11:27:11 server postfix/qmgr[19906]: warning: connect to transport smtp: Connection refused[/b]
So now no spam is send from my server.
But this is not actually a real solution, because now I can’t use webmail to send mail (witch is bad). At first I was thinking if it was a php-script sending once per minut, but even if I try to shut down the webserver it still tries to send, witch (I think) rule out the webserver as the source of these spam mails.

So where to go next?

[uptimejeff]

If you are using the content filter, you are probably seeing bounces from the content filter (amavisd).

Jeff

[Moofo]

Is there any way to see those messages from the command line ?

And also, is there an administrator mode to see all the mailboxes on the system ?

[Steve St-Laurent]

Think I’ll go with Lenny’s solution [thanks!] and deny relays from 127.0.0.1. I don’t use webmail, so his downside doesn’t apply.

Someone asked whether the stuff was definitely spam or system mail. I can confirm it’s spam, probably bounced as the result of forged mail headers.

What I’ll never understand is how they are people so stupid that they would buy drugs, watches, whatever – turning over their credit-card number! – to someone who lied, deceived or otherwise broke into their mailbox. But they must exist, otherwise spam would die quickly.

[Steve St-Laurent]

I’ve tried Lenny’s suggestion to deny relays from 127.0.0.1 but it still seems to let them through. Example:

Nov 20 11:35:54 s64-180-110-181 postfix/smtpd[16737]: connect from localhost[127.0.0.1]
Nov 20 11:35:54 s64-180-110-181 postfix/smtpd[16737]: 73149460D15: client=localhost[127.0.0.1]
Nov 20 11:35:54 s64-180-110-181 postfix/cleanup[16719]: 73149460D15: message-id=
Nov 20 11:35:54 s64-180-110-181 postfix/qmgr[16094]: 73149460D15: from=, size=3557, nrcpt=1 (queue active)
Nov 20 11:35:54 s64-180-110-181 postfix/pipe[16739]: 73149460D15: to=, relay=cyrus, delay=0, status=sent (holecomm.ca)
Nov 20 11:35:54 s64-180-110-181 postfix/qmgr[16094]: 73149460D15: removed

I’m using Postfix, the 10.4 Server’s built-in mail server, and it’s configured to allow mail only from the local IP address. Can anyone spot something obvious from the above? Thx.

[alpha39]

Super old topic, but I’d run into the same thing and found the cause.

Turns out it had to do with my /etc/aliases file sending messages to a certain account to both the local account and a remote one. The trouble messages were spam, and when it tried to send it to the remote account, -something- happened which resulted in my server then sending something back to the email the spam came from, which then got rejected by that server and caused it to hang around in the mail queue suspiciously.

Pretty obscure, but the logs really aren’t telling me much more then that, but hopefully this might be a bit of help to someone.

[Steve St-Laurent]

I don’t think that’s the case here.

I’ve tried posting more details but my message here is getting rejected by the forum software as spam.

[Steve St-Laurent]

Thanks!

Specifically, I was seeing Mailer-Daemon loading the queue with bounces on truckloads of messages from an empty sender [empty angle brackets] to all sorts of gibberish non-existent email addresses for a virtually hosted domain.

As noted earlier, relaying is turned off for 127.0.0.1. Heck, I even tried entering Mailer-Daemon on the reject-relays list. But nothing short of turning off mail for that domain stopped the outgoing flood. The domain is mine; I’m the only one using it as an email address. With mail hosting turned off, the stuff never makes the queue, of course, because of the no-relay rules in place.

Big concern is landing on a “back-scatter spammer” list. I still figure it’s forged reply-to header nonsense. Is there a simple way to tell the Mailer-Daemon to just forget about it if it can’t deliver something? Not ideal, but it’s still better than this mess.

I see lots of stuff out there about editing the Postfix configuration directly to introduce tighter controls. Then my hand starts to shake . . .

[Steve St-Laurent]

Months later . . . perhaps I can rephrase the question.

Is there any way to disable MAILER-DAEMON? The forged reply-to email prompts the mailer daemon to try and send along spam. I know this is what is happening. Google “mailer daemon spam” and there’s lots of evidence of this happening, but no easy solution.

A fire-and-forget mail sender, while inconvenient, would be an improvement. In other words, I want mailer daemon to ignore all bouncebacks, returns to sender, etc. If you can’t deliver it on the first go, forget about it.

Is there a line in the Postfix config that would let me disable this useless daemon? Thx.

[foilpan]

[QUOTE][u]Quote by: Steve+St-Laurent[/u][p]Months later . . . perhaps I can rephrase the question.

Is there any way to disable MAILER-DAEMON? The forged reply-to email prompts the mailer daemon to try and send along spam. I know this is what is happening. Google “mailer daemon spam” and there’s lots of evidence of this happening, but no easy solution.

A fire-and-forget mail sender, while inconvenient, would be an improvement. In other words, I want mailer daemon to ignore all bouncebacks, returns to sender, etc. If you can’t deliver it on the first go, forget about it.

Is there a line in the Postfix config that would let me disable this useless daemon? Thx.[/p][/QUOTE]

you don’t want to do that. if you do, you may be blacklisted by these folks: http://rfc-ignorant.org/policy-dsn.php

the “book of postfix” (no starch press) advises treating the empty envelope sender as any valid recipient, letting message restrictions do the work.

unless i misread your problem…

[Steve St-Laurent]

Thanks for the follow-up. I checked out the link . . . and it left me discouraged. OK, if a fire-and-forget SMTP is not nice and will get me into trouble, is there anything can be done about forged reply-to mail headers that would stop spammers from, in effect, using my stunned mailer daemon to NOT send along spam?

Is there a way to just kill incoming email for non-existent addresses? That would solve it too. I keep dreaming of a check box in the OS X Server mail configuration that would do just that but it doesn’t exist, does it? Honestly, that one feature would be worth the price of Leopard to me.

This is nuts. Getting dragged into back-scatter spam will cause problems with one group, but disabling the mailer daemon will get you into doodoo with another.

What’s happening: Spammers put a non-existent email address at my domain as the sender [reply-to] of a spam message. When it doesn’t get delivered — for whatever reason — it bounces back to my mail server. There the trusty mailer daemon tries to send it again. 🙄

[Steve St-Laurent]

One more thought . . . What exactly is the value of a checkbox that says “copy undeliverable mail to:”? It would be useful if I could DELIVER, not copy, otherwise undeliverable mail to a specific account then have all mail delivered to that account deleted.

That would be a big plus. Simply getting a copy of undeliverable mail that the goofy mailer daemon is trying to return to yet another forged address just adds insult to injury.

How do other people handle this? I guess my irritation is showing; apologies for that. My guess is that there are probably a number of tweaks that can be made to the Postfix configuration file that would improve the situation. Apple’s mail documentation is useless on this point.

[foilpan]

[QUOTE][u]Quote by: Steve+St-Laurent[/u][p]Thanks for the follow-up. I checked out the link . . . and it left me discouraged. OK, if a fire-and-forget SMTP is not nice and will get me into trouble, is there anything can be done about forged reply-to mail headers that would stop spammers from, in effect, using my stunned mailer daemon to NOT send along spam?

Is there a way to just kill incoming email for non-existent addresses? That would solve it too. I keep dreaming of a check box in the OS X Server mail configuration that would do just that but it doesn’t exist, does it? Honestly, that one feature would be worth the price of Leopard to me.

This is nuts. Getting dragged into back-scatter spam will cause problems with one group, but disabling the mailer daemon will get you into doodoo with another.

What’s happening: Spammers put a non-existent email address at my domain as the sender [reply-to] of a spam message. When it doesn’t get delivered — for whatever reason — it bounces back to my mail server. There the trusty mailer daemon tries to send it again. 🙄 [/p][/QUOTE]

+++

i recommend the book of postfix. it’s a great reference.

you can try adding some smtpd_recipient options to your postfix config.

reject_multi_recipient_bounce will reject messages to multiple addresses from the empty (<>) envelope sender.

reject_unverified_sender will attempt to verify the sender and reject messages if that fails.

chapters 8 and 9 should give you a good overview of filtering and mail restriction options. anyone who needs finer control over postfix will abandon the server admin tools and manage the configuration by hand. that’s just the way it is.

[Author]

Posts