Developers of Sympa

[address@concealed]

Patrick von der Hagen wrote:

> address@concealed schrieb:
> [...]
>  
>
> > Current scenario can return "doit", "editor","request_auth" and "reject"
> > , only reject is concerned. In addition the scenario can return
> > "reject,quiet". In such case, no notification is sent to the original
> > sender (may be something very near what you are looking for). What do
> > you suggest the Sympa milter server could do with "reject" and
> > "reject,quiet" ?
> >    
> There are three result-codes which can reasonably be returned to the
> MTA. "sympa-reject" could be mapped to SMFI_REJECT, "sympa-reject,quit"
> would map to SMFIS_DISCARD and all other results would be mapped to
> SMFIS_ACCEPT.
>
> Of course sympa-reject,quiet might be mapped to SMIFS_ACCEPT, the
> message would then be processed again by sympa and discarded by sympa.
> However, if the MTA can discard it, there is no reason for this
> additional burden to sympa.
>  
Ok.

> Personally, if I knew that "reject" would usually result in a rejected
> message instead of a bounce, I'd see hardly any reason to do
> "reject,quiet" at all. Personally, I'd give a reject anyway, which
> wouldn't bother a spammer, but inform a valid sender. It might be
> reasonalbe to have a configuration-option to decide wheter
> "reject,quiet" should result in SMFIS_DISCARD or SMFIS_REJECT.
>  
I don't think so. Too much complexity In some case developpers have to 
do the choice not leaving obscur option to the user.  In practice, 
"reject,quiet" result mainly from editor decision not from automatic 
scenario handling so discard seems the good mapping and should be hard 
coded.

Serge