[Declude.JunkMail] spf breaks email forwarding -

Email customers that forward through me are getting their email bounced because of the original sending domain's spf policy. I understand this delima is addressed with Sender Rewriting Scheme http://www.openspf.org/srs.html Does anyone have a solution to this w/Declude Imail? Thanks

RE: [Declude.JunkMail] spf breaks email forwarding -

I think the underlying problem as has been discussed on this list is that an SPF FAIL should not be relied upon as an outright rejection, rather used as part of a weighting system. John T eServices For You Seek, and ye shall find! -Original Message- From: [EMAIL PROTECTED]

Re: [Declude.JunkMail] spf breaks email forwarding -

I'm not aware of any mail server that supports the Sender Rewriting Scheme. It's certainly a fine idea, but the real issue is that the SPF implementation has issues with forwarded E-mail, and they are seeking to have mail servers correct their shortcoming. It may be a very long-time in

Re: [Declude.JunkMail] spf breaks email forwarding -

The problem is not anything I am doing - it with SPF itself. By design forwarded email will bounce if the receiving MTA is configed that way. Even if I whitelist the emails they will bounce... Let me explain - user@Adelphia.net send an email to user@greenmountainhealth.com which is an alias

Re: [Declude.JunkMail] spf breaks email forwarding -

Real-world issues include working around bad implementation, such as surfglobal.net not configuring their server to reject messages that fail SPF. SPF has many real-world issues. SRS is novel, but it is impractical since no one supports it (that I am aware of), and it certainly won't be

RE: [Declude.JunkMail] spf breaks email forwarding -

Nick, What I've done, and I can't be sure its working, is to set up my client's SPF records like this: v=spf1 ip4:[my ip mx range] ip4:[client ip mx range] mx ~all The range format is nnn.nnn.nnn.nnn/nn I haven't had complaints about SPF rejects. George -Original Message- From:

RE: [Declude.JunkMail] spf breaks email forwarding -

Nick, Sorry about my last email. I thought you were referring to outbound forwarding, not inbound. George -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Nick Hayer Sent: Saturday, March 04, 2006 3:27 PM To:

[Declude.JunkMail] DELETE_RECIPIENT ?

Hi; I can't find anything on how to write the filter for: DELETE_RECIPIENTin the manual. Is DELETE_RECIPIENT designed for filters? what is the syntax? DELETE_RECIPIENT [EMAIL PROTECTED] I have written a filter to remove a certain email from the list if the email is originating from a

Re: [Declude.JunkMail] spf breaks email forwarding -

Matt wrote: Real-world issues include working around bad implementation, such as surfglobal.net not configuring their server to reject messages that fail SPF. SRS is a work around - and I'm simply asking if anyone has implemented it on an Imail/Declude platform. Kindly stay on topic I

RE: [Declude.JunkMail] spf breaks email forwarding -

I was not referring to anything you are doing, I was referring to the recipient domain doing a rejection based upon a SPF fail. John T eServices For You Seek, and ye shall find! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick

RE: [Declude.JunkMail] DELETE_RECIPIENT ?

DELETE_RECIPIENT is a ACTION. John T eServices For You Seek, and ye shall find! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kami Razvan Sent: Saturday, March 04, 2006 1:03 PM To: Declude.JunkMail@declude.com Subject:

Re: [Declude.JunkMail] spf breaks email forwarding -

Someone could write a plug-in or Declude could be modified to handle this, or IMail could be modified to handle this (and then Declude would probably need to be updated to handle what IMail changed). Why implement a work around in a standards compliant platform in order to deal with a flawed

RE: [Declude.JunkMail] DELETE_RECIPIENT ?

Thanks John.. Hard to figure that out from the manual. so in the default file I should have: test_name delete_recipient [EMAIL PROTECTED] Is that correct? Regards, - Kami From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John T (Lists)Sent: Saturday, March 04, 2006 4:26

RE: [Declude.JunkMail] spf breaks email forwarding -

Hear hear. -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Matt Sent: Saturday, March 04, 2006 4:36 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] spf breaks email forwarding - Someone could write a plug-in

RE: [Declude.JunkMail] DELETE_RECIPIENT ?

I believe you just use DELETE_RECEIPIENT, although admittedly now that you question in it need to do more testing. Hopefully Declude will say for sure Monday morning. John T eServices For You Seek, and ye shall find! -Original Message- From: [EMAIL PROTECTED]

Re: [Declude.JunkMail] DELETE_RECIPIENT ?

Kami, It would be like so: TESTNAME DELETE_RECIPIENT This is used just like the DELETE action but with a BIG caveat. This only applies after the ROUTETO action handles the message, and you can't let the weights for a ROUTETO test and DELETE_RECIPIENT overlap. They initially changed the