> 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.
