Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

'Undeliverable Mail Return To Sender' spam?

As of late, we have been getting 'undeliverable mail' which appears to be spam. The long headers appear to indicate that it is indeed coming from our mail server and the body of the message goes something like this:

This is the Postfix program at host nopali.com.

I'm sorry to have to inform you that your message could not be
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to <postmaster>

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

The Postfix program

<clinique@ccpmtl.com>: host 127.0.0.1[127.0.0.1] said: 550 5.7.1 Message
content rejected, UBE, id=21361-04 (in reply to end of DATA command)
Reporting-MTA: dns; nopali.com
X-Postfix-Queue-ID: 7260D27DAB9
X-Postfix-Sender: rfc822; clinique@ccpmtl.com
Arrival-Date: Sat, 23 Dec 2006 04:10:46 -0500 (EST)

Final-Recipient: rfc822; clinique@ccpmtl.com
Action: failed
Status: 5.0.0
Diagnostic-Code: X-Postfix; host 127.0.0.1[127.0.0.1] said: 550 5.7.1 Message
content rejected, UBE, id=21361-04 (in reply to end of DATA command)

From: "Ronald Myers" <qbdldfs@alderking.com>
Date: December 23, 2006 4:11:11 AM EST (CA)
To: clinique@ccpmtl.com
Subject: Because that is curious girdle, and Hormah, and some therefore,


...and there is generally a spamish content underneath.

Has anyone encountered this?

I thought perhaps that somehow others were able to use my mail cue, but I closed the firewall for SMTP mail to only favourable IPs. However, when I look at my mail cue, I see a bunch of things waiting to be sent out. They appear to be a bunch of spam that the server trying to return. The cue would typically have this message:

Message ID: 266692764C8
Date: Thu Dec 21 13:31:52
Size: 6742
Sender: MAILER-DAEMON
Recipient(s) & Status:
----------------------
online_identity@wc.wachovia.com:
connect to wc.wachovia.com[169.200.182.108]: Operation timed out


It appears that the server is trying to return spammed mail to sender and it is timing out. I am not sure, though. This would not make sense since I have spam being redirected to a separate spam_depot account.

Any ideas on how to figure this one out?

Mirror Drive, Mac OS X (10.4.8)

Posted on Dec 23, 2006 4:17 AM

Reply
17 replies

Dec 23, 2006 4:34 AM in response to Zatman

Do you use virtual domains or local host aliases? If yes, these are most likely just bounces from your content filter.

This is because Apple's standard configuration will let mail for unknown virtual users reach the content filter. Next the content filter tries to bounce them back.

If you do use virtual domains and want to get rid of this problem see my tutorial on "Rejecting virtual mail users before the content-filter on OS X Server" here:
http://osx.topicdesk.com/downloads/

Alex

Dec 23, 2006 12:37 PM in response to pterobyte

I followed the instructions from your link and the problem seems to persist. SInce implementing the changes, I have had a couple of similar emails in the mail cue and have received a couple of similar 'rejected' mails as described above.

I even added the suggested:

unknown virtual_alias_rejectcode = 450
unknown virtual_mailbox_rejectcode = 450

that was mentioned in the link and the rejected mail was the same as before the changes (ie error 550).

The only thing I can maybe have done 'wrong' is when creating the virtual domainsdummy file, I was not sure how to separate the words in the line:

dummy.local allow

I used spaces. Should it be a tab?

Any other ideas?

Thanks

Dec 25, 2006 6:38 AM in response to UptimeJeff

Great, I found some ideas using your clues. What I did was modify:

$final bad_headerdestiny = D_PASS; # (defaults to D_PASS), D_BOUNCE suggested

to:

$final bad_headerdestiny = D_DISCARD; # (defaults to D_PASS), D_BOUNCE suggested


Is this a wise thing to do? If I try to send email to a bad email, I will never know!

Thanks

Dec 25, 2006 5:19 PM in response to Zatman

