Thanks Sam. I see the problem .. Hmm..... Well, back to square one then :-)
Faris. > -----Original Message----- > From: spamdyke-users-boun...@spamdyke.org [mailto:spamdyke-users- > boun...@spamdyke.org] On Behalf Of Sam Clippinger > Sent: 16 February 2009 15:50 > To: spamdyke users > Subject: Re: [spamdyke-users] [Slightly OT] Using fetchmail or similar > with spamdyke > > To do this, you just need to find the IP address of the remote server > that sent the message (e.g. from the topmost "Received" header), then > set the TCPREMOTEIP environment variable before starting spamdyke. > Fetchmail has the ability to pass incoming messages through scripts, so > it should be possible. There's no need to strip message headers on > spamdyke's behalf; it doesn't check headers anyway. You may, however, > need to remove headers if you're going to use other filters like > SpamAssassin or ClamAV. > > However, it won't work. Even if you can make a message _appear_ to be > delivered from the remote server, what will happen when spamdyke > rejects > it? Normally the remote server is responsible for retrying or bouncing > the message, but in this setup your script will have to figure out what > to do. If spamdyke generates a permanent rejection code, your script > can simply delete the message but legitimate senders (false positives) > will receive no notification that their message was lost. If it > generates a bounce message instead, it'll create backscatter. If > spamdyke generates a temporary rejection code, will your script store > the message and retry it later? It'll have to be pretty smart to > discard the messages after they've been retried a number of times; I > think you'll end up reimplementing most of a mail server's > functionality. Some filters, especially graylisting, will be > completely > useless because your script will _always_ retry delivery, even if the > original server would not have done so. spamdyke will be unable to > require authentication or enforce relaying rules. > > All in all, I think spamdyke can't help. It depends on running during > the original message delivery so its messages will be sent to the > remote > server. Trying to move it deep inside a mail delivery system defeats > most of its design. > > -- Sam Clippinger > > Faris Raouf wrote: > > Hi all, > > > > I have a few email addresses that are not running on servers that I > control. > > A lot of them are getting high levels of spam sent to them > (coincidentally, > > mostly ones where the FROM and TO are both the same and are my email > > address). > > > > What I want to somehow do is arrange things so that this email is > magically > > piped to one of the servers we have running spamdyke, in a way that > appears > > to spamdyke as though it came directly from the original sender. > > > > I initially thought of using fetchmail for this but that wouldn't > work, > > would it? I need to effectively strip the headers belonging to the > host that > > accepted the email in the first place in order to get anywhere close > to what > > I want, and fetchmail isn't designed for that as far as I can tell. > > > > So, am I stuffed or might there be some other Linux magic available > > somewhere that might help me? > > > > Faris. > > > > > > > > > > > > _______________________________________________ > > spamdyke-users mailing list > > spamdyke-users@spamdyke.org > > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > > > _______________________________________________ > spamdyke-users mailing list > spamdyke-users@spamdyke.org > http://www.spamdyke.org/mailman/listinfo/spamdyke-users _______________________________________________ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
