On Sun, Jan 25, 2004 at 03:50:08AM -0800, Greg Connor wrote:
OK, back to the question of forwarding.
Case 1. IF sender is not rewritten:
Let's call this "simple" forwarding. Since the envelope is not
rewritten, additional hops will not be able to check the SPF info.
This is usually called "relaying", not "forwarding".
I accept your terminology. However, businesses that do this may still
refer to themselves as "forwarders".
IMHO:
If mail is coming _to_ you, through such a business, you don't check
SPF. You just trust their IP. They will have to do SPF checking.
Alternatively, they _do_ alter MAIL FROM and are prepared to process
bounces on your behalf.
If mail from you is being sent through such a business, you publish
_their_ outgoing relay in _your_ SPF record. Alternatively, they
_do_ alter MAIL FROM and no action from you is needed.
I think my point, which I didn't state very clearly, is that SPF breaks
forwarding (which we all knew) and SRS is not being well-received. So,
perhaps some kind of whitelisting will always go hand-in-hand with spf v1.
We used to know it was OK to send mail via a random MTA to a final
destination. Sometimes this came in handy, when something broke or
when connectivity was poor. Nowadays this is inappropriate behaviour.
Other techniques have emerged and we learned to cope with it.
We are going to have used to know it was OK to send mail using a
alien MAIL FROM. Sometimes this came in handy. In the near future,
this will be considered inappropriate behaviour. Other techniques
will have emerged and we will have learned to cope with it.
SPF also has its flaws. Forwarding is one. Single-minded devotion to the
envelope sender as the end-all and be-all of verification is another. I
don't think it's going to take long for spammers to realize that all they
need to do is spit out something different in the envelope sender that
doesn't appear anywhere in any header, and it passes right through SPF,
even if the Sender: and From: are both bgates(_at_)microsoft(_dot_)com(_dot_)
Huh? Why should MAIL FROM be different from any header? It can be,
but why does it _need_ to be? They find an open relay and will use
that domain in their "From:" as well as in their "mail from:"
I see "forwarding pretty much breaks" as a pretty big incentive to make
sure SPFv2 fixes it. Also, any approach that pays no attention to headers
at all will be of limited benefit to users. I see those as pretty big
targets for SPFv2 to try and fix.
SPFv2 could work around the problem -or- forwarding is fixed. I'm not
sure the solution is to keep working around the problem (which the
current forwarding "solution" as used by many is IMHO).
Perhaps I'm being too paranoid, but let's say SPF causes spammers to change
their behavior, but they adapt relatively quickly, and scramble the
envelope sender to not match the headers. If SPF causes relatively little
pain for spammers, and much more pain for forwarders, administrators will
find themselves looking at alternate proposals. If that happens, let's be
ready with v2.
SPF makes sure MAIL FROM is true. Blacklisting spammers can thus occur
on the RHS. SPF in itself doesn't stop spam. SPF is just another tool
to help in the fight.
There used to be a time every mail coming from "@aol.com" was suspected.
People would blacklist MAIL FROM: <(_dot_)(_dot_)(_dot_)(_at_)aol(_dot_)com>
Next step was to list authorized injetion points for aol.com but this
was manual and rather static. Not all mail from aol.com was rejected.
Some mail would be rejected even when it was coming from a (new) host
from aol.
Next step is SPF where this publishing of authorized injection points
is automated and somewhat dynamic. More domains like aol can use it,
even the smaller ones that would never have a chance to be manually
included.
five times my $0.02
cheers,
Alex
--
begin sig
http://www.googlism.com/index.htm?ism=alex+van+den+bogaerdt&type=1
This message was produced without any <iframe tags
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