Re: SA-Exim and User Preferences

[Danny Sauer <cloudmaster@cloudmaster.com>]

Benjamin Story wrote:
> On Tue, Jul 08, 2003 at 10:43:16AM -0400, Danny Sauer wrote:
> 
>>Benjamin Story wrote:
>>[...]
>>
>>>The problem is that the networking manager wants the SMTP rejection
>>>routines and the MIS VP wants total user custom control through the SA
>>>user_prefs.  Unfortunately these seem to be mutually exclusive goals
>>>since sa-exim doesn't honor user_prefs the way it is currently coded.
>>>What I'm looking for is a way to get the local_scan sa-exim to run
>>>spamc with the -u flag and put the to: address as the user.
>>>
>>>Any ideas short or rewriting sa-exim?
>>
>>Point out to the networking manager that the whole message has to be 
>>delivered for SA to process it anyway, so there's no bandwidth benefit 
>>to using the SMTP rejection.  Honestly, I'm not sure that there's *any* 
>>benefit, aside from checking the sender against some blacklists and 
>>checking the FROM/TO for validity.  After the DATA's sent, the client's 
>>gonna send the headers and the rest of the message before it pays any 
>>attention to any server responses.
> 
> 
> Well one advantage is that spammers get a mailer-daemon error which
> most of them use to drop addressess from their list.  Granted this
> isn't a show stopper I guess.

I'd guess that a majority ignore any server-response after they've sent 
the DATA, since that's just wasted time that could be used sending more 
spam.  The spammers using open relays are usually using a fake source 
address, so the reject message isn't gonna get propogated back to them, 
either.

>>If the goal is to nofiy the sender that their message was marked as 
>>spam, then why don't you just use the router/spamc solution to get 
>>per-user configs, use procmail for local delivery, and set up a 
>>responder in the /etc/procmailrc that'll send a response if the 
>>X-Spam-Status header is Yes?
> 
> 
> We are doing the X-Spam-Status header, but as this is a gateway to
> "defend" an exchange server procmail will have to be outlook rules
> (yuck). ;-)

I suppose that does make things a little more ugly.

Either way, per-user prefs could not be loaded until after any address 
expansion occurs.  So, mail sent to aliases or other not-easy addresses 
will have to go through the whole expansion process before user prefs 
could be loaded.  And what happens when a message is sent to an alias 
that delivers to multiple users, or a message is just sent to multiple 
users who have differing prefs?  I'm not sure how good of an idea it is 
to do all of that before closing the connection to the client...

--Danny


-
To unsubscribe, send email to majordomo@luci.org with
"unsubscribe luci-discuss" in the body.