Bill,
thanks for the points, I've got them
I need to look a little around as I'm rather new and I'm not sure how to do the things but at least I know where to start looking for
Thanks
Flaviano
> Hi Bill
>
> first of all I hope to do the right thing answering this email from my email client, it's first time I use the list.
>
> all messages come from outside, from port 25 or 587 but only from authorized senders that must authenticate themself to send.
>
> Having looked around a little on the list there's a lot I should / would like to do,
> but at present I do not need to refuse messages, I just need to split complex messages (in terms of to/bc/bcc) into single messages
>
> this to allow the firewall filter to catch all messages sent (at present if only catch the "to") so to warn us every X messages sent
>
> max_rcpt seems the right way to go to me.
>
> Thanks
> Flaviano
>
Flaviano,
FWIW, and this is 'non standard' as Hell:
- I allow just TWO simultaneous connections per connecting IP. One for
traffic, one for callouts, if there happen to be any.
- I allow just ONE recipient per message. 100 recipients in one
domain.tld we just do not have, anyway. Not even 15% of that at peak,
and even fewer now that I've 'retired' (yet, again!).
But .. that lets me apply per-recipient processing all the way through
the DATA phase, which is OTHERWISE limited to apply any actions to the
whole 'group' of all recipients for that message. Since there is now
never more than ONE, that smtp flaw is no longer an issue.
NB: Sam Varshavchick fixed this in Courier-MTA ten+ years ago with
EXDATA - allowing per-recipient rejection in the DATA phase. But it only
helps when both players are Courier-MTA AND the feature is switched-on.
Tony Finch once suggested adopting a similar method in Exim, but it did
not happen.
No one else ever picked up that ball - but it IS a part of the LMTP spec.
Left with no other option for now, my method is at least 'universal'.
Downside? IF/AS/WHEN there really are, for example five recipients for a
given message, then sending end must initiate five separate and
successive connections to complete delivery. That can take anywhere from
mere seconds per each go to five minutes per go, depending on far-end's
retry rules.
Not really a problem, that - not for many years now.
And it certainly makes implementing fine-grain control easier.
ALSO - I use a flat-file containing regular expressions, one per line.
Nearly a dozen DIFFERENT acl's at MNAY phases of the smtp session each
look for full or partial or wildcard matches in that SAME file. One may
look for a hostname, another for an envelope, or any of several headers.
Dumping all those disparate fragments into the SAME file makes it really
fast and easy to grep if/as/when someone whinges about their friend
being blocked.
A similar file is used in a slightly different manner.
Ex:
# DATA_9: Check for forbidden strings in Subject: IF found THEN DENY
#
deny
condition = ${lookup{$h_Subject:}nwildlsearch{/var/filters/badsub}}
And yet another for known-abusive commercial spam engines:
# DATA_SCAN_01A1: IF message is from known spam-engine THEN deny
#
deny
regex = ^Received:: .*PowerMTA
# DATA_SCAN_01A2: IF message is from known spam-engine THEN deny
#
deny
regex = ^Received:: .*InterMail
Result?
We haven't had to use SpamAssassin in going on two years now, saving
machine resources BIGTIME - yet get less spam than ever.
Ciao,
Bill
--
韓家標
