Re: [Declude.JunkMail] spf breaks email forwarding -
Hi Sandy Sanford Whiteman wrote: Andrew, I like your workaround with the Program Alias. However, I think that instead, if people are willing to wait a few weeks to a month, I can find time to put out a full-fledged external test for Declude that does much the same thing, without having to forge brand-new Q files and so on, honoring IMail-level forwards. Although I am going to give Andrew's tactic a try now I would very much appreciate your external test when it becomes available. Thanks! -Nick --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] spf breaks email forwarding -
Wow thanks for the efforts here Andrew - Nice work! -Nick Colbeck, Andrew wrote: Hey, Nick. I spent some time poking at this with a stick. Since I just use IMail as a gateway so that I can use Declude... I've had no use for IMail mailboxes or forwarding, so it was all new to me. The real answer is that you should lobby Ipswitch to implement that sender re-writing in their forwarding (what the heck... all of SPF plus the bells and whistles while they're at it). If you can garner support from other people to make the same request, all the better. You can also tell your client "Sorry, Adelphia controls how [EMAIL PROTECTED] email is moved around and since the destination you want adheres to Adelphia's wishes, I can't forward it. However, if you do have Adelpha forward the mail to me, I can filter out the spam and viruses, and you can use POP/IMAP to retrieve the good mail from my server." As a new policy, you would want to double-check that any mailbox for which you do forwarding doesn't send mail from some domain that has a tight SPF, or whomever you're fowarding to (e.g. surfglobal.net) will see you as a spammer. If you want to perservere and build your own forwarding system, what I found was that: 1) Just doing a "forward" action on a mailbox was functionally identical to making an IMail mailbox with a rule that says "if sender email contains '@' then forward the mail to [EMAIL PROTECTED]" and that this forwarding violates SPF for a domain like Adelphia.com. 2) It's not easy but it's not impossible to instead use a Program Alias instead. That program alias would call a batch file with optional parameters (let's say we provide two in our configuration). That batch then receives a %3 parameter added on that contains a tmp*.tmp filename which is really a D*.SMD file with a different name in the \imail\spool folder. The first thing the batch would do is some sanity checks. You would have to avoid mail loops and other badness by making sure that this is a message that should be forwarded, e.g. not a bounce message from whomever you're forwarding messages to! If it is crap, it should delete the tmp*.tmp file and exit. The second thing the script would do is manufacture a Q*.SMD file. Since you've already got the D*.SMD file, if you can just manufacture an appropriate Q*.SMD file, you can have IMail re-send the message while passing on the complete headers and without having to do any editing of the D*.SMD file although there probably are useful smarty pants edits (e.g. changing the "From:" line to something like "From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED]" or inserting the frills Received-SPF: header). Here's the format of the Q*.SMD file, as per the venerable R. Scott Perry: http://www.mail-archive.com/imail_forum@list.ipswitch.com/msg64280.html The "S" sender row would normally be [EMAIL PROTECTED] but that violates SPF, so you instead specify [EMAIL PROTECTED] there. The "R" recipient row would then be the 3rd party destination, e.g. [EMAIL PROTECTED] In my testing it seemed that also using the "N" original recipient row to the sender field would preserve the "Reply-To:" as the original sender but that may have been an artifact of bad thinking on my part (you'd best extract the original Declude spoolname from the tmp*.tmp file and use that to extract the MAILFROM for that message from the sys*.txt file! [To get that, you must use the "XSENDER ON" option in your global.cfg file]) The "Q" file row defines the fully qualified name of the tmp*.tmp file and doesn't have to be D*.SMD format; you can just specify the tmp*.tmp file here. The "H" host row is just your normal name for the IMail host. The "I" guid row contains the long id number that IMail will use in the sys*.txt file to identify this message. Ideally this would be unique every time; however for testing you could write out the same row every time. Here's a sample: QC:\IMail\spool\tmp1B.tmp Hmail.madriver.com Ic507787800822fbd WC:\IMail S<[EMAIL PROTECTED]> NRCPT TO:<[EMAIL PROTECTED]> R<[EMAIL PROTECTED]> The third thing the script would do is to have IMail deliver the message. Here's how to re-queue a single Q*.SMD + D*.SMD pair: http://support.ipswitch.com/kb/IM-2623-DM02.htm The short version being that if you make sure that the Q*.SMD file (which can be any filename) contains the "Q" row and a fully qualified D*.SMD file (which can be any filename) you can just call: smtp32.exe Qxxx.SMD and IMail will queue it up immediately. Ta-dah! Easy as world peace. And
RE: Re[2]: [Declude.JunkMail] spf breaks email forwarding -
Thanks, Sandy. I liked this approach for a couple of reasons; off the top of my head: 1) I was sure that Declude locks the Q*.SMD file (if for no other reason than to stop Imail from poaching them) and possibly the D*.SMD file so I thought an external test wouldn't be able to "redirect" them. 2) I wanted to leave the option open to rewrite the D*.SMD file, such as inserting a custom header line. 3) Configuration would be very easy. For example, each time a Program Alias is created in IMail, the first two parameters could be the "destination at my domain" and the "destination at the forwarded domain"; when the script or program is called, it is provided with the hardcoded "from" and "to" addresses and then the name of tmp*.tmp file (which is really a D*.SMD file). 4) The DAISYCHAIN directive has received little attention in the years I've been using Declude with IMail, so it's probably not a good feature to rely on if I spec'ed this to be an external program that would run after Declude and change the queuing behaviour. 5) It makes the assumption that the other Declude filters and antispamming can go ahead as planned; I didn't have to think about the law of unintended consequences. 6) That previous item expands to my trying to write a two part solution where an external filter creates the correct condition, and then a doesn't-scale-well Declude filter test plus action to COPYTO [EMAIL PROTECTED] lines 7) I had already downloaded one of the "official" distributions of source code for SRS and it made my eyes swim; it was pretty clear that SRS tackles a much larger problem than the envelope re-writing I could almost reach this way. Andrew 8) > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Sanford Whiteman > Sent: Tuesday, March 07, 2006 6:37 PM > To: Colbeck, Andrew > Subject: Re[2]: [Declude.JunkMail] spf breaks email forwarding - > > > If you want to perservere and build your own forwarding > system, what I > > found was that. . . > > Andrew, I like your workaround with the Program Alias. > However, I think that instead, if people are willing to > wait a few weeks to a month, I can find time to put out a > full-fledged external test for Declude that does much the > same thing, without having to forge brand-new Q files and > so on, honoring IMail-level forwards. > > --Sandy > > > > Sanford Whiteman, Chief Technologist > Broadleaf Systems, a division of > Cypress Integrated Systems, Inc. > e-mail: [EMAIL PROTECTED] > > SpamAssassin plugs into Declude! > > http://www.imprimia.com/products/software/freeutils/SPAMC32/do > wnload/release/ > > Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes > into IMail Aliases! > > http://www.imprimia.com/products/software/freeutils/exchange2a > liases/download/release/ > > http://www.imprimia.com/products/software/freeutils/ldap2alias > es/download/release/ > > --- > This E-mail came from the Declude.JunkMail mailing list. To > unsubscribe, just send an E-mail to [EMAIL PROTECTED], and > type "unsubscribe Declude.JunkMail". The archives can be > found at http://www.mail-archive.com. > --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re[2]: [Declude.JunkMail] spf breaks email forwarding -
> Back to SRS. SRS isn't just simply changing the Mail From address, > it is a system that requires both the encoding and parsing of the > Mail From addresses, and it requires both the sending and receiving > MTA to be SRS aware. The following is from what is apparently the > master SRS document. . . I'm not going for an SRS implementation, but a simple method of performing server-side envelope sender address rewriting. The implementation is not intended for use by dedicated forwarders, who must by necessity assume the pass-through of both messages and DSNs. Rather, it is intended for mailbox providers to pre-fetch IMail account- and mailbox-level forwards and rewrite accordingly. Things will break: bounces of forwarded mail will not be returned to the original sender, and this breakage is by design. But SPF 1.0 checks will pass, which is the matter under discussion. --Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] spf breaks email forwarding -
orry, Adelphia controls how [EMAIL PROTECTED] email is moved around and since the destination you want adheres to Adelphia's wishes, I can't forward it. However, if you do have Adelpha forward the mail to me, I can filter out the spam and viruses, and you can use POP/IMAP to retrieve the good mail from my server." As a new policy, you would want to double-check that any mailbox for which you do forwarding doesn't send mail from some domain that has a tight SPF, or whomever you're fowarding to (e.g. surfglobal.net) will see you as a spammer. If you want to perservere and build your own forwarding system, what I found was that: 1) Just doing a "forward" action on a mailbox was functionally identical to making an IMail mailbox with a rule that says "if sender email contains '@' then forward the mail to [EMAIL PROTECTED]" and that this forwarding violates SPF for a domain like Adelphia.com. 2) It's not easy but it's not impossible to instead use a Program Alias instead. That program alias would call a batch file with optional parameters (let's say we provide two in our configuration). That batch then receives a %3 parameter added on that contains a tmp*.tmp filename which is really a D*.SMD file with a different name in the \imail\spool folder. The first thing the batch would do is some sanity checks. You would have to avoid mail loops and other badness by making sure that this is a message that should be forwarded, e.g. not a bounce message from whomever you're forwarding messages to! If it is crap, it should delete the tmp*.tmp file and exit. The second thing the script would do is manufacture a Q*.SMD file. Since you've already got the D*.SMD file, if you can just manufacture an appropriate Q*.SMD file, you can have IMail re-send the message while passing on the complete headers and without having to do any editing of the D*.SMD file although there probably are useful smarty pants edits (e.g. changing the "From:" line to something like "From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED]" or inserting the frills Received-SPF: header). Here's the format of the Q*.SMD file, as per the venerable R. Scott Perry: http://www.mail-archive.com/imail_forum@list.ipswitch.com/msg64280.html The "S" sender row would normally be [EMAIL PROTECTED] but that violates SPF, so you instead specify [EMAIL PROTECTED] there. The "R" recipient row would then be the 3rd party destination, e.g. [EMAIL PROTECTED] In my testing it seemed that also using the "N" original recipient row to the sender field would preserve the "Reply-To:" as the original sender but that may have been an artifact of bad thinking on my part (you'd best extract the original Declude spoolname from the tmp*.tmp file and use that to extract the MAILFROM for that message from the sys*.txt file! [To get that, you must use the "XSENDER ON" option in your global.cfg file]) The "Q" file row defines the fully qualified name of the tmp*.tmp file and doesn't have to be D*.SMD format; you can just specify the tmp*.tmp file here. The "H" host row is just your normal name for the IMail host. The "I" guid row contains the long id number that IMail will use in the sys*.txt file to identify this message. Ideally this would be unique every time; however for testing you could write out the same row every time. Here's a sample: QC:\IMail\spool\tmp1B.tmp Hmail.madriver.com Ic507787800822fbd WC:\IMail S<[EMAIL PROTECTED]> NRCPT TO:<[EMAIL PROTECTED]> R<[EMAIL PROTECTED]> The third thing the script would do is to have IMail deliver the message. Here's how to re-queue a single Q*.SMD + D*.SMD pair: http://support.ipswitch.com/kb/IM-2623-DM02.htm The short version being that if you make sure that the Q*.SMD file (which can be any filename) contains the "Q" row and a fully qualified D*.SMD file (which can be any filename) you can just call: smtp32.exe Qxxx.SMD and IMail will queue it up immediately. Ta-dah! Easy as world peace. Andrew 8) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Nick Hayer Sent: Saturday, March 04, 2006 1:13 PM To: Declude.JunkMail@declude.com Subject: 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 am aware of your feelings about SPF - all I'm doing is working out a soluti
Re[2]: [Declude.JunkMail] spf breaks email forwarding -
> If you want to perservere and build your own forwarding system, what > I found was that. . . Andrew, I like your workaround with the Program Alias. However, I think that instead, if people are willing to wait a few weeks to a month, I can find time to put out a full-fledged external test for Declude that does much the same thing, without having to forge brand-new Q files and so on, honoring IMail-level forwards. --Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
RE: [Declude.JunkMail] spf breaks email forwarding -
Hey, Nick. I spent some time poking at this with a stick. Since I just use IMail as a gateway so that I can use Declude... I've had no use for IMail mailboxes or forwarding, so it was all new to me. The real answer is that you should lobby Ipswitch to implement that sender re-writing in their forwarding (what the heck... all of SPF plus the bells and whistles while they're at it). If you can garner support from other people to make the same request, all the better. You can also tell your client "Sorry, Adelphia controls how [EMAIL PROTECTED] email is moved around and since the destination you want adheres to Adelphia's wishes, I can't forward it. However, if you do have Adelpha forward the mail to me, I can filter out the spam and viruses, and you can use POP/IMAP to retrieve the good mail from my server." As a new policy, you would want to double-check that any mailbox for which you do forwarding doesn't send mail from some domain that has a tight SPF, or whomever you're fowarding to (e.g. surfglobal.net) will see you as a spammer. If you want to perservere and build your own forwarding system, what I found was that: 1) Just doing a "forward" action on a mailbox was functionally identical to making an IMail mailbox with a rule that says "if sender email contains '@' then forward the mail to [EMAIL PROTECTED]" and that this forwarding violates SPF for a domain like Adelphia.com. 2) It's not easy but it's not impossible to instead use a Program Alias instead. That program alias would call a batch file with optional parameters (let's say we provide two in our configuration). That batch then receives a %3 parameter added on that contains a tmp*.tmp filename which is really a D*.SMD file with a different name in the \imail\spool folder. The first thing the batch would do is some sanity checks. You would have to avoid mail loops and other badness by making sure that this is a message that should be forwarded, e.g. not a bounce message from whomever you're forwarding messages to! If it is crap, it should delete the tmp*.tmp file and exit. The second thing the script would do is manufacture a Q*.SMD file. Since you've already got the D*.SMD file, if you can just manufacture an appropriate Q*.SMD file, you can have IMail re-send the message while passing on the complete headers and without having to do any editing of the D*.SMD file although there probably are useful smarty pants edits (e.g. changing the "From:" line to something like "From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED]" or inserting the frills Received-SPF: header). Here's the format of the Q*.SMD file, as per the venerable R. Scott Perry: http://www.mail-archive.com/imail_forum@list.ipswitch.com/msg64280.html The "S" sender row would normally be [EMAIL PROTECTED] but that violates SPF, so you instead specify [EMAIL PROTECTED] there. The "R" recipient row would then be the 3rd party destination, e.g. [EMAIL PROTECTED] In my testing it seemed that also using the "N" original recipient row to the sender field would preserve the "Reply-To:" as the original sender but that may have been an artifact of bad thinking on my part (you'd best extract the original Declude spoolname from the tmp*.tmp file and use that to extract the MAILFROM for that message from the sys*.txt file! [To get that, you must use the "XSENDER ON" option in your global.cfg file]) The "Q" file row defines the fully qualified name of the tmp*.tmp file and doesn't have to be D*.SMD format; you can just specify the tmp*.tmp file here. The "H" host row is just your normal name for the IMail host. The "I" guid row contains the long id number that IMail will use in the sys*.txt file to identify this message. Ideally this would be unique every time; however for testing you could write out the same row every time. Here's a sample: QC:\IMail\spool\tmp1B.tmpHmail.madriver.comIc507787800822fbdWC:\IMailS<[EMAIL PROTECTED]>NRCPT TO:<[EMAIL PROTECTED]>R<[EMAIL PROTECTED]> The third thing the script would do is to have IMail deliver the message. Here's how to re-queue a single Q*.SMD + D*.SMD pair: http://support.ipswitch.com/kb/IM-2623-DM02.htm The short version being that if you make sure that the Q*.SMD file (which can be any filename) contains the "Q" row and a fully qualified D*.SMD file (which can be any filename) you can just call: smtp32.exe Qxxx.SMD and IMail will queue it up immediately. Ta-dah! Easy as world peace. Andrew 8) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick HayerSent: Saturday, March 04, 2006 1:13 PMTo: Declude.JunkMail@declude.comSubjec
Re[4]: [Declude.JunkMail] spf breaks email forwarding -
> Please don't assume that you have any idea how my policies are set. I'm not assuming: you've made some of them public. For example, you touted day-of-week and hour tests as effective gauges of spamminess. Note that I don't disagree at all with your conclusions about these tests. I mention such positions to show that they are certainly counter to your prior claim that RFC-compliance alone ensures legitimacy. More important, since it would be impossible to get real effectiveness out of any anti-spam solution without following internal policies that countermand RFC compliance, it is safe to say that _everyone_ who is satisfied with Declude does not treat the RFC compliance of incoming sessions/messages as grounds for whitelisting! You simply wouldn't be here if you took that much stock in RFCs; it doesn't matter that you haven't revealed your whole config. AFAIK, the only people who treat the RFCs with that much respect are the academic anti-spam-is-fascism advocates (at least, those few who are actually sincere and not trolls for the direct matrketing industry). > Good to know, next time I have to make sure that my servers can > communicate properly with the rest of the world, I'll be sure to > check the relevant case law first. After all, I'm sure the courts > will help me do a much better job than by following the RFCs. Don't really see much there to mock, but knock yourself out. US Code protects your right to restrict the use of domains you own in any MAIL FROM. The law therefore protects your ability to publish policies for your domain that are expressly intended to affect how and where non-owners of your domain may use the domain, as long as (and I did mention this caveat before) such protection does not contradict a right expressly granted by a separate contract. There is no generic, assumed right that a non-owner has to the use of a domain. Look, I know you're very put out by SPF. You know you don't have the kind of userbase, and the kind of relationship with your users, that would let you publish a policy. That's just fine. I have clients that can't publish SPF either, so I'm not telling you that you have to find a way to make it work. I'm telling you that it does work for some very significant domains, domains with very large legal departments at that, and there is no legal argument against it. There may be an RFC argument against it -- *if* in every area you treat RFC-compliant senders as trusted senders. But I think due to the nature of this mailing list, there is a justifiable presumption of guilt in that department. --Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re[3]: [Declude.JunkMail] spf breaks email forwarding -
On 11:39 PM 3/6/2006 -0500, it would appear that Sanford Whiteman wrote: > Sure it is, SPF is NOT an RFC and if the email follows RFC then it > is legit. I'm afraid you have a rather exaggerated opinion of the relevance of RFCs, and of the concept of domain ownership. RFCs are meaningless when it comes to the acceptable use of your domain (which is protected by law, not at all by RFC). . . not to mention that the SMTP RFCs are widely disregarded in spamfighting: I'm sure you have several policies which do not respect all RFC MUSTs and SHOULDs. Please don't assume that you have any idea how my policies are set. The courts have affirmed that a domain owner solely controls the use of the domain, even if it is not a distinctly registered trade or service mark (US Code Title 15, Chapter 22, Subchapter III, § 1127). Anyone else is simply using the mark at the will of the owner and is not protected any way by RFC. US Code v. RFC = no contest! Good to know, next time I have to make sure that my servers can communicate properly with the rest of the world, I'll be sure to check the relevant case law first. After all, I'm sure the courts will help me do a much better job than by following the RFCs. Tyran Ormond Programmer/LAN Administrator Central Valley Water Reclamation Facility [EMAIL PROTECTED] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re[3]: [Declude.JunkMail] spf breaks email forwarding -
> Sure it is, SPF is NOT an RFC and if the email follows RFC then it > is legit. I'm afraid you have a rather exaggerated opinion of the relevance of RFCs, and of the concept of domain ownership. RFCs are meaningless when it comes to the acceptable use of your domain (which is protected by law, not at all by RFC). . . not to mention that the SMTP RFCs are widely disregarded in spamfighting: I'm sure you have several policies which do not respect all RFC MUSTs and SHOULDs. The courts have affirmed that a domain owner solely controls the use of the domain, even if it is not a distinctly registered trade or service mark (US Code Title 15, Chapter 22, Subchapter III, § 1127). Anyone else is simply using the mark at the will of the owner and is not protected any way by RFC. US Code v. RFC = no contest! > If your users are employees, then you are correct. If your users > are customers, then you are wrong. Paying customers have a right to > expect services to conform to accepted RFCs. Use of a domain is dictated by the domain owner, not by people who are customers, employees, or in any other way using the domain with the consent of the owner. True, _if_ an ISP's EULA should warrant that no measures will be taken to block the use of the domain name by the non-owners, then of course it would be an illegal trade practice to then make actionable moves toward such restrictions (such as publishing an SPF policy) without revising and publicizing a new EULA. But no one would be so stupid as to make such a declaration with any enforceable wording -- I've never seen anything close. You're imagining a level of end-user protection which simply is not generally recognized, though it may exist if literalized in a specific contract. --Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re[2]: [Declude.JunkMail] spf breaks email forwarding -
On 08:54 PM 3/5/2006 -0500, it would appear that Sanford Whiteman wrote: > Perfectly legit email - my spf recs are perfect etc. No, it's *not* legit! Sure it is, SPF is NOT an RFC and if the email follows RFC then it is legit. My users don't have the right to have this restriction completely ignored, though they may rightly dispute the resultant rejections. If your users are employees, then you are correct. If your users are customers, then you are wrong. Paying customers have a right to expect services to conform to accepted RFCs. SPF breaks multiple RFCs (974 and 2821 come immediately to mind). Tyran Ormond Programmer/LAN Administrator Central Valley Water Reclamation Facility [EMAIL PROTECTED] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: Re[2]: [Declude.JunkMail] spf breaks email forwarding -
Couldn't you get around this whole issue by just adding the forwarding server to the SPF record? Dean On 3/5/06, Sanford Whiteman <[EMAIL PROTECTED]> wrote: > Perfectly legit email - my spf recs are perfect etc.No, it's *not* legit! Domain owners set SPF policies that dictate legitimacy. This is their right. SMTP server owners respect SPFpolicies. This is my obligation. If Adelphia sets a strict SPF policy,and SurfGlobal respects it, so what? Don't assume that just because a user thinks their mail should go through, that the mail looks"uncontroversial," that the user is right.If a domain owner sets a policy that says, "Mail with an envelopesender of @ example.com must only come from these servers," sure, maybethat policy will prove unworkable later on. Maybe they didn't thinkenough about server-level redirection (unlikely, since Adelphia isn't exactly a tiny company). Maybe they'll change their policies onceusers start getting their mail rejected (possible, with sufficientoutcry). But this all isn't your problem. If you're originating mail that fails the domain owner's policy, what's the big surprise that itgets bounced? I sure as heck would hope that it got bounced, if I werethe domain owner! My users don't have the right to have this restriction completely ignored, though they may rightly dispute theresultant rejections.Your MTA breaks the policy with its built-in forwarding function, soif you don't want to change your forwarding functionality, put together a nice helpfile on your forwarding page (just like the kindof thing you may have put together to inform people that they can'tforward to AOL) that warns them that the forwarded messages may be bounced back to the senders if the senders have restrictive policies.It shouldn't be difficult to articulate in userspeak: "If some of yourfriends or associates' ISPs allow them to send mail only _directly_ to other addresses, you won't be able to 'relay' or 'zig-zag' that mailthrough your Mad River Access account to the final destination.Restrictions like this are placed by your friend's ISP or employer, not by MRA! We'd be very happy to forward the mail, but your friendsaren't allowed to use this service."Recommend that they keep a copy on your server as a fallback againstsuch situations (aging these out, of course, if it's otherwise a global forward). *Let* the SPF failures keep getting bounced back tothe senders. That's the only way anyone is going to be made aware ofthe possible "problem" with their SPF policy.But if you do want to change your forwarding policy, it wouldn't be as difficult as implementing SRS or any of that. You could write a veryeasy script to change the envelope sender to the local user. It wouldact like a client-side FW: in that respect. The bounces may stay on your server, which isn't "full service." But it gets the job done.Well-documented, this would be a perfectly reasonable option forusers.I have never, not once, ever, had any issues rejecting on SPF. I catch thousands of messages a day. There are no false positives. Therecannot be, unless your SPF library has bugs.--SandySanford Whiteman, Chief Technologist Broadleaf Systems, a division ofCypress Integrated Systems, Inc.e-mail: [EMAIL PROTECTED]SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ ---This E-mail came from the Declude.JunkMail mailing list. Tounsubscribe, just send an E-mail to [EMAIL PROTECTED], andtype "unsubscribe Declude.JunkMail ". The archives can be foundat http://www.mail-archive.com.-- __Dean Lawrence, CIO/Partner Internet Data Technology888.GET.IDT1 ext. 701 * fax: 888.438.4381http://www.idatatech.com/Corporate Internet Development and Marketing Specialists
Re[2]: [Declude.JunkMail] spf breaks email forwarding -
> Perfectly legit email - my spf recs are perfect etc. No, it's *not* legit! Domain owners set SPF policies that dictate legitimacy. This is their right. SMTP server owners respect SPF policies. This is my obligation. If Adelphia sets a strict SPF policy, and SurfGlobal respects it, so what? Don't assume that just because a user thinks their mail should go through, that the mail looks "uncontroversial," that the user is right. If a domain owner sets a policy that says, "Mail with an envelope sender of @example.com must only come from these servers," sure, maybe that policy will prove unworkable later on. Maybe they didn't think enough about server-level redirection (unlikely, since Adelphia isn't exactly a tiny company). Maybe they'll change their policies once users start getting their mail rejected (possible, with sufficient outcry). But this all isn't your problem. If you're originating mail that fails the domain owner's policy, what's the big surprise that it gets bounced? I sure as heck would hope that it got bounced, if I were the domain owner! My users don't have the right to have this restriction completely ignored, though they may rightly dispute the resultant rejections. Your MTA breaks the policy with its built-in forwarding function, so if you don't want to change your forwarding functionality, put together a nice helpfile on your forwarding page (just like the kind of thing you may have put together to inform people that they can't forward to AOL) that warns them that the forwarded messages may be bounced back to the senders if the senders have restrictive policies. It shouldn't be difficult to articulate in userspeak: "If some of your friends or associates' ISPs allow them to send mail only _directly_ to other addresses, you won't be able to 'relay' or 'zig-zag' that mail through your Mad River Access account to the final destination. Restrictions like this are placed by your friend's ISP or employer, not by MRA! We'd be very happy to forward the mail, but your friends aren't allowed to use this service." Recommend that they keep a copy on your server as a fallback against such situations (aging these out, of course, if it's otherwise a global forward). *Let* the SPF failures keep getting bounced back to the senders. That's the only way anyone is going to be made aware of the possible "problem" with their SPF policy. But if you do want to change your forwarding policy, it wouldn't be as difficult as implementing SRS or any of that. You could write a very easy script to change the envelope sender to the local user. It would act like a client-side FW: in that respect. The bounces may stay on your server, which isn't "full service." But it gets the job done. Well-documented, this would be a perfectly reasonable option for users. I have never, not once, ever, had any issues rejecting on SPF. I catch thousands of messages a day. There are no false positives. There cannot be, unless your SPF library has bugs. --Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
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 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. > > > > I suggest you tell your customer that they can't forward their > E-mail reliably unless surfglobal.net removes their SPF restrictions, and > there is nothing that you can do about it. > > > Should I stamp my feet and make a face when I tell them that? :) > > I can simply ask SurfGlobal to accept me as a trusted sender - but I > am trying to avoid that via SRS - so I will not have to make that call or > any others. > > -Nick > --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
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 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. I suggest you tell your customer that they can't forward their E-mail reliably unless surfglobal.net removes their SPF restrictions, and there is nothing that you can do about it. Should I stamp my feet and make a face when I tell them that? :) I can simply ask SurfGlobal to accept me as a trusted sender - but I am trying to avoid that via SRS - so I will not have to make that call or any others. -Nick
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 Hayer Sent: Saturday, March 04, 2006 12:27 PM To: Declude.JunkMail@declude.com Subject: 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 - @Adelphia.net send an email to @greenmountainhealth.com which is an alias on my server that forwards to @surfglobal.net SurfGlobal will bounce the email because it failed Adelphia's SPF. Perfectly legit email - my spf recs are perfect etc. The solution is SRS - otherwise forwarding is dead -Nick John T (Lists) wrote: I think the underlying problem as has been discussed on this list is that anSPF FAIL should not be relied upon as an outright rejection, rather used aspart of a weighting system. John TeServices For You "Seek, and ye shall find!" -Original Message-From: [EMAIL PROTECTED] [mailto:Declude.JunkMail-[EMAIL PROTECTED]] On Behalf Of Nick HayerSent: Saturday, March 04, 2006 11:40 AMTo: Declude.JunkMail@declude.comSubject: [Declude.JunkMail] spf breaks email forwarding - Email customers that forward through me are getting their email bouncedbecause of the original sending domain's spf policy. I understand thisdelima is addressed with "Sender Rewriting Scheme"http://www.openspf.org/srs.html Does anyone have a solution to this w/Declude & Imail? Thanks -Nick---This E-mail came from the Declude.JunkMail mailing list. Tounsubscribe, just send an E-mail to [EMAIL PROTECTED], andtype "unsubscribe Declude.JunkMail". The archives can be foundat http://www.mail-archive.com. ---This E-mail came from the Declude.JunkMail mailing list. Tounsubscribe, just send an E-mail to [EMAIL PROTECTED], andtype "unsubscribe Declude.JunkMail". The archives can be foundat http://www.mail-archive.com.
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 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. I suggest you tell your customer that they can't forward their E-mail reliably unless surfglobal.net removes their SPF restrictions, and there is nothing that you can do about it. Should I stamp my feet and make a face when I tell them that? :) I can simply ask SurfGlobal to accept me as a trusted sender - but I am trying to avoid that via SRS - so I will not have to make that call or any others. -Nick
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@declude.com > Subject: 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 - > @Adelphia.net send an email to @greenmountainhealth.com which > is an alias on my server that forwards to @surfglobal.net > SurfGlobal will bounce the email because it failed Adelphia's SPF. > Perfectly legit email - my spf recs are perfect etc. The solution is SRS - > otherwise forwarding is dead > > -Nick > > > John T (Lists) wrote: > > 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] > [mailto:Declude.JunkMail- > [EMAIL PROTECTED] On Behalf Of Nick Hayer > Sent: Saturday, March 04, 2006 11:40 AM > To: Declude.JunkMail@declude.com > Subject: [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 > > -Nick > --- > This E-mail came from the Declude.JunkMail mailing list. To > unsubscribe, just send an E-mail to [EMAIL PROTECTED], and > type " > <http://www.openspf.org/srs.htmlDoesanyonehaveasolutiontothisw/Declude&Ima > il?Thanks-Nick---ThisE- > mailcamefromtheDeclude.JunkMailmailinglist.Tounsubscribe,justsendanE- > [EMAIL PROTECTED],andtype> unsubscribe Declude.JunkMail". The > archives can be found > at http://www.mail-archive.com. > > > > --- > This E-mail came from the Declude.JunkMail mailing list. To > unsubscribe, just send an E-mail to [EMAIL PROTECTED], and > type "unsubscribe Declude.JunkMail". The archives can be found > at http://www.mail-archive.com. > > > --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
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: [EMAIL PROTECTED] [mailto:Declude.JunkMail- > [EMAIL PROTECTED] On Behalf Of Nick Hayer > Sent: Saturday, March 04, 2006 2:40 PM > To: Declude.JunkMail@declude.com > Subject: [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 > > -Nick > --- > This E-mail came from the Declude.JunkMail mailing list. To > unsubscribe, just send an E-mail to [EMAIL PROTECTED], and > type "unsubscribe Declude.JunkMail". The archives can be found > at http://www.mail-archive.com. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
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 globally available any time soon. I suggest you tell your customer that they can't forward their E-mail reliably unless surfglobal.net removes their SPF restrictions, and there is nothing that you can do about it. SPF is not a magic bullet. Matt Nick Hayer wrote: 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 - @Adelphia.net send an email to @greenmountainhealth.com which is an alias on my server that forwards to @surfglobal.net SurfGlobal will bounce the email because it failed Adelphia's SPF. Perfectly legit email - my spf recs are perfect etc. The solution is SRS - otherwise forwarding is dead -Nick John T (Lists) wrote: 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] [mailto:Declude.JunkMail- [EMAIL PROTECTED]] On Behalf Of Nick Hayer Sent: Saturday, March 04, 2006 11:40 AM To: Declude.JunkMail@declude.com Subject: [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 -Nick --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
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 - @Adelphia.net send an email to @greenmountainhealth.com which is an alias on my server that forwards to @surfglobal.net SurfGlobal will bounce the email because it failed Adelphia's SPF. Perfectly legit email - my spf recs are perfect etc. The solution is SRS - otherwise forwarding is dead -Nick John T (Lists) wrote: 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] [mailto:Declude.JunkMail- [EMAIL PROTECTED]] On Behalf Of Nick Hayer Sent: Saturday, March 04, 2006 11:40 AM To: Declude.JunkMail@declude.com Subject: [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 -Nick --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
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 coming if it ever gets here at all. IMO, real-world issues demand real-world solutions. Matt Nick Hayer wrote: 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 -Nick --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
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] [mailto:Declude.JunkMail- > [EMAIL PROTECTED] On Behalf Of Nick Hayer > Sent: Saturday, March 04, 2006 11:40 AM > To: Declude.JunkMail@declude.com > Subject: [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 > > -Nick > --- > This E-mail came from the Declude.JunkMail mailing list. To > unsubscribe, just send an E-mail to [EMAIL PROTECTED], and > type "unsubscribe Declude.JunkMail". The archives can be found > at http://www.mail-archive.com. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
[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 -Nick --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
