Subject: Re: SPAM Alert: Email Address Harvesting
To: NetBSD-current Discussion List <current-users@NetBSD.ORG>
From: macfinity Mailing Lists <ml@macfinity.net>
List: current-users
Date: 01/05/2004 21:45:24
hi,

that was what i meant to say. one should be aware not to pay a higher=20
price (higher system load, more bandwidth wasted due to iterative=20
re-connects etc.) by doing something that was intended to avoid paying=20=

the 'normal', low price (bandwidth/cpu cycles wasted to spam as a=20
single event)...

thanks for your very detailed explanation on smtp ;)

>> maybe rfc 2821 (ad smtp, successor to rfc 821) will put some light on
>> this topic?
>
> SMTP is a store and forward protocol (and always was -- i.e. this is=20=

> the
> same no matter whether you look at RFC 821 or the "new" RFC 2821).
>
> An SMTP server MUST read the whole message, the end-of-DATA command
> ("."), and then send a reply code to the client indicating the
> disposition of the message, and then wait for the client to send=20
> another
> command (which may be "QUIT", "RSET", or even "HELO" or "EHLO").
>
> When Postfix rejects a message because text from the content (headers=20=

> or
> body) matches a specified pattern then it _MUST_ still read the whole
> message from the network.  It then sends a (usually permanent) failure
> response code to the end-of-DATA command.
>
> The client should then bounce the message to the sender, and most SMTP
> clients do.  Spamware though will usually just drop the connection and
> go on to try the next victim, which may involve re-connecting back to
> the same server and trying again (though apparently some spamware has
> learned to send a RSET command and try another transaction within the
> same connection if it thinks it knows another valid address that =
should
> be delivered to the same server -- as well it should and you want it =
to
> do this since it's less overhead for you as well).
>
> Note that if you were to break Postfix's SMTP compliant behaviour and
> cause it to drop the connection immediately when the specified pattern
> is matched then you _might_ stop some of the spam from burning up some
> of your bandwidth some of the time, but you would create a situation
> where any spam sent through a real mailer would result in endless
> retries of the same message over and over again eating up MUCH more
> bandwidth until days later when hopefully the sending mailer gives up
> and tries to bounce it back to the sender.
>
> All you're doing with header and content checks is avoiding final =
local
> delivery of the spam (and hopefully causing the client to generate a
> bounce for any false-positive matches).  No bandwidth is saved.
>
> --=20
> 						Greg A. Woods
>
> +1 416 218-0098                  VE3TCP            RoboHack=20
> <woods@robohack.ca>
> Planix, Inc. <woods@planix.com>          Secrets of the Weird=20
> <woods@weird.com>
>
>
--=20
mit vorzueglichster Hochachtung/best regards,

Timo Schoeler=A0-- Informatiker

//macfinity -- finest IT services | www.macfinity.net
Triftstrasse 39 | 13353 Berlin / Germany
Fon ++49 30 25 20 30 20 |=A0Fax ++49 30 25 20 30 19
____________________________________________________________________
PGP Public Key Block at
http://www.macfinity.net/~tis/contact/PGPPKB_timo.schoeler.txt
Key fingerprint =3D 0F17 8BDE 1DE6 0BA7 80C3  4ED9 346E 350B BDE3 5870