On 12/05/14 16:51, Heiko Schlittermann wrote:
>>> (The actual question was: I'd like to tear down the outgoing connection
>>> as soon as I'm faced with a specific (E)SMTP banner. -- Don't ask why.)
>>
>> That's a fairly esoteric need. I wish I was allowed to ask why :)
>
> Lets say there is a farm of load balanced backend hosts behind the same
> IP. Their load balancer maps the traffic round robin to the backends.
> But unfortunenately some of the backend servers are "lame". As soon
> as I see the SMTP banner, I can tell if it's one of the known lame
> servers.
Oh. Yuck.
>
>> I'd be tempted to refuse to have a separate acl option for each
>> possible SMTP command, but to have only one which was passed the
>> command line (now that ACLs can take arguments, it doesn't even
>> need a global).
>
> I'm lost a bit. What command line you're talking about?
The smtp command. "MAIL FROM<foo@bar>" or "RCPT TO:<bill@ben>" etc.
Actually, we could ensure that $smtp_command has it; no need
for an acl argument.
> How could it look like in the configuration?
Presumably an option to be expanded on each "event". If we
can use that global this is simpler.
Still not quire sure how best to label the non-smtp-protocol
events which are also relevant though.
>
>> Perhaps the TCP connect and the TLS verify could also be regarded
>> as events also for such a callback. I'm having a hard time
>> guessing when you'd ever want the TCP connect one though.
>
> Imagine this as a last measure before the doing real connection,
> But, in fact, I do not have a real use case for this currently.
> It's mainly provided for completeness :) - because I think, if we
> start implementing "ACL for outgoing connections" we should do it
> completly.
It's a valid position to take, certainly.
--
Cheers,
Jeremy