Hi Marc,
On Thursday 30 October 2003 00:50, Marc wrote:
I have to disagree with you about a portion of your message:
the admin of an MTA is opnly interested in 1 thing -
delivering legitimate email. Spam, worms/viri etc from forged
and non-existant addresses should be IMMEDIATELY rejected, not
bounced, by issuing a 5xx response at the DATA command. A forged
email is simply not allowed onto my server.
Actually, I think that the first part of the above is exactly correct--the
MTA admin is only interested in delivering legitimate email. Bandwith
costs and CPU costs are, for the most part, insignificant. Especially when
related to the costs of end-user time to process and discard mail. Yes, a
complete inbox of spam (let alone multiple mailboxes, or hundreds) can take
up a serious amount of storage, but simply receiving a complete message and
discarding it as spam does not take up permanent storage. And as
SPF+blacklisting becomes more effective, the bandwith will be reduced
because less spam will be sent.
I would love to agree with your last sentence - at the moment I am just
-hoping- that less spam will result!
I must confess to forming my views on a mix of other peoples opinions and my
own personal experience - with a heavy slant to the former. OK, starage is
not an issue for my server (though it is for me - I'm daft enough to keep
copies of most spam for analysis later..!). Bandwidth, however, is an issue,
and we ought to keep this in mind.
Random disjointed comments, as I am travelling today, and short on time...
As SPF/RMX/LMAP/etc expands, spam initially will _not_ decrease. Spammers will
just spend more time getting it into the system and defeating our defenses. I
see mails specifically routed though secondary mail exchanges, SMTP protocol
violations, etc... The warning is that as this attempted activity increases,
you are effectively contributing to a dDOS on your own server, as the spammer
probes your defenses.
I could just accept the message, and drop it into the bit bucket. Is this what
we are suggesting -should- happen? I am not happy with this idea.
If a mail is fake, I have to REJECT it, and NOT (NEVER, UNDER ANY
CIRCUMSTANCES, ABSOLUTELY PROHIBITED {you get the idea!}) accept it, then
generate a bounce.
If it is to be rejected, I want to do it ASAP. Actually, going back a bit, CPU
costs for me are not insignificant. I am currently having to seriously
redesign out MTA, because it is doing an awful lot. If I can 5xx at the RCPT
stage (that is, before the connecting MTA issues a DATA command), I have done
very little :
HELO verification and (hopefully) SPF check.
If I have to wait until I have received all the data (so that I can read and
headers in the message body), I have done the following:
a LOT of DNS queries (Connecting host, envelope sender address, from
address, recipient address, RBL's ...)
an IDENT query
DCC & Razor & other spam checks.
Viral Scan
used a lot of processing power, and tied up a socket for a noticable length of
time whilst all this occurs. Whilst I am happy with some of the costs, I am
most unhappy with the time lag whilst these checks occur.
Using anything in the message headers to convey information about forgery is
going to be a -VERY- expensive way of implementing what should be a very
simple process.
-------
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.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