Re: Mail to postmaster...

[Matti Aarnio <mea@nic.funet.fi>]

On Tue, Feb 01, 2000 at 04:30:37PM -0400, David L. Potter wrote:
> Snipped for local correspondence...
> 
> >> I thought mail to postmaster@some.site should _ALWAYS_ be accepted, 
> >> regardless of whether an address is blocked because of spamming or not.
> 
> > It's not accepted (ZMailer errors out at the MAIL 
> > FROM:<badaddress@somedomain.com> stage). 
> 
> 
> Was I crazy thinking that mail to postmaster should always be accepted or 
> have we got something wrong in our configuration...?

	Good question.  You don't have any specific example available ?

	Part of the problem is that the source address rejection happens
	way before recipient analysis has a change to happen.

	Very recently (in CVS) I have been toying with a new arrangement of
	policy parameters so that in the boilerplate file (smtp-policy.src)
	there is easier way to choose how to use which of the possible
	RBL-like blocks -- so that essentially the test happens very early,
	but blocking+reporting happens late at RCPT TO phase.

	I haven't thought of delaying other possible MAIL FROM rejection
	message until the RCPT TO phase, though.

	There are four base classes of possible things:
		- Source address syntax errors -- absolute garbage in input
		  (Undelayable)
		- Source address domain does yield NODATA or NXDOMAIN for
		  the DNS lookups (or times out)
		  (Undelayable)
		- Source (IP / MAIL FROM) address is listed in local static
		  rejection tables
		  (Undelayable -- should perhaps be delayable)
		- Source IP address is listed in RBL-like databases
		  (This is delayable at 2.99.52 -- CVS contains version of
		   the boilerplate which makes configuration pickup for it
		   simpler..)

	An always successfull form should be:

		MAIL FROM:<>
		RCPT TO:<postmaster>

	but this is a "should", not an "is"..
	(I didn't go thru the code to verify this, that is..)
	Any Syntax+DNS valid source domain should work in that case too,
	even when the RCPT TO carries a *local* domain to the system.

	Also, given that many MUA systems have problems at correlating multi
	RCPT TO related reports to actual addresses sent out, it has already
	been necessary to report input address in the reports.
	(Especially bad in this field are - of course - M$ products, although
	 I won't issue a clean bill of health to any other MUA either, until
	 I am shown some which do the correlation right...)

> david potter
-- 
/Matti Aarnio	<mea@nic.funet.fi>