rcooper at crstexas.com rcooper at crstexas.com
Mon Apr 16 21:14:19 PDT 2001

Quoting "John D. Hardin" <jhardin at wolfenet.com>:

> On Mon, 16 Apr 2001, rcooper wrote:
> > When enabling SECURITY_NOTIFY_RECIPIENT the recipient does indeed
> > get a message notifying them of the filtered email.  
> > Unfortunately this does not include a transcript of the email
> > headers etc of whom or where the message came from.  Thus the
> > recipient is left confused as to who generated the message.  Is
> > there a way to enable this feature to send more information?

> Well, yes, you could cut-and-paste the headers part from the
> administrator notify into the recipient notify - see the attached
> (totally untested quickie) diff.
> If you wanted only certain headers it would be correspondingly more
> complex.

Thanks, I'll attempt to utualize it.  Indeed things can get horribly complex

> > This feature is nice because the recipient can take corrective
> > measures with the person sending the email that was filtered.  
> > But not if they have no idea who the message came from.  While I
> > understand in a number of cases it may be hard to tell, in some
> > cases Im sure the recipient will recognize who the email came
> > from,

> I didn't think of this because I (as postmaster) tend to handle that
> for my users.

We have enacted a somewhat draconian policy and as a result it is not
unusual for me to get 50-60 security alerts a day.  Those 2500 users
tend to generate a hell of a lot of traffic.  As I explained to Brett,
users love to blame the email system for lost emails, though the reality
is there has yet to be a singe lost mail unless it was filtered to /dev/null as
per our poisoned list (pretty much reject *.*  We only allow a very narrow
amount of email with attachments).  This is why SECURITY_NOTIFY_RECIPIENT
looks to be an attractive option.  I'd rather be rubbing my nose in some perl
code than trackig down emails for end users.  I'm too lazy to want to answer
their questions :)

> > So my question I guess is are there any plans for now or in the
> > future to enhance this feature.  In theory its a useful function
> > provided we can get more information from it to satisfy the end
> > users curiosity.
> Yes, 2.0 will have much better end-user reporting capabilities.

I look forward to using 2.2 :)  Seriously it sounds as if 2.0 will be
a major update, though the current version is very nice as it is.
Thanks for answering my questions and listening to my suggestions.


More information about the esd-l mailing list