I think the relevant discussion, which nobody has addressed, is when to
terminate the email and what benefit you would observe. Therefore, to be
direct, in reality approximately what percentage of you overall bandwith
goes to spam? This is bandwith which would be absolutely recoverable by
rejecting a message at the early phase rather than accepting it and then
deleting it. Second, why was the question only addressed to ISP's? Are
corporate users no less important?
Marc
-----Original Message-----
From: Larry Smith [mailto:lesmith(_at_)ecsis(_dot_)net]
Sent: Wednesday, January 21, 2004 4:31 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Calling ISPs: does bandwidth matter to your
bottom line?
On Wednesday 21 January 2004 15:04, John Capo wrote:
Quoting Meng Weng Wong (mengwong(_at_)dumbo(_dot_)pobox(_dot_)com):
On Wed, Jan 21, 2004 at 01:04:31PM -0500, Meng Weng Wong wrote:
|
| Could ISPs please weigh in on whether your email/spam bandwidth cost
is
| signicant or not, thanks.
The decision at hand is:
How important is it to reject forgeries before DATA vs after DATA at "."
time.
Its quite easy to add the hooks needed to reject before DATA to a
lot of MTAs, especially Postfix. Rejecting after DATA is much more
complicated. In my case a system redesign.
If I accepted all of the junk that I reject at the door, my bandwidth
costs would increase about 50%.
If it is important, that's an argument in favour of the envelope sender,
otherwise the argument allows use of headers.
Weighing in on the "light-weight" scale of things (I am small and don't
weight much)... I would have to agree with Bob and John specifically in the
context that as an "ISP" - I sell "access" which corelates almost directly
to
"bandwidth". The more spam, the less "bandwidth" available for other (more
legitimate) uses; the more spam, the more I have to tweak and work with my
mail servers and routers and other "backbone" support issues -and the more
time me and my support staff spend talking, working with, consoling, etc,
etc. customers who really don't understand why (they get so much "junk"
mail)...
On the one side I have customers that simply stop reading their mail because
there is just too much "junk" (from their perspective) to deal with; I also
have (ex)customers who cancelled their service just because they figured
changing service (read that email accounts) would "help" at least in the
short term.
The bottom line to this being - the sooner (eg before the helo if possible,
but definitely before the data if _at_all_ possible) that I can "reject" a
message/connection and get off the line so-to-speak; the sooner my server
can
go on to something else productive. Regardless of who or what you support,
there are at some point a finite level of resources available - even
"super-servers" max out at some value of X number of connections (be it
smtp,
nntp, www, or whatever). The "big" guys can load-balance, split-horizon,
share-resources and so forth - but we are all seeing the same result -
resources being consumed almost as fast as we upgrade.
My vote is for determination _prior_ to the data statement....
--
Larry Smith
SysAd ECSIS.NET
sysad(_at_)ecsis(_dot_)net
-------
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;±¤Ö¤Íµø?¡
-------
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;±¤Ö¤Íµø?¡