[Esd-l] SECURITY_NOTIFY_RECIPIENT

[Paul Thomas]

John,

I don't know what your plans are for the SECURITY_NOTIFY_RECIPIENT
feature and you have your hands full enough as it is, but this
is what seems to work for my situation, at least to start on for
the moment:

In html-trap.procmail I have changed:

TO=$LOGNAME

:0
* LOGNAME ?? ^root$
{
  # If $LOGNAME is root, we're probably running as a gateway filter:
  # get the "real" to name(s) out of the message headers.
  :0
  * ^To: +\/.*
  {
    TO="$MATCH"
  }
}

to this:

TO=$LOGNAME

:0
* LOGNAME ?? ^(root$|daemon$)
{
  # If $LOGNAME is root, we're probably running as a gateway filter:
  # get the "real" to name(s) out of the message headers.
  :0
  * ^To: +\/.*
  {
    TO="$MATCH"
  }
}

because I'm running as daemon in my configuration. Perhaps something
can be done with daemon_bias to handle various daemons?

Then after that I added:

RECIPIENT="$TO"

So then hop down a few lines to:

    :0
    * SECURITY_NOTIFY_RECIPIENT ?? [^ ]
    {
      LOG="${NL}NOTIFY RECIPIENT${NL}"

      # We could stuff this directly into $DEFAULT but then
      # we'd have to worry about generating Message-ID and Date headers...
      :0 h ci
      | ( \
          echo "To: <$LOGNAME>";\

and change the above line to:

          echo "To: <$TO>";\

I know Cc: needs to be checked and even if To: & Cc: are checked and
combined, only one of the addresses is the actual destination address
if any of them are, and if the recipient is listed in Bcc: welll we
miss it altogether.

In my Sendmail style headers quite often is something like:

for <recipient at here.com>

which reflects the address of the actual recipient delivery is being
accepted for. Maybe a testing of these fields and headers in order of
importance would give some functionality to the SECURITY_NOTIFY_RECIPIENT
feature.

Thanks again for your work!

--Paul T.

--
"So enjoy yourselves, dabble in sound, paint your pictures, turn
on your mind and gently float downstream..." -- George Martin, 
Beatles's Producer