ietf-asrg
[Top] [All Lists]

Re: [Asrg] Random thought

2003-03-12 23:08:56
From: william(_at_)elan(_dot_)net

...
Based on my tests less then half of mail servers will accept 500 error 
after data command (those are mostly the ones that support limits on size 
of emails - SIZE ESMTP extension I believe).

I'd like to believe that you've only hit bad patch of SMTP clients.

Since I was testing mail servers that connected to my mail server, 
possibly the data was contaminated by spammers who just dont take no (500) 
for an answer.

I don't understand.  How can you know that 5yz responses to DATA are
ignored?  How can you tell the difference between a broken client
that ignores 5yz for DATA and a good client that generates a bounce?
The won't-take-no(5yz) STMP clients clearly do accept and recognize
5yz errors to the DATA command; they just do the wrong thing.


...
Again, why do that when the protocol already includes sufficient
provisions for examining headers or data before making a final decision?

After you receive entire email though... Why wase so much bandwidth when 
75% of spam can be rejected based on just incorrect headers and most 
solutions require using special headers for additional information on 
authentication as well allowing to distiguish between standard mail and 
authenticated email.

The bandwidth required to handle a single mail message is trivial.  It's
typically about that required for a single HTTP page hit.  Only if your
system is handling more than about 200,000 mail messages/day do you need
more than current puny, commodity PC hardware.  I think there are
subscribers to this mailing list who are dealing with 2 Mmsgs/day or
more with cheap, commodity PC boxes, albeit more than one box.

...  
I'm way confused by what you wrote. What I meant is that there is a difference 
between how blacklists work (when SMTP servers responds with 500 just based on
your ip) and how spam filters work (which scans the email, trys to 
classify it as spam and it is - its either discards it or bounced back to 
the sender or sent to special spam folder).

I don't like that distinction for several reasons.  I think a "filter"
is any of those things.  Besides, there are spam defenses that use
DNS IP blacklists to detect and report spam to a distributed network
so that substantially identical copies can be rejected from unlisted
IP addresses.  DNS IP blacklists can do anything of the things that
the other sort can do, including only tag or segregate spam.  It is
at least as common for DNS IP blacklists to operate at the end of the
envelope, so that the SMTP server can accept mail to some mailboxes
such as postmaster from blacklisted IP addresses.


                                            I'd rather have filtering do 
like blacklists and either return an error (instead of discarding or 
trying to send email back) or accept it (either to spam folder or to 
normal folder).

Some implementations of what you call "filtering" can do that.


...
What else I'd find usefull is automated way to say that it requires 
certain type of authentication for email to be accepted (and not just that 
it requires authentication as is possible now).

It's often easier to require the authenticating tokens at the start,
do much of the processing, and only just before doing something
permanent or expensive check the authentiation tokens as well as decide
whether the request is authorized given the authentication.

In other words, if that's what you want, you could simply use SMTP-AUTH
but lie about whether you like the tokens.


Vernon Schryver    vjs(_at_)rhyolite(_dot_)com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>