... reasons1.1
RFC 2821, 6.1 [Kle01] 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... bottleneck2.1
Price/MB for RAM approaches that for a hard disk 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... itself2.2
For example, if the hostname is host.domain.tld then the system should by default accept mail for that name as local, but it should not treat domain.tld as local too. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... storage2.3
That is storage that does not lose its content during a system failure, e.g., power loss. Such storage is usually a disk, but not DRAM. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...bind(2)2.4
It is possible not to specify a port but then the OS selects one which isn't useful for an SMTP server. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...mutable2.5
Better name? 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...yacc(1)2.6
Thanks to John Kennedy for testing this. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... recipient2.7
this is a consequence of the way milters are designed, not a direct consequence of SMTP. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... recipient2.8
this may not be a particular good example. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... only2.9
at least right now. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... recipient2.10
that is, rejecting a recipient if the feature has not been used/is not active. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... ESMTP2.11
Because STARTTLS is per session, not per recipient, hence it is not possible to do this in the server, but it is (theoretically) possible in the client. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... recipient2.12
which is an implementation decision, with a different implementation this would not be possible. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... too2.13
See storage map in sm8. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... bounces2.14
this could be per domain, but which domain? 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... recipient.2.15
There are systems in which local delivery doesn't need to be done as the recipient, because the recipient is not a user of the OS. In that case access must be authorized by other means which however is beyond the scope of sendmail (and this document). Other systems, e.g., System V based Unix versions, use a group-writable mailbox which does not require root access either. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... full2.16
If AQ is full the transaction is currently rejected with a temporary error. This is an area for possible improvements. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... closed2.17
Question: copy or move, i.e., should the data be removed from IQDB as soon as it is in AQ? Answer: copy; the data in IQDB is still required for the list of open transactions. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...$^,$2.18
Note: currently the data is copied from IQDB to AQ immediately after the transaction is closed, not when the transaction data is actually committed to IBDB. This is an area where optimizations are possible, e.g., data is not copied into AQ if the destination is down. However, currently data can be transferred to DEFEDB only via AQ, see Section 2.4.3.3. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... this2.19
2004-04-14: Due to way group commits to IBDB are handled and how entries are marked ``done'' in IBDB. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... full2.20
older and newer refer to ``next time to try'', not when entries are added to EDBC. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... sharing2.21
System V shared memory, maybe mmap(2), others? 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... succeeds''2.22
To provide reliable mail transmission, the SMTP client MUST be able to try (and retry) each of the relevant addresses in this list in order, until a delivery attempt succeeds. [Kle01], pg 59 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... VERP2.23
Variable Envelope Return Paths, [Ber97] 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... first2.24
which in the case of sendmail 8 even requires a restart of the daemon. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... secured2.25
Maybe that data comes from the QMGR? 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... match2.26
Regular expressions can be treated as maps which of course provide more functionality. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... length2.27
in IPv6 subparts can be omitted however. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... RPCs2.28
Remote Procedure Calls, not referrring to the actual implementation by Sun 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... ``functionality''2.29
also called category by ISC or facility by syslog 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... delimiter2.30
of course the encoding can be changed if a different delimiter should be used 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... mechanism3.1
accessing an internal file descriptor allows to get notified when a result arrives, but is not a documented API 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... master.cf3.2
this file can be changed by the user within the restriction listed in caps inside the file. Wietse is certainly tired of people breaking postfix by not following the instructions. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... randomization3.3
sendmail 8 uses mxrand() to compute a hash of the host name which then is used to sort the records (as second order key after priority). This assures that the same order is used every time, hence it may not really fulfill the RFC requirement. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... problems3.4
This might be similar to background fsck in recent FreeBSD 5 versions 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... directory3.5
A simple hashing scheme could be used 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... address3.6
This is what exim does. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... useless3.7
See sm8: there's not much difference between the mailers relay and esmtp. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... recipients3.8
Currently it is implemented as two linked lists, one each for transactions and recipients. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... entries3.9
This is the common tradeoff between storage and computation. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... free3.10
free: no session active; idle: session open, but no transaction; busy: session open, transaction active. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... stored3.11
Unless it is required for other purposes, e.g., logging or bounces. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... above3.12
Again, it might be necessary to keep the original address. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... preserved3.13
For now; this can be relaxed later on, which complicates the algorithm however. Hence it should be determined first whether strict ordering causes a bottleneck. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... queue3.14
Question: does it require updating EDBC? 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... checks3.15
It might make sense to specify a ``strictness'' level for the syntax checks. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... (transaction3.16
sendmail 8 does not have DISCARD per recipient? 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... performed3.17
see item 6 in the list of valid RHS above for an explanation. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... QUICK3.18
It is also possible to use a negative value, but that might cause confusion with sendmail X error values. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... problems3.19
``A bug is a feature that cannot be disabled''. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... standpoint3.20
The current (2004-04-19) implementation accepts mailertable entries due to the way results are returned. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... \$2003.21
2004: 200GB for $100 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... results3.22
Question: what is a useful terminology to distinguish those two results? 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... chosen3.23
At least for now, there might be a configuration option that determines whether a leading dot is required. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... 4.23.24
DB_MPOOLFILE-$>$set_flags(): if DB_MPOOL_NOFILE is set, no backing temporary file will be opened for in-memory databases, even if they expand to fill the entire cache. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... instance3.25
It is impossible in C to store a va_list. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... close3.26
db->close() ``frees any allocated resources'' 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... allocation/deallocation3.27
BDB provides a function to specify malloc(2), realloc(2), and free(2) methods. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... maps3.28
Specifying one as limit means that this is a single instance map only, hence no additional flag is necessary. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... enough4.1
Famous last words? Probably need to increase this to 32 bits. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... pipe4.2
otherwise the write operation could theoretically block 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... set4.3
Note: this is too early, the flag should be set after the transaction has been committed to DEFEDB, but that's hard to accomplish because it would require to have another list of transactions which would be updated after DEFEDB has been successfully changed. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... AQ4.4
this is ok because the recipient is in a persistent DB already, so even if the update requests for DEFEDB or IBDB fail the recipient can be recovered from either DB. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... generated4.5
the latter case is not really necessary but a result of the current bounce handling implementation, e.g., qda_upd_dsn() assumes that the recipients are in DEFEDB. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... Where4.6
See below: Macros 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... usage4.7
Others use some ``integral'' value of memory over time. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... times5.1
How can it be more than the number of transactions? 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.