Vipul: Here's how CSV or SPF handle the scenario you paint:
Systems that are able to keep their noses clean will have better
reputations than other systems.
An ISP (typically) (in the case of CSV) or a .com domain (typically) (in
the case of SPF) will be motivated by the scheme to keep its nose clean
(the mail stream emanating from its users' systems, that is, to be precise).
If it doesn't, there will be consequences. Its infrastructure costs
will go up, as it has to work hard to deliver a huge mail queue that
piles up as it tries do deliver to machines that are throttling or
tempfailing it's delivery attempts for as long as it's reputation is
questionable.
Make sense? You're familiar with the aspen framework? One difference
between CSV and SPF is that the latter doesn't do a good a job defining
the party most able to do something about the problem. (The SPF
protocol allows the party to be poorly defined and hard to trace.)
On 11/27/2004 4:32 PM, Frank Ellermann sent forth electrons to convey:
SPF is not the FUSSP, it's the next "necessary" step.
Nonsense. SPF breaks MUCH MORE than is necessary to achive sender
authorization and authentication.
Defining "necessary" by the minimal modification you can get
away with (excl. radical approaches like "delete all bounces"
because that breaks SMTP).
At this point, strong SPF checking breaks too much stuff
(especially forwarding).
It's not "especially forwarding"
True, that's not the biggest problem of SPF. A bigger problem is the
ISP end-user support nightmare looming around the corner: the
reconfiguration of every power user's MUA, since SPF breaks their
current configuration. It's not going to happen.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg