Alessandro Vesely [ves...@tana.it] wrote:
Julian Mehnle wrote:
[...]
Now someone at pobox.com (which is SPF protected) sends me a message
to my cpan.org address. The cpan.org MTA forwards the message to the
mehnle.net MTA, which sees the "pobox.com" envelope sender being used
on a message coming from a cpan.org MTA. But the pobox.com SPF record
doesn't authorize cpan.org MTAs to send mail on their behalf, so
mehnle.net rejects the message.
To solve the problem, cpan.org would have to rewrite the envelope
sender to something at cpan.org before forwarding the message.
That not only requires cpan.org to implement SPF, but also SRS.
No, really just SRS would suffice. The act of rewriting the sender during
forwarding does not imply guaranteeing that the forwarded message has been
SPF-checked. It only implies taking full responsibility for the use of
one's domain name as the sender address in the forwarded message.
The SPF checking on the final message is not much useful: it only
tells that you can accept mail from cpan.org, which you should
know already, since you have an account there.
If that message should be SPF-rejected, only cpan.org could do it.
True.
I would be content if they just implemented SPF.
Now that I come to think about it, I guess consequentially white-listing
forwarders who act on my behalf (i.e. where _I_ have set up the
forwarding) may be a philosophy that makes sender rewriting unnecessary.
As a consequence, ESPs would of course have to implement per-user
configurable forwarder white-listing in order not to apply SPF checks to
messages coming from users' configured forwarders. (I think I am going to
create a per-user configurable forwarder/remote-host filter module for
Courier::Filter.)
Still, I do not understand the attack vector to SRS that Sam tried to
describe. Currently I don't believe there is one.
18 messages in net.sourceforge.lists.courier-usersRE: [courier-users] Status of SRS (SP...
