Subject: Re: SPAM Alert: Email Address Harvesting
To: NetBSD-current Discussion List <current-users@NetBSD.ORG>
From: macfinity Mailing Lists <firstname.lastname@example.org>
Date: 01/05/2004 21:45:24
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
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=
> 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
> command (which may be "QUIT", "RSET", or even "HELO" or "EHLO").
> When Postfix rejects a message because text from the content (headers=20=
> 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 =
> be delivered to the same server -- as well it should and you want it =
> 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 =
> delivery of the spam (and hopefully causing the client to generate a
> bounce for any false-positive matches). No bandwidth is saved.
> Greg A. Woods
> +1 416 218-0098 VE3TCP RoboHack=20
> Planix, Inc. <email@example.com> Secrets of the Weird=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
Key fingerprint =3D 0F17 8BDE 1DE6 0BA7 80C3 4ED9 346E 350B BDE3 5870