24 Jul 08:31
RE: Re: SPF and Google Groups (sending on behalf of)
From: John Kirkwood <jkirkwood <at> kclinfo.com>
Subject: RE: Re: SPF and Google Groups (sending on behalf of)
Newsgroups: gmane.mail.spam.spf.help
Date: 2008-07-24 06:31:54 GMT
Subject: RE: Re: SPF and Google Groups (sending on behalf of)
Newsgroups: gmane.mail.spam.spf.help
Date: 2008-07-24 06:31:54 GMT
Dear all,
Many thanks for your clarifications and input. It turns out that the
SPF implementation was fine, but some separate processing had been
added temporarily, which interfered and has now been removed.
Apologies for the static.
However, the situation I now face is that 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. (I was
assured that mail relay was allowed for the dotster.com mailservers,
although I am now told that it is not and that the only solution is to
remove the relay).
Before I go hunting for another mail provider, can anyone say whether
SPF would normally have any problems with mail relay? (I am loathe to
lose my death2spam mail filtering - it does a damn good job).
Many thanks,
John
-----Original Message-----
From: Alex van den Bogaerdt [mailto:alex <at> ergens.op.het.net]
Sent: 20 July 2008 15:13
To: spf-help <at> v2.listbox.com
Subject: Re: [spf-help] Re: SPF and Google Groups (sending on behalf
of)
On Sat, Jul 19, 2008 at 06:36:41PM +0200, Frank Ellermann wrote:
> > does still not mean the discussion belongs here.
>
> IBTD because I'd like to know if this is dubious code.
> If we know this we could put a warning on the SPF site.
>
> SPF users should never have to worry about such issues,
> and if an implementor confused MAIL FROM with 2822-From
> (s)he belongs into a "hall of shame" on the main page -
> hopefully convincing other implementors that this isn't
> how they want a link to their code.
I think you know very well what I was saying, but for the off chance
that you didn't: there's one specific entity which takes our carefully
crafted SPF records and then {ab|re}uses them for their own
incompatible
protocol: SenderID.
If implementors get it wrong when parsing the various headers with all
their if-then-else decisions, that's indirectly the fault of this
other
protocol, not ours. Why should we provide support?
I strongly believe that anything looking at message headers (perhaps
with the exception of return-path) is SenderID and that questions on
this should be redirected to the appropriate place.
I urge all who do actually implement SenderID to mention SenderID in
their error messages/bounces, not SPF.
Right now I feel like we are an unpaid helpdesk for MS, something I
do not like very much.
Cheers
Alex
-------------------------------------------
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
<!D2S:heatherbr <at> kclinfo.com/good/3a2d0b1/≥
RSS Feed