< draft-lindberg-anti-spam-mta-07.txt		draft-lindberg-anti-spam-mta-08.txt >
	INTERNET-DRAFT Gunnar Lindberg		INTERNET-DRAFT Gunnar Lindberg
	draft-lindberg-anti-spam-mta-07.txt Chalmers University		draft-lindberg-anti-spam-mta-08.txt Chalmers University
	Expires April, 1999 of Technology		Expires April, 1999 of Technology
	23 Dec 1998		30 Dec 1998
	Anti-Spam Recommendations for SMTP MTAs		Anti-Spam Recommendations for SMTP MTAs
	Abstract		Abstract
	This memo gives a number of implementation recommendations for SMTP,		This memo gives a number of implementation recommendations for SMTP,
	[1], MTAs (Mail Transfer Agents, e.g. sendmail, [7]) to make them		[1], MTAs (Mail Transfer Agents, e.g. sendmail, [7]) to make them
	more capable of reducing the impact of spam(*).		more capable of reducing the impact of spam(*).
	The intent is that these recommendations will help clean up the spam		The intent is that these recommendations will help clean up the spam
	skipping to change at page 8, line 33 ¶		skipping to change at page 8, line 33 ¶
	for different rules (e.g. 451 Temp Fail vs 550 Fatal Error).		for different rules (e.g. 451 Temp Fail vs 550 Fatal Error).
	The discussion below often ends up with a need to do various forms of		The discussion below often ends up with a need to do various forms of
	pattern matching on domain/host names and IP addresses/subnets.		pattern matching on domain/host names and IP addresses/subnets.
	It is RECOMMENDED that the data/template for doing so may be supplied		It is RECOMMENDED that the data/template for doing so may be supplied
	outside of the MTA, e.g. that the pattern matching rules be included		outside of the MTA, e.g. that the pattern matching rules be included
	in the MTA but that the actual patterns may be in an external file.		in the MTA but that the actual patterns may be in an external file.
	It is also RECOMMENDED that the pattern matching rules (external		It is also RECOMMENDED that the pattern matching rules (external
	file) may contain regular expressions, to give maximum flexibility.		file) may contain regular expressions, to give maximum flexibility.
	Of course all string matching on domain/host names MUST NOT be case		Of course string matching on domain/host names MUST NOT be case
	sensitive. Since <local-part> may be case sensitive it may be natural		sensitive. Since <local-part> may be case sensitive it may be natural
	to keep that here. However, since <sPAmMeR@domain.example> and		to keep that here. However, since <sPAmMeR@domain.example> and
	<spammer@domain.example> is most probably the same user and since the		<spammer@domain.example> is most probably the same user and since the
	string compares are used to refuse his messages, we suggest that		string compares are used to refuse his messages, we suggest that
	<local-part> comparisons be case insensitive too.		<local-part> comparisons be case insensitive too.
	The interpretation that should apply to all these recommendations is		The interpretation that should apply to all these recommendations is
	flexibility - regardless of how well we design anti-spam rules today,		flexibility - regardless of how well we design anti-spam rules today,
	spammers will find ways around them and a well designed MTA should be		spammers will find ways around them and a well designed MTA should be
	flexible enough to meet those new threats.		flexible enough to meet those new threats.
	skipping to change at page 21, line 14 ¶		skipping to change at page 21, line 14 ¶
	o Hosts used as unauthorized Mail Relays become overloaded.		o Hosts used as unauthorized Mail Relays become overloaded.
	Besides the technical implications, this too requires a lot		Besides the technical implications, this too requires a lot
	of human resources, cleaning up mail queues and taking care		of human resources, cleaning up mail queues and taking care
	of furious external users that were spammed through the Relay.		of furious external users that were spammed through the Relay.
	o The fight against spammers includes blocking their hosts (which		o The fight against spammers includes blocking their hosts (which
	is described in this memo). However, there is a great risk		is described in this memo). However, there is a great risk
	that Mail Relay hosts may be blocked too, even though they are		that Mail Relay hosts may be blocked too, even though they are
	also victims. In the long run, this may cause Internet		also victims. In the long run, this may cause Internet
	mail service to deteriate.		mail service to deteriorate.
	o The common use of forged "MAIL From:" and "From:" addresses		o The common use of forged "MAIL From:" and "From:" addresses
	puts the blame on innocent persons/hosts/organizations. This		puts the blame on innocent persons/hosts/organizations. This
	is bad for reputations and may affect business relations.		is bad for reputations and may affect business relations.
	Several of the methods described in this document increases the load		Several of the methods described in this document increases the load
	on several support systems to the email system itself. Those support		on several support systems to the email system itself. Those support
	systems can be DNS, logging, databases with lists of local users,		systems can be DNS, logging, databases with lists of local users,
	authentication mechanisms and others. Implementing the methods		authentication mechanisms and others. Implementing the methods
	described in this document will, because of that, increase the risk of		described in this document will, because of that, increase the risk of
End of changes. 4 change blocks.
	4 lines changed or deleted		4 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/