X-Junk-Score: 0 [] X-Cloudmark-Score: 0 [] Return-Path: Received: from mail.virtuelle.no ([91.189.123.91] verified) by mail.stalker.com (CommuniGate Pro SMTP 5.2.7) with ESMTP id 47525245 for CGatePro@mail.stalker.com; Fri, 05 Sep 2008 08:52:04 -0700 Received-SPF: pass receiver=mail.stalker.com; client-ip=91.189.123.91; envelope-from=nicolas.hatier@niversoft.com X-CGP-ClamAV-Result: CLEAN X-VirusScanner: Niversoft's CGPClamav Helper v1.72 (ClamAV engine v0.91.2) Received: from dummy.name; Fri, 05 Sep 2008 17:51:44 +0200 X-CGP-ClamAV-Result: CLEAN X-VirusScanner: Niversoft's CGPClamav Helper v1.8.0 (ClamAV engine v0.94) X-ExtFilter: Niversoft's DomainKeys Helper DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; d=niversoft.com; s=default; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type; b=xu56uBq6+myxMdBKmSkY3Ph7fPpJHBd7eORneKHOkLHXqKHz6KC1USFv/OYaL5Fq84 fyuK9KfLZW997pyKXV43bRC1kJfW5W+4QFdnVyvawiPZtOSYB/gF3sRaji85aI72w+Q9 ogJX5vErAgEh4GaDlaJ4vI8EflH9nFQ+G00cs= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niversoft.com; s=default; l=12005; t=1220629902; x=1221234702; q=dns/txt; h=Message-ID:Date:From:User-Agent:MIME-Version:To: Subject:References:In-Reply-To:Content-Type; bh=Kdxyvsky+Hp4BZs3 6hF2IAx4CdtEikcyPS1zsWF/HQY=; b=trWW+qweU5WIiQTOwMaM/sPoYY/Lnf/G ja9GLmEbs8pVu0WFQEuFnreDggQy+0oxbW/WP1rNq4HtXBqTuXEvbUoTbkSdRFVy l1a+rMBj7GuP4+iHOiQ5BZpKPVGD3PJEu9+etbd49r/OAnOgY+UjAIhjYWVXglwq tpa/DbrIKKc= Received: from dummy.name; Fri, 05 Sep 2008 11:51:42 -0400 Message-ID: <48C1558D.6090500@niversoft.com> Date: Fri, 05 Sep 2008 11:51:41 -0400 From: Nicolas Hatier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16) Gecko/20080708 Thunderbird/2.0.0.16 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: CommuniGate Pro Discussions Subject: Re: hundreds of non-delivery messages References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090407010204070301000007" This is a multi-part message in MIME format. --------------090407010204070301000007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hello The NDR messages are not necessarily formatted in a way to easily=20 extract the returned headers. A large part of NDR messages does not even = contain them, or contains only standard ones. The "false positives"=20 ratio would probably be larger than the current "false negatives" ratio. = Some NDR messages does not even have the NDR type (multipart/report,=20 message/delivery-status, etc), the are just normal messages with error=20 text in the body. A safer approach could be to remember all the outbound messages for,=20 say, a week - remember only the From/To pair and the sent date would=20 probably be enough. When a NDR is received, it could be possible to=20 extract all email addresses present in the NDR body and headers and=20 check if any of the pair is matching the known data. As other solutions, = this requires that all messages _from_ your users are sent _through_=20 your server. If any users goes through his ISP, he may never get any NDR = as your server will flush them. Another, probably better approach, which I don't think is currently=20 within the reach of a CGP external filter, would be to rewrite the=20 return-path of a send message with some data in the "detail" part of the = address, which could be matched when a NDR is received. Again, this=20 requires all messages to be sent through your server but reduces the=20 required message parsing and would cut in the amount of data needing to=20 be kept by the server. But none of these solutions would be able to filter NDR messages that=20 does not have the NDR type, as they would appear as normal messages to=20 the filter. Regards, Nicolas Hatier Todd Clayton wrote: > Hello, > > Sorry to dig up an old thread, but I wanted to get an opinion on=20 > resolving this issue. Would it be possible to add a header to the=20 > message when it is sent from the server? Then if you get a NDR, you=20 > could check to see if that header is in the message and reject it if=20 > it is not included. Then you could distinguish between valid NDRs and = > SPAM ones. If this is possible, any suggestions on how to build the=20 > rules for this? > > Thanks very much, > Todd > > >> *From: *"Urs Gruetzner" >= >> *Date: *April 21, 2008 6:07:22 AM EDT >> *Subject: **hundreds of non-delivery messages* >> >> >> One of our accounts (mabellanATems.ch) gets in the last days hundreds = of >> mails whih claim to be answers to undeliverable mails >> >> >> like the example below. >> >> >> I guess these non-delivery messages are faked an the attachments may >> contain viruses. Has anyone the same experience? How to stop?=20 >> >> >> Urs --=20 *Nicolas Hatier* /Niversoft id=E9es logicielles/ /http://www.niversoft.com/ --------------090407010204070301000007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello

The NDR messages are not necessarily formatted in a way to easily extract the returned headers. A large part of NDR messages does not even contain them, or contains only standard ones. The "false positives" ratio would probably be larger than the current "false negatives" ratio. Some NDR messages does not even have the NDR type (multipart/report, message/delivery-status, etc), the are just normal messages with error text in the body.

A safer approach could be to remember all the outbound messages for, say, a week - remember only the From/To pair and the sent date would probably be enough. When a NDR is received, it could be possible to extract all email addresses present in the NDR body and headers and check if any of the pair is matching the known data. As other solutions, this requires that all messages _from_ your users are sent _through_ your server. If any users goes through his ISP, he may never get any NDR as your server will flush them.

Another, probably better approach, which I don't think is currently within the reach of a CGP external filter, would be to rewrite the return-path of a send message with some data in the "detail" part of the address, which could be matched when a NDR is received. Again, this requires all messages to be sent through your server but reduces the required message parsing and would cut in the amount of data needing to be kept by the server.

But none of these solutions would be able to filter NDR messages that does not have the NDR type, as they would appear as normal messages to the filter.

Regards,
Nicolas Hatier

Todd Clayton wrote:
Hello,

Sorry to dig up an old thread, but I wanted to get an opinion on resolving this issue.  Would it be possible to add a header to the message when it is sent from the server?  Then if you get a NDR, you could check to see if that header is in the message and reject it if it is not included.  Then you could distinguish between valid NDRs and SPAM ones.  If this is possible, any suggestions on how to build the rules for this?

Thanks very much,
Todd


From: "Urs Gruetzner" <ugruetzner@ems.ch>
Date: April 21, 2008 6:07:22 AM EDT
Subject: hundreds of non-delivery messages


One of our accounts (mabellanATems.ch) gets in the last days hundreds of
mails whih claim to be answers to undeliverable mails


like the example below.


I guess these non-delivery messages are faked an the attachments may
contain viruses. Has anyone the same experience? How to stop? 


Urs

--

Nicolas Hatier
Niversoft idées logicielles
http://www.niversoft.com


--------------090407010204070301000007--