lør, 03.09.2005 kl. 00.39 skrev Sam Varshavchik:
One thing that puzzles me is, why can't we have both (semi-POSIX and
PCRE) at the same time for them as will? Postfix does. Not withstanding,
I'm a PCRE person, so ...
Doing that is probably going to be unnecessarily confusing. There's really
no need for that. Except for the "w" option, PCRE does everything the old
pattern matching engine could do, and much more.
Ok :) As I said, I'm a PCRE man anyway. As you say, it does much more.
If anyone cares, the new maildrop-1.8.1.2005082 PCRE engine works
perfectly ("well, of course it does") and for me, at any rate, gives a
common interface with my Postfix 2.1/2.2 PCRE mumble_checks. Sam and
Philip Hazel da men.
Forcing me to attack a maildroprc that I'd never touched in months
*also* helped me solve a long-standing dspam/maildrop filtering problem
that had cost me many headaches. Sometimes I ask myself whether I'm not
getting more intelligent with my advancing years, sometimes more senile
;)
At some point in the future I need to re-engineer the MIME parser in
librfc2045. When that happens, I can flip PCRE into UTF-8 mode, and be able
to properly match against MIME-encoded header content, and message body
content.
Postfix's 'man pcre_table' mentions nothing about UTF-8/UTF8, so you'd
be ahead of WV there. Though I've never encountered that in practice.
Straight 8-bit non-encoded header and body filtering would be a plus,
though. At the moment I have amavisd-new (pre-queue content filter)
smtp-reject it, though the less that amavisd-new has to do, the better -
it's enormously resource-intensive. It's wonderful the way Postfix (3
smtpd listeners plus amavisd-new and dspam running as an lmtp daemon)
co-operate with maildrop to be able to smtp reject shit.
Thanks again,
--Tonni