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

From: [email-masked]
Date: Tue, 30 Jul 2002 11:38:36 +0200 (MEST)

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?

Another question: zmailer also accepts messages for non-existent mail
recipients in my local domain:

3J1O28648r      RCPT To:<[email-masked]>
3J1O28648w      250 2.1.5 Ok; can accomodate 2495 byte message for
<[email-masked]>

How can I prevent this, without 'enable-router' and interactive processing
of RCPT TO which is warned to be a possible intrusion door?

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)

Thanks,

	Andras Micsik

-- 
 Micsik András          [email-masked]
 MTA SZTAKI             http://www.sztaki.hu/~micsik

-
To unsubscribe from this list: send the line "unsubscribe zmailer" in
the body of a message to [email-masked]

---

From: Matti Aarnio <[email-masked]>
Date: Tue, 30 Jul 2002 13:10:58 +0300

> 3J1O28648w      250 2.1.0 Sender syntax Ok

  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.

> 3J1O28648w      250 2.1.5 Ok; can accomodate 2495 byte message for <[email-masked]>
> 

  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..

> (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.

-- 
/Matti Aarnio	<[email-masked]>
-
To unsubscribe from this list: send the line "unsubscribe zmailer" in
the body of a message to [email-masked]

---

From: [email-masked] (Alexey Lobanov)
Date: Tue, 30 Jul 2002 14:38:50 +0400

Hello.

On 30 Jul 2002 at 11:38, [email-masked] wrote:

Date sent:      	Tue, 30 Jul 2002 11:38:36 +0200 (MEST)
From:           	[email-masked]
Subject:        	Zmailer accepts mail from <> (empty address)
To:             	[email-masked]

> 3J1O28648w      250 2.1.0 Sender syntax Ok

Unfortunately, you may not. See http://www.rfc-ignorant.org/policy-dsn.html for full 
explanations.

Alexey

-