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 <[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
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
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
