Known/suspected bugs/Missing Features on current Zmailer sources
- Configuration files, esp. cf/aliases.cf has controversy in it.
Many people think it is broken (I tend to agree) - 940614/mea
- Canned error messages are abysmal -- they need more complete ways to
configure what is told and how, whole error facility needs an overhaul
in fact.. (See mention above about: IETF NOTARY)
libc: "make install" is "crazy"
proto: "make install" -- nothing goes in ???
--> MAILSHARE/proto/ !!
All programs (?)
- At places where time definitions are entered, allow always
"6m30s" type notation in addition to plain integers..
Badly out of date!
BUG: $(elements zz) does not result in a LIST type object
in proper way. Most visible this problem is in server.cf
9-9-1999 -- POSSIBLY fixed
BUG? router/functions.c: $(homedirectory ..) function does
getpwnam() from somewhere WITHOUT checking at the
possible errno telling that there is e.g. temporary
access error with backend database...
Replace current multi-process router farm with one where queue
scanner runs interactive routers alike the smtpserver hooks
z# stableprocess 123456
z# stableprocess 123457
z# stableprocess 123458
z# stableprocess 123459
All results (except prompts) of the router need to be dumped
to the router logfile. At each prompt, that logfile can be
re-opened so that simple log rotate with 'mv' works.
(older entry way below had:)
Have separate queueing processor feeding actual routers
to take care of the problem related to message priorities.
Could implement: high/normal/bulk/junk priorities which
contains ways to be able to process messages from different
work categories without causing starvation of some class
queue; E.g. at least one router per class, but if some
class is (momentrarily) empty, its router can work other
(another old entry had:)
- Log-file option does not set (reliably) the logfile
to be something else, than the default.
** Well... See $MAILSHARE/cf/standard.cf: dribble routine, and
** especially its calls! Not so easy to configure externally...
- SIGHUP log close/reopen does not work quite as one would
want it to work. In fact it does not close the files, rather
opens new ones after it has dup()ed old descriptors away from
the harms way.. e.g. it leaks log-files..
If reply waiting in smtp_sync() gets SIGALRM, program crashes..
(syncing for BDAT, for example.)
There is some memory leak (possibly in all ta programs?),
propably in MIME header rewrites. It appears only in
very long living and hard working smtp-ta program as
slow size growth.
SSL/TLS client functionality has been asked for repeatedly.
To implement it we must rewamp the entire FILE* abstraction
based network socket (write) buffering at the smtp program,
PLUS at libta/mimeheaders.c ( writeheaders() ) as well...
Not so nice. (AT&T Research Sfio *may* help here..)
VERIFY: BDAT (and DATA) status processing in case the remote
yields disk-full temporary error.
To rewrite the MX processing in streamlined flashion:
In case two domains have common (sub-)set of MX servers, and
we have been feeding mail to domain A thru MX-server B, and
now we change to deliver domain C which too has MX-server B.
We are to reuse the already open channel to server B to feed
the message out even though the domain C might have had server
D with lower preferrence..
(Noting that all MX-hosts with same or larger privilege,
than ourselves are to be pre-removed from the list!)
- We violate RFC 1123 part 5.2.2 which says that at MAIL FROM
and at RCPT TO the domain parts MUST be primary DNS objects,
*not* CNAMEs. We never rewrite...
- Somewhere ? (smtpserver, and perhaps smtp transport agent ?)
Implement OUTBOUND message size limit mechanism.
Possibly a multi-value system which works against
IP/reversed domain information, and adjust maximum
inbound message size at the smtpserver per that
A further complication is need to limit outbound
email's sizes when the inbound size is limited so
that our system will not send out anything to which
error report size is larger than our inbound limit.
Problem being, of course, that outbound channels
need to interrogate that same configuration mechanism
to do "Sorry, this is too large for sending" processing.
- All transport agents:
- Unify the content MIME processing routines; Construct them
to be a common sub-layer ?
- Do not decode Q-P or Base-64 if the resulting material exceeds
RFC-821/RFC-822 line length limits (or whatever limits have
(router + TA library + TA programs):
Router to scan message MIME structure, and to store that
into dense consise format which doesn't need prerescan of
the message *body* for every delivery attempt in case some
"in-flight" data conversions are desired.
- transporters: When decoding MIME-QP the final line MAY be of
".....=", which means there is no final NEWLINE.
Fixed on SMTP, must fix on MAILBOX, and SM! (4-Jan-95)
(Prepared to do it, however only on SMTP it is fatal -- I think..)
How does arrival of a new job into active thread work in case
the current activity has already reached the end of the thread ?
When will the new job be fed to the transport agent ?
Sometimes will generate spurious successfull-delivery-
reports when the command is retried, and the tag selector
is unable to start the real processor.
resync mechanism needs to be rewritten; now it throws away
all info about the file, while it should only scan thru all
data, and sync in-core status with the file.
(incomplete code skeleton written for this)
( sync_cfps() is that skeleton.. )
Tool/mechanism for requeueing a message from the transport
back to the router -- all message recipients that have not
been processed yet.
Tool/mechanism for the scheduler to command expiration of all
recipients in given thread. (alike 'manual-expiry', except
a bit smarter..)
A new management channel protocol.
- Delivery messages plain-text part needs easier human
understandable format on the messages.
- Does the NOTIFY=SUCCESS work ok ?
[2.99.49b2 - now it should ("ok3" status code)]
Have two waiting threads (one message each):
- start both of them with ETRN
- both issue report of "retryat +nn"
- both are rescheduled about immediately..
- system spins (FAST) on those two...
(Fixed ? Haven't seen this for a while)
- New cfg param: maxha -- max age that a child-process can be
active, and the scheduler will wait for that much after the
feed for any "#hungry" message from (to detect hung-up processes)
- Another: maxlife -- maximum lifetime for a transport agent
for limiting the time a smtp-channel stays open for a long-
- Supply PARAM entries for *all* (well, very nearly) command-line
startup options where it makes sense...
- SSL/TLS code needs to be updated to support non-blocking operations,
which appeared at 0.9.4 release of the OpenSSL.
- VERIFY: behaviour on BDAT (and DATA) phases when the disk fills
- Report that if the router subprocess crashes, interactive
processing goes into mixed state -- it reports 2XX, and
yet claims to be in wrong state (MAIL FROM or RCPT TO ?
I have forgotten..)
- accept email to postmaster(s), never mind what else policy testers
- "-s" option processing is entirely wrong...
- The connection source IP reversal is not verified paranoidly, we
may accept people who claim dishonest reversals.. (But then we
can test against their IP address..)
- Have some flag passing mechanism from the initial policy db
back to the smtpserver proper so that it can:
- give more meaningfull explanations of rejection reason
- run more verification subroutines on addresses per policy
driver control; namely "this domain can be valid source only
when it is coming from this IP address"
type of checkup...
- "make install" does not handle manual-page installation properly,
also alternate-root installation has a few odd ends (vacation
man-page, libc/libzmailer.a, (libc)include/zmailer.h )
- Integrate transports/fuzzyalias/ into the configuration system
- Manuals leave a lot to desire.. Especially a good users/administrators
manual is in need
[July 1997: technical writers are hard at work on this one]
[April 1998: Completing the work is at Matti's hands..]
- what UID it runs programs like procmail with ?
What uid it should run them ?
I don't think the current (up to 2.99.49p*) way of running
procmail/cyrus is entirely safe.
- I have gotten comments that they are suid/sgid root/root
at most installations, and indeed so procmail is at my
- DSN handling flags ?
- "localize" the destination address properly. That is, strip
quotes from around a quoted destination address according to
the RFC822 syntax. -- Is this always correct ?
- check existence of mailq/tcp in /etc/services
- check MAILVAR/MAILSHARE/POSTOFFICE protections
- check "nobody" and "daemon" accounts
- systemwide .forward checker
- iterate all users in the system
- check peoples directory ownerships and permissions
- check peoples .forward ownerships and permissions
- Need a program to verify that given configuration is ok, checks
for things like:
- "nobody" userid
- scheduler's resource control working to the maximum
extend that system supports
- mmap() correct operation (GNU autoconf does this)
- sprintf() return type is autoconfigured correctly
- Need a program to run thru various file permission checks:
- $MAILVAR/db/ -dir, and files in it
- $MAILVAR/lists/ -dir, and files in it
- ~/.forward -files (and home directories)
- IPv6 stuff:
- lib/selfaddrs.c: Don't properly do automatic IPv6 interface address
picking (IPv4 is ok)
- libc/myhostname.c: don't do automatic IPv6
- scheduler/mailq.c: don't do IPv6 connect
- transports/hold/hold.c: incomplete NS/AAAA, no IPv6 PTR
- transports/mailbox/mailbox.c: BIFF gethostbyname() ?
- whole chain (smtpserver/router/mailbox+hold):
- Have a NEW pseudoheader (NRCPT) in addition to the ORCPT, which
we now (in not completely kosher manner) create, if we don't get
it originally. That is, similar entry for traversing unchanged
thru the router to tell what address we got as input.
(Thru some pseudo-alias..)
- Retain (in some TA-header object) the original "MAIL FROM:<..>"
address, and be able to store it into the MAILBOX channel.
(That is, don't let the routing process to alter this!)
- Store the ORCPT information into a "X-Orcpt-To: "-header
- Store the NRCPT information into a "X-InRcpt-To: "-header
- Store the ENVID information into a "X-Envid: "-header
- Store the original FROM:<..> into a "X-OrigFrom: "-header
- Provide aforementioned "headers" also as environment variables
to the pipes
- At the router:run_rfc822(): if the message has these headers,
purge them away.
- Autoconfig problems:
- System mailbox locking schemes are sometimes non-obvious..
- For the last PERHAPS must back introduce the host-configuring
for describing host-system dependencies like mailbox-lock schemes
- Got mail with a suggestion: (via zmailer-list)
I suggest you to improve the 'crossbar' function of 'router'.
It might return a list of header rewrite functions as well
as a single function like now. So different rewrite methods
could be applied for sender and recipient addresses.
The crossbar() C function contains some comment that refers
to some similar thing, but I found it unimplemented.
* We expect to see something like
* (rewrite (fc fh fu) (tc th tu)) or
* ((address-rewrite header-rewrite) (fc fh fu) (tc th tu))
* back from the crossbar function.
- When killing previous routers/scheduler/smtpserver, should wait
the previous process group leader to die before writing over
the $POSTOFFICE/.pid.KIND -file.
- Co-ordinated shutdown for the scheduler -- send a signal to it
(SIGQUIT), and it sends out newlines to all processes still
receiving anything from the scheduler, and shuts the feed channels
down from the scheduler to the transporters. Then it will spend
some time (infinity?) to get responces from the transporters.
When all childs are dead, it can exit.
20-Jan-97: Sort of facility exists now..
- DSN (Delivery Status Notification) mechanism does not (yet) report
- Want to have more interactivity at the scheduler status and control
mechanisms. Especially thinking a new two-way system where there
can be multiple manager interfaces acting at the scheduler ``mailq''
port issueing commands (queries), and receiving responces.
With authentication, could do queue purges, rerouteing commands, etc.
- 'channel error' detection is partial at places;
transporters: hold, errormail
- router/rfc822.c: sequencer()
Consider providing some data/function/whatever telling to
the configuration script how many "Received:" headers there
are so that the message can be trapped for a loop-prevention
in the script, and not hardwired in the sequencer() code.
(Now has a global variable that gets the count of "Received:"
headers, but the loop-count exceeded trap is done in the
same C-code without calling the scripts...)
- Sometimes incoming SMTP can be a hellish load, need to introduce
a load-limited incoming SMTP acceptor (smtpserver/smtpserver.c)
(Rayan wrote it, but never released it..)
13-Dec-94: It exists for Linux ....
23-Dec-94: Pulled bits from "top" -program. Now it
exists also for Suns..
A discussion on the ZMailer -list revealed that the acceptance blocking
is a BIG can of worms, and that even the BSD-sendmail has had a long
journey along the rocky path to "get it right"... (5-Jan-95)
Hmm.. Perhaps we could do a `single process doing multi-stream reception ?'
it would require fairly large rewrite of the SMTP-server..
Also: What to do when there are more incoming SMTP sessions than the
process can have open file descriptors ? One for the SMTP socket, one
for each spool file in active use at the input phase, and one for log.
(The stdio is used only for SMTP responses, and for spooling out the
accumulated message. Thus there SHOULD be enough resources for all
uses -- except when the system runs out of FDs per any individual
- Processing of several headers is questionable/lack of:
Generic: header wrapping within N chars (like to 80-chars
space of BITNET) and also infinite wide systems,
like News.. (transports/libta/writeheaders.c ?)
Generic: RFC-1342 aka. non-US-ASCII chars in the headers..
Auto-conversion and wrapping