[ On Monday, January 5, 2004 at 09:57:29 (+0100), macfinity Mailing Lists wrote: ]
> Subject: Re: SPAM Alert: Email Address Harvesting
>
> 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 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 another
command (which may be "QUIT", "RSET", or even "HELO" or "EHLO").

When Postfix rejects a message because text from the content (headers 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.

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>