I can't tell you if this is a wise decision for your setup, you need to make that call.

You are getting into settings which stray far from the GUI and the support of Apple, venture forward carefully..

The comments within the amavisd.conf file and threads in this forum contain most/all of what you may require. Spend time reviewing the config file. all of it's options, the flow of amavis (well documented) and how amavis links to postfix...... then out of thousands of possible configurations you can make the decision of what is best for your server.

Some hints... (which were documented in an earlier thread)

The GUI sets tag2 and sa kill_leveldflt the same:
$sa kill_leveldeflt = $sa tag2_leveldeflt;

You can change this so that one set of actions is performed at tag2 and a more extreme action at the kill level. something like this works well for a well trained server:
$sa tag2_leveldeflt = 3.0
$sa kill_leveldeflt = 6.0;

When the kill level is reached, the final spamdestiny action is performed. If you bounce or reject, you will generate bounces in your queue. If you discard, the no bounce is generated. Even if you discard, you still have a quarantine.
The default is to quarantine the spam as files in /var/virusmails Many people never look in this folder, and it can easily fill-up. Look in your settings for something like this:
$QUARANTINEDIR = '/var/virusmails';
you can comment this to:
#$QUARANTINEDIR = '/var/virusmails';
to disable the quarantining to a directory.

You can quarantine to an email address, read the file, it's pretty clear.

Take the time to read through the file. Make changes one at a time and allow plenty of testing between changes. Make any files you change. Be sure to stop/start mail service to activate changes.

Jeff

Dec 26, 2006 9:28 AM in response to Zatman

In general, you want to D_PASS e-mails with bad headers:

$final bad_headerdestiny = D_PASS; # (defaults to D_PASS)

Bad headers are more of an inconvenience than anything else. While, in theory, they can create problems for MTAs and MDAs, they seldom do. Most bad headers are the result of a non-standard character being placed in the subject line--pretty benign stuff. You will block some legitimate e-mail if you use D_DISCARD for mail with bad headers.

If you are worried about bad headers, you can defange them by uncommenting the line:

# $defang badheader = 1; # default is false: don't modify mail body.

Dec 26, 2006 2:26 PM in response to Joel Mcintosh1

I have tried these suggestions and I still have the same problem. I will leave the setting the D_PASS fro now and investigate this further. I have the feeling that it originates from faked headers, but I am not sure.

The annoyance is minor for now. I am striving for perfection, though. It somehow sad when you know some of your spam is coming from your own mail server...

Thanks!

Dec 27, 2006 5:32 AM in response to Joel Mcintosh1

After poring through the forum and the above suggestions, this is what I have done:

in /etc/amavisd.conf :

set the following:

$final virusdestiny = D_DISCARD;
$final banneddestiny = D_BOUNCE;
$final spamdestiny = D_DISCARD;
$final bad_headerdestiny = D_PASS;

