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@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
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com
> 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@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
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com