Non English Spam
norgaard at locolomo.org
Sun Oct 15 12:23:07 PDT 2006
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 [126.96.36.199])
> > 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
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
> As Ted pointed out, various people often post perfectly intelligible
> messages in English in the various FreeBSD lists, reporting non-Roman
Which was exactly the problem I mentioned to OP - I mean not that
intelligible messages are posted :), but they are encoded in different
> 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
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.
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
More information about the freebsd-questions