(Uptime's comment above mentioned that D_DISCARD still goes through the quarantine process)


I also commented:

#$QUARANTINEDIR = '/var/virusmails';

(since I never check that directory. Kind of odd that it is ON by default)


I quarantine mail to:

$virus quarantineto = 'infection@mydomain.com';


and spam to:


$spam quarantineto = 'spammed@mydomain.com'


Finally, I set the tag and kill levels to:

$sa tag_leveldeflt = -999;
$sa tag2_leveldeflt = 4.0;
$sa kill_leveldeflt = 7.0;


I will see what happens and get back in a couple of days.

Thanks for the tips!

Dec 27, 2006 10:04 AM in response to Zatman

One funny thing happened after making the above changes. I rebooted the server and found that mail was appended with *JunkMail* and being delivered, even though this was not the setting before reboot.

I then looked through Server Admin Filter tab and saw that the setting was indeed to deliver with the **Junk Mail** prefix. So I changed to redirect to my spam quarantine using Server Admin.

I then checked the /etc/amavisd.conf file and it had reverted all my previous changes (except the #QUARANTINEDIR change).

Does this mean I should not use Server Admin anymore for filtering adjustments? I still don't get how the **Junk Mail** delivered was set the first time.

Also, the Server Admin now still shows **Junk Mail** deliver even though amamvisd.conf has kept my changes.

Mirror Drive Tower Mac OS X (10.4.8)

Powerbook 17

Dec 27, 2006 12:49 PM in response to Zatman

Ok, here's the deal after some testing:

The above manual settings seem to work extremely well, but Server Admin seems to overwite some of the settings on a Mail Server restart. In order to get some sort of concordance, I had to do a 2 step process:

1) In Server Admin, go to the Filters area and select 'Junk Mail Should Be Deleted'. I left notifications off. Restart the mail server.

2) Edit /etc/amavisd.conf and you will find:
- '$final spamdestiny = D_DISCARD;' remains as D_DISCARD and does not revert to D_REJECT. This is good.
- #$QUARANTINEDIR = '/var/virusmails' will remain commented out. This is good.
-$spam quarantineto = 'spammed@mydomain.com' will be commented out. This is bad since we want spam to be forwarded to my quarantine account. I simply uncommented it and a server restart does not seem to touch this.
-$sa tag_leveldeflt = -999 remains unchanged
-$sa tag2_leveldeflt = 4.0 remains unchanged and corresponds to the Server Admin spam tolerance setting

The only outstanding problem is the line:
-$sa kill_leveldeflt = 7.0

This line ALWAYS gets rewritten with a server reboot as the default

$sa kill_leveldeflt = $sa tag2_leveldeflt

Can anyone suggest a workaround? I had thought of repeating the line:
$sa kill_leveldeflt = $sa tag2_leveldeflt
$sa kill_leveldeflt = 7.0

And this will not be overwritten by a server restart.

However, I am not sure if you can have 2 lines in tandem in that way. Can anyone confirm if this is ok?

Thanks

Dec 27, 2006 2:07 PM in response to Zatman

Are you also saving any mail configuration changes in Server Admin?

Basically, once you've made the jump over to editing your configuration files manually, you need to stop editing your mail configuration via Server Admin. As a general rule, its one or the other.

Make a backup of your amavisd.conf file. Then try this. Make your changes to amavisd.conf using a standard Unix text editor (vi, pico, whatever you use). Save your work.

You can use Server Admin to stop and start your mail server if you wish. There is nothing wrong with that. Alternatively, you can issue the following in Terminal:

sudo serveradmin stop mail

Wait for the message: mail:state = "STOPPED"

sudo serveradmin start mail

Wait for the message: mail:state = "RUNNING"

Now check your amavisd.conf file. It should not have changed.

Dec 27, 2006 3:02 PM in response to Zatman

Can anyone suggest a workaround? I had thought of repeating the line:
$sa kill_leveldeflt = $sa tag2_leveldeflt
$sa kill_leveldeflt = 7.0


I haven't seen amavisd.conf replaced during a reboot. As Joel suggested, maybe you are saving from ServerAdmin....

as a work-around (wich you shouldn't need), I believe the last entry will be used- a quick test will confirm it. You'll see in the amavisd.log and your mail headers what the actual kill level is, if you see it at 7.0 then you are good.



Jeff

Dec 28, 2006 6:22 AM in response to UptimeJeff

WHat I tried was restoring from a backup amavisd.conf file and re-entered the changes above. I tested the whole thing and nothing changes in the file with a restart. I am not sure what happened earlier, but at least things are working better.

One thing:

With the new settings, I am getting a bit more Spam getting through, and the spam that makes it through has neither 'X-SPAM' in the header or has 'X-SPAM : not detected'. The spam that does get quarantined seems to have the proper SPAM rating. All messages are scanned for viruses.

Is this normal behaviour?

'Undeliverable Mail Return To Sender' spam?

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.