Here are the full headers
Received: from hotmail.com [65.54.185.14] by mail.zcom.it with ESMTP
(SMTPD32-8.15) id A6892E300A8; Mon, 28 Mar 2005 21:10:01 +0200
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
Mon, 28 Mar 2005 11:09:16 -0800
Message-ID: <[EMAIL PROTECTED]>
Received: from 82.48.60.139 by by15fd.bay15.hotmail.msn.com with HTTP;
Mon, 28 Mar 2005 19:09:16 GMT
From: <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
So the delivery-chain was Italian DSL => US Hotmail Server => MS
demonstration that their SMTPSVC is working well ;-) => my own SMTP Server
in Italy
I've already had such problems with the country/ies test and asked Scott for
an explanation. I believe it was in a period while Scott has had way too
much work.
What I want to do:
I consider it not a good idea to assign weights to every mail comming from a
certain country. But I discovered that it's a very good thing to combine the
origin (or pass trough) of certain messages with different other content-,
rule- or BL-based tests and so for example add extra points if the message
is comming from country X and is also failing other tests. This way I can
assign bigger weights to blacklisted DUL-IP's all over the world while
bypassing this for messages comming from Italy, Austria, Germany and
Switzerland as it would generate many FP's for legit messages. (This could
be used also the other way with "COUNTRIES END CONTAINS xx" to list only
"trusted" instead of hundreds of "untrusted" countries)
All I have to know is exactly how this part of declude JM is working. As
already said it's not so easy as other tests to simply try it out.
Unfortunately I haven't MTA's placed all over the world. So please can
someone who is working on this code try to explain what and how it's doing
exactly.
Thanks in advance
Markus
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Matt
> Sent: Tuesday, March 29, 2005 11:04 PM
> To: Declude.JunkMail@declude.com
> Subject: Re: [Declude.JunkMail] Country-Chain filtering
>
> Andrew,
>
> You are thinking of the ROUTING test. That test shouldn't be
> used at all with servers located outside of the US.
>
> Let me try to explain the issue that Markus is seeing here.
> The COUNTRIES variable is something that is generated from
> the use of the all_list.dat file. This generates the
> variable COUNTRY and COUNTRIES.
> These variables contain lists of countries by their two
> letter code, with COUNTRY being the connecting server and
> COUNTRIES being the full list separated by spaces I believe.
>
> The %COUNTRYCHAIN% variable that is being used in the headers
> however is not exactly the same, and I have a feeling that it
> might be generated by data that is different from that
> contained in the all_list.dat, and if so, that would explain
> the issue. One could easily verify this by removing the
> all_list.dat and checking to see if the %COUNTRYCHAIN%
> variable was still populated in the headers. There is also
> the possibility that the header parsing is different for
> COUNTRIES/COUNTRY and %COUNTRYCHAIN%, so in this case
> COUNTRIES might be picking up a hop that %COUNTRYCHAIN%
> isn't. There is also of course a possibility of a bug or
> maybe an ordering issue. The STARTSWITH filter came along
> way after COUNTRIES was introduced, and Scott might not have
> bothered to order them properly since they couldn't be
> filtered with anything but CONTAINS at that time. It would
> be nice for someone from Declude to confirm the order and
> format of the COUNTRIES variable. ENDSWITH might well be the
> proper way to filter this for the first country in the chain.
>
> Unfortunately the only place that any of these things is
> documented is in the release notes. None of it appears in
> the manual, so I'm not even sure if %COUNTRYCHAIN% uses
> all_list.dat or not.
>
> Markus, if you were to share the full headers of this
> message, that would also help determine the source of the issue.
>
> Another note...since many zombie spammers forge headers prior
> to the connecting received header, it isn't always useful to
> know which country was first, but I don't assume to know
> exactly what you are doing with your filter so it may in fact
> be useful. The data also isn't always complete or accurate,
> and due to the way that IP space is used, it could never be
> perfectly accurate.
>
> Matt
>
>
>
>
> Colbeck, Andrew wrote:
>
> >Markus, my foggy memory tells me that Country-Chain was
> designed to be
> >US-centric, and is designed to trigger on suspicious routing
> for, say,
> >"US -> Brazil -> US".
> >
> >It wasn't designed to figure out the destination country and work
> >backwards, nor was it designed to merely count the number of
> countries
> >in the chain.
> >
> >If you get a better answer directly from Declude Support,
> please give us
> >some feedback here.
> >
> >Andrew 8)
> >
> >
> >-----Original Message-----
> >From: [EMAIL PROTECTED]
> >[mailto:[EMAIL PROTECTED] On Behalf Of
> Markus Gufler
> >Sent: Tuesday, March 29, 2005 3:20 AM
> >To: Declude.JunkMail@declude.com
> >Subject: [Declude.JunkMail] Country-Chain filtering
> >
> >
> >
> >X-Spam-Tests-Failed: DSBL, NJABLPROXIES, FIVETEN-SRC,
> COMBO-COUNTRY-US
> >X-Country-Chain: ITALY->UNITED STATES->destination
> >
> >
> >The testfile for COMBO-COUNTRY-US contains only one single line:
> >COUNTRIES 0 STARTSWITH us
> >
> >Now the question is, how can this Country-Chain fail this test?
> >
> >We've in use v1.82 with Imail.
> >Would it be possible to bether explain the country chain as it's not
> >easy to send arround different test messages having all possible
> >combinations of country chains? Whats the first entry, whats
> the last?
> >What's the internal country chain, as we have to filter for
> us, it, fr,
> >... And not "UNITED STATES", "ITALY" or "FRANCE". Has this internal a
> >different order (inversed)?
> >
> >Markus
> >
> >---
> >This E-mail came from the Declude.JunkMail mailing list. To
> >unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type
> >"unsubscribe Declude.JunkMail". The archives can be found at
> >http://www.mail-archive.com.
> >---
> >This E-mail came from the Declude.JunkMail mailing list. To
> >unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
> >type "unsubscribe Declude.JunkMail". The archives can be found
> >at http://www.mail-archive.com.
> >
> >
> >
> >
>
> --
> =====================================================
> MailPure custom filters for Declude JunkMail Pro.
> http://www.mailpure.com/software/
> =====================================================
>
> ---
> This E-mail came from the Declude.JunkMail mailing list. To
> unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
> type "unsubscribe Declude.JunkMail". The archives can be found
> at http://www.mail-archive.com.
>
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
