cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1719
Views
0
Helpful
10
Replies

Howto to filter russian undeliverable-messages?

Pat_ironport
Level 1
Level 1

We got hundreds of such messages this weekend:

Ihre Nachricht hat einige oder alle Empfänger nicht erreicht.

Betreff: Новинка на рынке баз данных
Gesendet am: 06.04.2008 18:56

Folgende Empfänger konnten nicht erreicht werden:

pavel@kolomna.ru am 06.04.2008 20:43
Das E-Mail-Konto ist in der Organisation, an die diese Nachricht gesendet wurde, nicht vorhanden. Überprüfen Sie die E-Mail-Adresse, oder setzen Sie sich direkt mit dem Empfänger in Verbindung, um die richtige E-Mail-Adresse herauszufinden.
- mail.test.kolomna.ru #5.1.1 X-Postfix; unknown user: "pavel@kolomna.ru" -

Is it possible to activate a Content Filter for mails with characters like this:
Новинка на рынке баз данных

How could I create a filter-combination with 'undeliverable-messages' and foreign characters like the above one?

10 Replies 10

Pat,
you should think about using the bounce verification feature on your gateways. I guess you recieve NDR's for emails sent by a spammer with your users's addresses as senderaddress. Bounce verification can detect these false NDR's and delete them.

Jörg

Pat_ironport
Level 1
Level 1

Could you please tell me some practical advantages/disadvantages about "bounce verification"?

We have been encountering this issue recently as well. It started about two weeks ago. Even with bounce verification turned on these still get through. I talked with a support representative and because these bounces are not the RFC standard they will make it through. Any suggestions to help stop this would be much appreciated. We also get them from other places than Russia, but they seem to be one of the primary offenders.

Doc_ironport
Level 1
Level 1

Could you please tell me some practical advantages/disadvantages about "bounce verification"?


The advantage is easy - you'll never get a bounce for a message that didn't actually originate from your network. Only bounces that are for a message that passed through one of your IronPort's on the way out will be allowed back into the network. This means that real bounces still make it, but bounce spam/etc don't.

There are a few disadvantages, which can basically be put into two categories. These may or may not effect you - it just depends on your environment.

The first is that for BV to work, all mail from your domain needs to go out through your IronPorts. For most companies this shouldn't be an issue - you really dont want your staff sending email "from" your company, but originating outside of your network. For an ISP or the like this is different, and much harder to enforce. Outgoing mail that doesn't go through the IronPort's will still work - but if it bounces then the bounce will be blocked as invalid.

The second problem is that although BV is fully RFC compliant in what it does, some remote hosts have issues with how it's implemented. Generally these are very few and far between, and can be handled relatively easily with a whitelist. Unfortunately there's very little IronPort can do for these corner-cases as the problem is isn't on our end - it's on the remote end.

All of this presumes that the message is actually a "bounce" (ie, an NDR). If it's just a normal message that is made to look like a bounce then BV doesn't help - but in that case you should be forwarding the message through to spam@access.ironport.com so that we can write a rule and get it pushed out.

Pat_ironport
Level 1
Level 1

All of this presumes that the message is actually a "bounce" (ie, an NDR).  If it's just a normal message that is made to look like a bounce then BV doesn't help - but in that case you should be forwarding the message through to spam@access.ironport.com so that we can write a rule and get it pushed out.
I already tried to send it to the spam@-address with the help of IronPorts outlook-plugin. :wink: But the plugin couldn't send it, because it was not recognized as a spam-message. I hope this checks are sufficient enough to tell me that such mails are NDR... :oops:

Doc_ironport
Level 1
Level 1

[quote="Pat"]

I already tried to send it to the spam@-address with the help of IronPorts outlook-plugin. :wink:  But the plugin couldn't send it, because it was not recognized as a spam-message. I hope this checks are sufficient enough to tell me that such mails are NDR... :oops:


The plug-in should send it regardless of what it thinks it is - the whole point is that it should be used to send us messages which are not currently being detected as spam (not much point sending us stuff we already know is spam!)

The plug-in actually uses HTTPS to send the message to us, so it's possible that's being blocked somewhere in your environment - might be worth trying to forward it to spam@access.ironport.com - just remember to make sure it's sent as an RFC822 attachment (see http://tinyurl.com/en48a for details on how to do that)

Pat_ironport
Level 1
Level 1

Thank you for the hint. Other messages works fine and will be sent to you and a copy goes to \Deleted Objects\_IPSpam in my Outlook.

Pat_ironport
Level 1
Level 1

We have activated the "Bounce Verification"-Feature.
Now, I have 3 questions:

a) Will the 'Address Tagging Key' be removed from a mail-reply?
(I sent a mail to my private address and wrote a reply. But I can't see the "Address Tagging Key" in the mail-header.

b) Which logfile do I have to check to ensure that this feature is working well?

c) How many times should we change this key? Once a month?

andrea.murari
Level 1
Level 1

a) Will the 'Address Tagging Key' be removed from a mail-reply?
(I sent a mail to my private address and wrote a reply. But I can't see the "Address Tagging Key" in the mail-header.


The "address tagging key" is used in the "MAIL FROM" SMTP command and usually does not appear in your mail client, unless your e-mail lacks the "From" header in the e-mail body; you also might see it as a "Return-path" header, added by the mail server when it got the e-mail from your ESA.

b) Which logfile do I have to check to ensure that this feature is working well?


The logfiles in mail_logs contain the following records, although I was not able to find them in MFC, too.
"invalid bounce, rcpt address rejected by bounce verification"

HTH
Andrea

Pat_ironport
Level 1
Level 1

Thank you Andrea, you are right!
In the meantime I have found the KB answer ID 778 "What logs will show rejected bounces?" which contains:

The IronPort mail logs will show rejected bounces.
The mail log syntax of a rejected bounce will appear as follows:
# # invalid bounce, rejected by bounce verification.

Sorry, I can't quote the #-sign inside the <>-signs

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: