Subject: New Release Imminent?

From: "Daryle A. Tilroe" <[email-masked]>
Date: Wed, 22 May 2002 23:27:13 -0600

I just noticed in the last thread on 'Zmailer to Exchange bug ?'
that Matti was suggesting that the next release (2.99.56?) is
possible quite soon.

I am within a few days/weeks of rolling out a new mail server to
replace my venerable, old 2.99.50-s4 machine.  After considering
exim or postfix I decided to stick with zmailer as it has served
me well the last 7 years (has it really been that long?!).  Better
an evil you know and all that :-).

One thing struck me though; zmailer does not quite seem to have
the same visibility and size and/or activity of user base as some
of the other MTA software these days.  It is a little unfortunate
since I believe it was certainly ahead of it's time several years
ago.  I guess zmailer has probably stagnated a little due to
Matti's real job and it has also been a victim of it's own stability
and features in that it has not seemed to required a lot of
upgrading and development, particularly lately.  By the latter I
guess I am alluding to users like myself who can set up a server
and then have it chug away for years with minimal intervention.  In
the last 4 years since upgrading to 2.99.50-s4 I think I have had
to make 3 or 4 non-critical tweaks and it has never crashed on me.
The only reason for upgrading now is that the old server needed a
complete hardware upgrade for space and performance reasons and it
seemed like a good time to upgrade all the software as well.  BTW
do NOT take this rambling as any sort of criticism, rather an
observation.

Anyhow, the new box is running RH7.2 and I had originally tried
compiling 2.99.55.patch1 but after some fooling around gave up
and checked out the latest CVS source (about a month ago now).
The CVS complied quite nicely and seems to work well in testing
but I am a trifle nervous about releasing it to a production
environment.  I guess I am interested in what it's shortcomings
might be and/or when 2.99.56 is going to be frozen?  Hey only 44
more revs till gold :-) or do we switch to 2.99.99.01?

On a somewhat unrelated note; what are the correct parameters and
test for the smtpserver security bug in the latest releases?  I.E.
is it now completely safe to leave the 'ftve' flags in and what
result should the 'MAIL FROM...' test return?:

http://www.zmailer.org/securitybug.html

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

---

From: "Daryle A. Tilroe" <[email-masked]>
Date: Tue, 11 Jun 2002 13:30:39 -0600

I am using this feature to stop quite a bit of inbound junk
at the smtpserver stage.  For example I put old employee
addresses in here.  I think this may be a stupid question but
if and how can regular expressions/wild cards work here.  My
specific example is that I would like to block email with
a "." in the to name part of the address sent to my domain.
For example:

[email-masked]

This should be simple since I can block both inbound and
internal as no valid email addresses in my domain have a ".".
Something like this:

.*[\.][email-masked]$

So is this possible at all?

---

From: Matti Aarnio <[email-masked]>
Date: Tue, 11 Jun 2002 22:58:44 +0300

> a "." in the to name part of the address sent to my domain.

  The whole facility is written with "pick the (sub-part-of) address,
  see if it can be found from the policy database by simple lookup"
  paradigm.  It really can't do any sort of iterative regular expression
  analysis.  Also, it works with MAIL FROM and RCPT TO envelope addresses
  only, paying no attention to message content (visible From:/To:/Cc:)

> So is this possible at all?

  Perhaps.  The  "man smtpserver" does describe "CONTENTFILTER
  INTERFACE", which is somewhat fragile, and difficult to use,
  especially when the filter program has a bug (like I had
  last weekend here at nic.funet.fi...)

  The  utils/smtp-contentpolicy.in  PERL script tries to show
  the interface, but alas there are a few bugs in it which I
  have learned about over last couple of weeks...

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

---

From: Roy Bixler <[email-masked]>
Date: Wed, 12 Jun 2002 12:01:04 -0500

>   have learned about over last couple of weeks...

Could you elaborate on the why the interface is "fragile and difficult
to use"?  I am interested in the content filter from the standpoint of
attaching a virus checker to it.

Thanks,

-- 
Roy Bixler
[email-masked]
-

---

From: Matti Aarnio <[email-masked]>
Date: Wed, 12 Jun 2002 20:11:20 +0300

> >   last weekend here at nic.funet.fi...)
... 
> attaching a virus checker to it.

  If the program gives unexpected outputs (like some PERL syntax error),
  the policy report is considered to be "-1 550 5.7.1 ...",  which
  might not be quite wanted -- especially when the reason is a perl
  goofup..

---

From: "Daryle A. Tilroe" <[email-masked]>
Date: Wed, 12 Jun 2002 11:53:37 -0600

>   last weekend here at nic.funet.fi...)

So basically using the existing smtp-policy setup there is no
way to do this because the lookup cannnot understand any
regular expressions?

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 13 Jun 2002 11:20:46 +0200

Matti Aarnio <[email-masked]>
>   might not be quite wanted -- especially when the reason is a perl

Shouldn't the smtpserver give a 4xx code and syslog an error if the
program behaves unexpectedly?

--Arnt
-

---

From: Matti Aarnio <[email-masked]>
Date: Thu, 13 Jun 2002 13:40:26 +0300

> program behaves unexpectedly?

  Like I said, it is "fragile".  I need to have a moment to
  re-engineer it to have sensible behaviour in absense of
  proper responses.  (Response lacking leading signed integer,
  or possibly to tighten the protocol to always demand the
  initial triplet, e.g.:  "-1 550 5.7.1 blabla...", and if
  that isn't gotten, then reply with "-1 450 4.7.1 blabla.."..)

  Of course, somebody else may also lend a helpfull hand, and
  make such re-engineering, and I will apply the patch. ( ;-) )

  Also, a collegue of mine said that "550" isn't proper response
  for the end of the DATA in all conditions.  That needs checking,
  and fixing.  It isn't proper to reply with bogus codes; while
  most UNIX systems look at the first character to classify the
  response, way too many M$ platform systems look into the entire
  code, and get mighty upset (and do unexpected) if they don't see
  codes what they expect per RFC 821..

---

From: Eugene Crosser <[email-masked]>
Date: Thu, 13 Jun 2002 15:46:57 +0400 (MSD)

On Thu, 13 Jun 2002 13:40:26 +0300 Matti Aarnio <[email-masked]> wrote:

>   proper responses.

With the recent exposion of spam and virus traffic, I became concerned
about content filtering.  But I am wandering if extra fork()/exec() for every
message is practical...  We currently process well over a million messages
per day.  Ideally, content filter might be built in smtpserver binary, with
filtering rules dynamically reloadable the same way as current policy database.

--
Eugene Crosser, head of Internet Applications section, +7 501 787 1000
ROL, Teleross, Golden Telecom, http://user.rol.ru/~crosser/

-