Non English Spam

[Erik Norgaard]

Ian Smith wrote:

> Ted's talking about the _first_ Received header, see mine below.  It's
> the only one you _can_ rely on, assuming your mailserver isn't lying to
> you.  Subsequent headers, sure, all can be faked, trust noone .. :)

Filtering on the Received header entries is waste of time: Only the 
first line is reliable, inserted by your own mail server, but in that 
case you can filter on the connect or HELO, which is much better because 
you don't waste bandwidth receiving the entire mail.

I actually had spammers DDOS my connection because I didn't reject the 
large bulk part early enough. I temporarily had to block any connection 
from China and Korea.

>  > Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119])
>  > 	by gaia.nimnet.asn.au (8.8.8/8.8.8R1.4) with ESMTP id WAA18000
>  > 	for <smithi at nimnet.asn.au>; Sun, 15 Oct 2006 22:02:19 +1000 (EST)
>  > 	(envelope-from owner-freebsd-questions at freebsd.org)
> 
> There's the verified IP address of the connecting peer mailserver, that
> IP's reverse resolution from DNS, and the HELO presented.  Any and all
> of which can be analysed, looked up in maps, blacklisted, whitelisted,
> or filtered any way you want, no? 

Maybe I didn't make clear how the filtering in Postfix works? Each 
header line is unwrapped and then filtered independent of the others. 
There is no info as to if that is the first or last Received line.

I can make a rule to reject the mail. And I can make a rule that accept 
a given header line, but the remaining header will still be filtered and 
possibly rejected.

I can't make a header check for Received cause checks for content-type 
to be skipped.

Nor can I make incoming mail from white listed servers skip the header 
checks. The two things are independent: The first applies when 
establishing the connection: HELO, MAIL FROM, RCPT TO etc. The header 
checks are invoked if the initial delivery request was accepted.

Yes, that sucks, but that's how Postfix works.

>  > Second: If you know postfix, you also know that header filtering is 
>  > independent of other checks, even the result of filtering on individual 
>  > header lines are independent.
> 
> Does that mean you can't black/grey/whitelist by connecting mailserver?

No, I'm only referring to the built in header filtering capabilities.

I have postgray too, and I do have freebsd white listed. Postgrey uses 
the MAIL FROM and RCPT TO, so it takes effect even before the DATA command.

>  > So the ideal you mention is not an option until a complete public list 
>  > of authorized mail servers is available and all mail relayed through 
>  > these requires authentication.
> 
> That's the 'solution' the mega players appear to be proposing.  And who
> then authorises whom to run mailservers?  What about, er, us?  Shudder. 

Anarchy is great, but it assumes that everyone are "good". Evidently 
this is not the case - unfortunately.

I'm one of 'us' and honestly, I don't see why it should be OK to set up 
a mail server without any possibility of identifying the owner or 
responsible, nor do I see this as a big problem:

You either relay mail through your provider's mail server (which 
requires you to authenticate) or register your mail server with the 
provider. The provider can then add your info to the whois database and 
open your connection out.

This should be trivial to implement, but currently there is no legal 
requirement or economic benefit for those capable to take action. For 
the latter, the problem is that implementing such controls only benefits 
everyone else.

> As Ted pointed out, various people often post perfectly intelligible
> messages in English in the various FreeBSD lists, reporting non-Roman
> charsets. 

Which was exactly the problem I mentioned to OP - I mean not that 
intelligible messages are posted :), but they are encoded in different 
character sets.

> I could mention one regular poster (and committer) whose
> messages provide no charset information at all :)

Well, his messages would be accepted since there is no character set to 
reject :)

I absolutely would prefer not to reject any mail on the FreeBSD list, 
but the effect would be to accept non-FreeBSD mail that is obviously spam.

If you have a solution at hand that would not open the gates to spam, 
please do share.

> Have you noticed a lot of non-Roman charset spam on the FreeBSD lists?

No, but as mentioned before: Distinguishing non-Roman charset FreeBSD 
mail from non-Roman non-FreeBSD spam is the problem.

> Because it's unnecessary, as well as arbitary, to filter list messages
> by charset alone as an unassociated variable.  Sure, it might be a hint
> in the mix to give some points.  The FreeBSD lists are mostly incredibly
> spam free, but I doubt that much of that filtering is based on charsets.

As mentioned in my original post, the previous and above: The problem is 
that filtering mail by charset while in many cases will reject what can 
positively be identified as spam, in certain cases also rejects 
legitimate mail sent to this list.

I am not the only one who wish to reject unreadable character sets, OP 
was asking exactly that, and I was making the point that this will get 
reject legitimate mail to the list.

Cheers, Erik
-- 
Ph: +34.666334818                      web: http://www.locolomo.org
X.509 Certificate: http://www.locolomo.org/crt/8D03551FFCE04F0C.crt
Key ID: 69:79:B8:2C:E3:8F:E7:BE:5D:C3:C3:B1:74:62:B8:3F:9F:1F:69:B9