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 [])
 >   by gaia.nimnet.asn.au (8.8.8/8.8.8R1.4) with ESMTP id WAA18000
 >   for <[EMAIL PROTECTED]>; Sun, 15 Oct 2006 22:02:19 +1000 (EST)
 >   (envelope-from [EMAIL PROTECTED])

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

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
freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to