On exim-users Philip Hazel wrote:
>On 1 Feb 2000, Lorens Kockum wrote:
>>
>> 3) per-domain, per-user, and per-alias incoming mail filtering on
>> message DATA, which would reject after the <CRLF>.<CRLF>
>
>Exim cannot do that. All it can do is check the syntax of header lines
>that contain addresses, and ensure that there is a valid sender in one
>of them.
So it does do some filtering, then? Hmmm ... I just might
care enough about this to hack something in there myself. But
the problem is of course that I am complicating a process that
should be very simple :-(
>It is certainly the case that some MTAs treat any error after CRLF.CRLF
>as a temporary error. See various comments in the Exim manual.
I was impressed by the exim hint databases. I was thinking
along the lines of remembering that if a mail was refused in
this way, an identical IP/HELO/FROM/RCPT combination cound be
rejected if it came back less than one hour afterwards. I
am not comfortable with that though, too convoluted even for
me, and prone to errors if the sender does treat the error as
permanent, and the originator sends a new message ... Since I
do want to refuse during the SMTP session while filtering on
content, I'd say to hell with it, if the sender wants to make
it temporary, it can send again for a week, I don't care. My
bottleneck to the Internet is my 10 Mbps Ethernet card, and I
should only filter the headers anyway, for some mail, so CPU is
no problem.
>If you turn verification on, you can in effect "execute code" after
>RCPT. Indeed, you could get a Perl script run via the embedded Perl
Cool.
>Of course, the more you execute, the longer it holds down the
>SMTP connection, which might matter on a busy system.
Yes, naturally. But I'm not tabling on a lot of mail, at least
not mail that I'll filter in this way, and I only intend to run
a very simple filter on the headers.
>However, there is no facility for doing this after DATA.
How difficult would it be to add it in? RFC 821 says data can
only get the permanent errors "exceeded storage allocation" and
"Transaction failed", but I can argue that storage space for
spam is 0 on my system :-)
>> if the RCPT matches a certain regexp B, and the same SMTP
>> session has already made other RCPTs also matching B, the
>> RCPT TO is rejected, and all subsequent RCPTs and the DATA
>> are rejected.
>
>Cannot do. Each recipient is treated independently. (Unless, I suppose,
>you make a director call Perl and get it to create a file per process in
>which it stuffs/reads data. But when do you delete the file? Far too
>expensive and error-prone. I would not like to try it.)
I was again thinking about the hint databases. But I haven't
dug deep enough yet to understand how it works, I'll be doing
that now.
Thank you very much for these and the other suggestions I've
snipped, I'll be trying to implement at least a subset of what I
want in a few days. Unless of course someone knows of a secure
MTA I've never considered that can do all I want, and whose
inventor will permit people other than himself to try it out ...
the guy I'm referring to will recognize himself if he's on this
list ;-)
HAND.
