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 mechanism in use at another provider, when that mechanism is rare? I would prefer that SPF just disappeared. You will probably spend less time telling your client that their destination server has issues that you can't fix and that they should take it up with them. It is not your, my, nor anyone else's responsibility to implement SRS in the current framework. SRS isn't a an RFC standard, in fact according to that page that you provided, it seems that they are moving towards the "SUBMITTER" parameter. Maybe people should have thought about these issues before rushing to support SPF in the first place? SPF, in it's current form, will die. Just give it time. The more support that you give for it, the more resistance to change will exist.and the longer it will take for it to die. The implementation of SPF was always severely flawed, and two years later, there has been hardly any progress at fixing those issues, and there are now several competing sender validation mechanisms, all of which are flawed in one way or another. The technology is all ridiculously short-sighted. It's a problem and not a solution. Matt Nick Hayer wrote: 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 am aware of your feelings about SPF - all I'm doing is working out a solution with what is in place - an MTA bouncing my legit email. |
- RE: [Declude.JunkMail] spf breaks email forwarding - John T \(Lists\)
- Re: [Declude.JunkMail] spf breaks email forwarding - Matt
- RE: [Declude.JunkMail] spf breaks email forwardi... george kulman
- Re[2]: [Declude.JunkMail] spf breaks email forwardin... Sanford Whiteman
- Re: Re[2]: [Declude.JunkMail] spf breaks email f... Dean Lawrence
- Re[2]: [Declude.JunkMail] spf breaks email forwa... Tyran Ormond
- Re[3]: [Declude.JunkMail] spf breaks email f... Sanford Whiteman
- Re[3]: [Declude.JunkMail] spf breaks ema... Tyran Ormond
- Re[4]: [Declude.JunkMail] spf break... Sanford Whiteman
- RE: [Declude.JunkMail] spf breaks email forwarding - Colbeck, Andrew
- Re[2]: [Declude.JunkMail] spf breaks email forwa... Sanford Whiteman