begin Monday 24 May 2004 07:42, Greg Connor quote:
--Seth Goodman <sethg(_at_)GoodmanAssociates(_dot_)com> wrote:
That's quite nice. The new convergence makes this somewhat messier. On
the first hop, there is no DAVE parameter, so the SPF test is done on
MAIL FROM: and your SPF record would do the job quite nicely. On
forwarding hops, the DAVE parameter is SPF checked and the 'exists' part
is no longer appropriate, at least with current SPF macros. To make this
practical, we'd need additional SPF macro terms to specify the parts of
the MAIL FROM: address instead of the DAVE address.
Right, I'm assuming that if RFROM checks out OK, you would just skip MAIL
FROM entirely. If RFROM is present, then only a PASS result is acceptable.
But, the SPF checking would be done against RFROM's domain anyway.
In that case, what's to prevent a spammer from using an RFROM pointing
to a domain that he controls, while leaving a FROM that points to an
innocent victim?
==> Bounces and complaints by inexperienced end-user still end up at
the joe-job victim's mailbox (because, supposedly, bounces still go to
FROM).
So, in order to prevent this, the system should only accept RFROM from
"trusted" forwarders.
But once we have established such a list, why bother with RFROM at
all? If the IP address of the mail submitter is on the (local) trusted
forwarders list, accept the mail without any checks.
Small providers may use a manually maintained trusted forwarder list
(in addition to trusted-forwarder.org), large providers may use a web
interface where each end user can enter the forwarders through which
he expects mail. The end user knows the forwarders that he uses,
because in 99% of the cases, forwarding has been set up by the end
user himself, or at his request. The only thing that changes now is
that when the end-user adds a forwarding, he not only needs to set it
up at the forwarding ISP, but also at the receiving ISP.
===> Solution of the "forwarding problem", without SRS and without
SMTP protocol extensions!
Regards,
Alain