I still come back to, how does this solve the subscription confirmation process? That will only work by sending a mail to the person that sent the request initially.
Matt Deatherage said: > On 5/7/07 at 12:14 PM, a.h.s. boy (lists) <[EMAIL PROTECTED]> > wrote: > >> >2) RE: Spam engine. All of those messages will end up in a reply to >> >the person that sent the mail (or that Letterrip thinks sent the >> >mail). You are not redistributing SPAM. Letterrip is rejecting it. >> >This is exactly the same behavior that any other mail server would do. >> >> Well, like it or not, LR _is_ redistributing spam. Spam is coming from >> Machine 1 (spoofed as Machine 2), to LR, and LR is _sending the spam_ >> to Machine 2. That's redistribution. I TOTALLY agree with you that's >> it's doing so for rather legitimate reasons, but the inadvertent side >> effect is that it winds up redistributing spam. > > I'd have to agree, reluctantly - if person A sends spam to LRP that's > spoofed as from person B and contains an invalid command, and if LRP > sends a reply to person B containing the original message, then there's > no way to get around the conclusion "LRP is distributing spam." > > At first I thought the answer to this might be a quick processor - > filter incoming messages for commands, process them, and don't send > errors back to the sender, just eat the message. Unfortunately, I have > no idea if this is true - the sample processors in my LRP installation > are all Classic applications; the most useful-looking of them are saved > as "run-only" so I can't see the AppleScript, and the ones that are > readable contain handlers for events that aren't in the LRP 4.07 > dictionary (like <<BassPreP>> and <<BassInit>>), so I have no idea if I > need to do anything there or not. > > If you have EIMS and anti-spam features (like in EIMS 3.3 or DNS-based > filtering like Denes), you could put LRP behind the spam protection so > that commands from fake IP addresses don't get through, or (presumably) > you could write a processor in C that looks up the MX that should go > with the sending address and eats the message (without error) if it came > from a different SMTP server. Or you could disable the "unsubscribe" > address and put up a Web page with a CGI to do the work instead. > > In other words, I think there are things you can do today to alleviate > the problem. For all I know, there's an STR# or TEXT resource you can > change that will keep LRP from substituting the original message into a > template reply, but I don't know what you'd change to get that effect > (or if it's true, it just seems possible given LRP's design). Some are > more work than others, but I think you can do *something*. > > --Matt > > -- > Matt Deatherage <[EMAIL PROTECTED]> > GCSF, Incorporated <http://www.macjournals.com> > > "I was going to be a neo-deconstructionist, but mom wouldn't let me." > -- Calvin, to Hobbes > > > -- > This message is from the Letterrip-Talk Mailing list. > To unsubscribe, send mail to: [EMAIL PROTECTED] > Archive: http://www.mail-archive.com/letterrip-talk%40lists.letterrip.com/ > > -- This message is from the Letterrip-Talk Mailing list. To unsubscribe, send mail to: [EMAIL PROTECTED] Archive: http://www.mail-archive.com/letterrip-talk%40lists.letterrip.com/
