24 Jul 10:23
death2spam.net (was: SPF and Google Groups (sending on behalf of))
From: Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz <at> gmail.com>
Subject: death2spam.net (was: SPF and Google Groups (sending on behalf of))
Newsgroups: gmane.mail.spam.spf.help
Date: 2008-07-24 08:23:06 GMT
Subject: death2spam.net (was: SPF and Google Groups (sending on behalf of))
Newsgroups: gmane.mail.spam.spf.help
Date: 2008-07-24 08:23:06 GMT
John Kirkwood wrote: > my mail is MX relayed via death2spam.net and then on to > dotster.com, and dotster.com is reapplying SPF as if > death2spam.net were the originating MTA. If death2spam.net forwards mail to third parties it *IS* the originating MTA as far as SPF checkers at these 3rd parties are concerned. > can anyone say whether SPF would normally have any > problems with mail relay? No problems with mail relays on the side of the sender or on the side of the receiver. SPF is in essence for the one critical hop where two unknown strangers (sender and receiver) meet. Now if you introduce a second critical hop in the form of "forwarding to 3rd party" this will nowhere work "as is": S -> F -> R instead of S -> R The sender S defines S-IPs permitted to send MAIL FROM S. The sender S has no reason to permit sending IPs of any forwarder F or forger F, in fact S has no idea who F is. The receiver R checks that MAIL FROM S comes from one of the S-IPs as defined in the sender policy of S. Without intervention sending IPs of forwarder F will FAIL, as for sending IPs of a forger F. There is no difference between "forwarding to 3rd party" and "forging" wrt SPF. Of course there are some things a legit F or R *could* optionally do: R could white list F as legit forwarder (legacy forger). F could rewrite MAIL FROM S to S <at> F (like mailing lists). F could store mails, and let R use say POP3 to fetch it. If F and R do nothing about this situation - and that is perfectly allowed - R sees a FAIL, and hopefully rejects the MAIL FROM S actually sent from F. After that F is obliged to send an error report (bounce) back to S. The sender S can then bypass the forwarder F and send the mail directly to R (if the bounce contains the real address at R). If you think that there is a problem, then your problem is almost certainly with forwarder F, not with S or R. It is up to you how you solve your problem with F. IMO an entity using the name death2spam.net should know that forwarding mail "as is" to 3rd parties is a part of the problem, YMMV. Frank
RSS Feed