In checking the logs it appears that Securence does not maintain an ID unique to each user. It changes often, so I guess the only option left is for the subscribers to complain loud and long to their ISPs or to pick up a Gmail account. This is particularly frustrating for these users because of their deaf-blindness. Thanks for all the assistance.

Regards,
Randy Klumph
The National Consortium on Deaf-Blindness
The Teaching Research Institute
Western Oregon University
[log in to unmask]


----- Original Message -----
From: Jacob Haller <[log in to unmask]>
Date: Friday, February 27, 2009 12:27 pm
Subject: Re: [LSTSRV-L] Securence antispam service
To: [log in to unmask]


> >On Feb 26, 2009 at 18:18 -0500, Nathan Brindle wrote:
> >=>At 02:35 PM 2/26/2009 -0800, Randy Klumph wrote:
> >=>>Resent-from: [log in to unmask]
> >=>
> >=>That's what's causing the problem.
> >
> >Don't shoot the messenger....(I don't want to start a SPF discussion
> >war.)
> >
> >This looks a whole lot to me like they are doing Sender Rewriting Scheme
> >(SRS).  See < and
> ><.
>
> They definitely are doing that with the return path:
>
> >Return-path: <[log in to unmask]>
>
> Neither of the links you mention the 'Resent-From:' header (because
> they both deal with SPF which doesn't care about such headers), but I
>
> think I see what they're doing there: it's a similar attempt to deal
> with Sender ID.  <
>
> Anyway, if the munged address
> ([log in to unmask] in this case) is
> always the same for the same user then I agree that the best (though
> annoying) way to deal with this problem is to add the munged address
> to the mailing list and set it to NOMAIL.  This should only be
> necessary for users who use a message forwarding service like
> securence, fortunately.  (It is particularly annoying that the
> addresses contain characters like '/', but such addresses are legal,
> so what are you going to do?)
>
> I don't see a good other way around this from either LISTSERV or
> securence's perspective, unfortunately, at least if securence wants
> to continue to be Sender ID-friendly.  In order for messages sent via
>
> securence to not fail the Sender ID tests the return address of the
> message has to be from a domain that securence controls, generally;
> and if securence does that then LISTSERV is going to interpret that
> return address as the source of the message, since that's what the
> return address is for.
>
> Anyway, that's my analysis, for what it's worth.
> --
> Jacob Haller, Technical Support, L-Soft international, Inc
>    LISTSERV (R) is a registered trademark of L-Soft.
>     Support is available 9:00-18:00 ET, Monday-Friday
>      except on the following holidays:
>       <
>
> Knowledge is just a click away:    <