Re: Zmailer accepts mail from <> (empty address)

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

On Tue, Jul 30, 2002 at 11:38:36AM +0200, micsik@sztaki.hu wrote:
> My standard zmailer configuration to my great surprise accepts a mail with
> 
> 3J1O28648r      MAIL From:<> SIZE=2495
> 3J1O28648w      250 2.1.0 Sender syntax Ok
> 
> How can I disable this?

  You can't.   That is a must for RFC 821/2821 conformance.
  Error deliveries, and delivery reports are sent in that style,
  and anybody who disables reception of "the box" will never
  receive any of those.

> Another question: zmailer also accepts messages for non-existent mail
> recipients in my local domain:
> 
> 3J1O28648r      RCPT To:<2345678@my.domain.com>
> 3J1O28648w      250 2.1.5 Ok; can accomodate 2495 byte message for <2345678@my.domain.com>
> 
> How can I prevent this, without 'enable-router' and interactive processing
> of RCPT TO which is warned to be a possible intrusion door?

  Aside of the "enable-router" there is no way.
  Indeed I do run several of my systems in interactive router enabled
  style (remember to add also 'f', and 't' characters in the style
  patterns...),  however  a) it loads the system a lot more than
  blind reception does, b) it is slower..

  Presently the likelyhood of configuration screwup becoming security
  threat (the routers do run as root, after all..) is fairly small,
  because the original SH-like string expansion rules were changes
  couple years ago so that careless presence of backticks, or whatever
  in the parameter string values would never be evaluated by the script
  processor.  Nevertheless other threat models can be envisioned, thus
  I won't say yet that it would be danger free...

  In all versions of   router.cf  prototypes there is:

	for method in $(elements $protocols)
	do
		. p-${method}.cf
	done

  .. to illustriate this point.  (The "protocols" is a list defined
  few lines above that, so it isn't user input, but still..)

  My current scripts _should_ be safe, but when you poke them, there
  may open up some ugly hole..

  "Better safe than sorry", and all that..


> And if anyone has a sample content-filter written in Perl, would be very
> fine to get hold of it...
> 
> (Spammers get very nifty nowadays)

  They do, so sad..

  I did inject my FUNET filter into cvs (utils/smtp-contentfilter.mea@funet),
  have a look there.

  It is _NOT_ perfect, indeed perhaps I should rewrite it again to use
  spam-assassin to analyze the message headers/body, also to do message
  header syntax verification..

  All in all, the framework should probably be written in C instead of
  the present PERL.

  Furthermore, I _THINK_ I will change the interaction protocol from
  its current one (worker is silent, master speaks, worker reports, and
  the cycle repeats)  into scheduler-ta -like (worker reports readiness,
  master speaks, worker reports results, and the cycle repeats..)

  When I get to that, (and what other patches I have in queue to merge),
  I plan to mention it at least in the  README.UPGRADING file,  maybe
  also to the list.

> Thanks,
> 	Andras Micsik
> -- 
>  Micsik András          micsik@sztaki.hu
>  MTA SZTAKI             http://www.sztaki.hu/~micsik

-- 
/Matti Aarnio	<mea@nic.funet.fi>
-
To unsubscribe from this list: send the line "unsubscribe zmailer" in
the body of a message to majordomo@nic.funet.fi