sendmail X.0.0.0.0 is available
Claus Aßmann
Hash: SHA1
Sendmail, Inc., and the Sendmail Consortium announce the availability
of sendmail X.0.0.0.0.
sendmail X is a message transfer system that has been designed with
these main topics in minds:
o security
o reliability
o efficiency
o configurability
o extendibility
sendmail X consists of five main modules of which only one runs
as root:
o mcp: the main control program is similar to inetd(8): it starts
all other sendmail X modules and watches over their execution.
mcp runs as root in order to bind to port 25 and to change the
uid of the processes it starts.
o smtps: the SMTP server receives e-mails.
o smtpc: the SMTP client sends e-mails.
o smar: the address resolver provides lookups in various maps including
DNS for mail routing.
o qmgr: the queue manager controls the flow of e-mails through the SMTP
servers and clients.
All of these modules run persistently. smtps and smtpc make use
of the statethreads library which provides a threading API well
suited for Internet applications, smar and qmgr use the POSIX
threads API.
The syntax of the sendmail X configuration file is very simple and
resembles C programs or the BIND 9 configuration files. A configuration
file does not require any special layout, e.g., tabs or one option
per line, but relies on braces and semicolons as structuring elements.
The first release of sendmail X (X.0) is intended to be used as a
secure and efficient mail gateway. It offers features that are not
available in sendmail 8 (or some other open source MTAs), but it
does not provide any mail content modification capabilities, e.g.,
masquerading of addresses or changing (addition, removal) of headers.
Later versions will probably add such capabilities. Moreover, this
version of sendmail X does not come with a mail submission program
nor a local delivery agent. The documentation explains which programs
can be used to perform these tasks and how other features that are
not directly available can be implemented.
sendmail X.0 comes with a policy mail filter library (libpmilter)
which offers similar features as libmilter known from sendmail 8,
however, without mail content modification capabilities (as mentioned
before). Two milter programs have been ported to the pmilter API
and are available in the contrib directory.
All aspects of sendmail X (including installation, configuration,
and operation) are documented in a single README file which is
available in various formats (dvi, HTML, PostScript, PDF, and plain
text) such that the user can select the most appropriate format for
her needs. Additionally, a design document is separately available
for background reading which also covers the implementation and
many other aspects.
The source code distribution and its PGP signature are available at:
ftp://ftp.sendmail.org/pub/sendmail/smX-0.0.0.0.tar.gz
ftp://ftp.sendmail.org/pub/sendmail/smX-0.0.0.0.tar.gz.sig
md5 checksums:
MD5 (smX-0.0.0.0.tar.gz) = 280dc042552dd8221322b1892ffc4fcd
MD5 (smX-0.0.0.0.tar.gz.sig) = 4ce6ccd37afcc00531c3050e99f66033
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (OpenBSD)
iQCVAwUBQ2T49M8etQMiMnoBAQL4UQP7BtJSdXD5HwfPiw1ZJZdY5uRixvseScfo
a7IIFsH3jR/CyPCyijwTYRY34czxz71Mo38dl0MJY4wWJvxECX4wAWIyWWvMv/01
wdScA89XYyLe6vAcSPxdKNNIPZztCC+CrqpLJDQYV6IXCQskRcMQWL904AteDpt5
wjmpeldx9i0=
=/b9i
-----END PGP SIGNATURE-----
--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.
jma...@ttec.com
Perhaps a pointer to a short explanation as to
-- the future of Sendmail 8 development by Sendmail Consortium
-- the migration path from Sendmail 8 to SendmailX
-- Feature differences between SM8 and SMX
And most important
>From the little I understand about Sendmail X the only thing it shares
with Sendmail 8 is the Sendmail name. What else do they have in common?
The Doctor
Add to that, how do 3rd party plugins like milter-spam
and MailScanner work?
--
Member - Liberal International
This is doc...@nl2k.ab.ca Ici doc...@nl2k.ab.ca
God Queen and country! Beware Anti-Christ rising!
Satan uses Republicanism to lead you away from the true path
Claus Aßmann
> -- the future of Sendmail 8 development by Sendmail Consortium
Let's turn this around: what do you expect from sendmail 8
development?
> -- the migration path from Sendmail 8 to SendmailX
Currently: none. You have to read the sendmail X documentation
and figure out whether it has the features that you use/want,
and then "migrate" by hand.
When sendmail X has more features, then we can take a look at
"automagic" migration.
> -- Feature differences between SM8 and SMX
See the fine documentation (the "summary" is in the announcement).
There are too many differences to list here.
> >From the little I understand about Sendmail X the only thing it shares
> with Sendmail 8 is the Sendmail name. What else do they have in common?
o The author/maintainer :-)
o The company that pays that person.
o Some code from libsm has made it into libmta (which was taken
from OpenBSD but has been modified for sendmail X requirements).
Claus Aßmann
> Add to that, how do 3rd party plugins like milter-spam
> and MailScanner work?
See the sendmail X documentation (and contrib/milter*)
Sebastian Jaenicke
* Claus Aßmann <ca+se...@mine.informatik.uni-kiel.de> wrote:
[..]
> Currently: none. You have to read the sendmail X documentation
> and figure out whether it has the features that you use/want,
> and then "migrate" by hand.
> When sendmail X has more features, then we can take a look at
> "automagic" migration.
Is there a list of features that will be implemented for
sendmail X? I've just taken a quick look at the released
version and I'm already missing several things, e.g. rmail
and vacation.
- Sebastian
--
Progress (n.): The process through which Usenet has evolved from
smart people in front of dumb terminals to dumb people in front
of smart terminals.
-- o...@burnout.demon.co.uk
jma...@ttec.com
Your well written answer shows that indeed they are different products
completely.
Therefore it stands to reason that there may possibly never be a
migration path.
As such, I would hope that sendmail 8 continues down the same path it
did with 9,10,11,12,13
New features and fixes, keeping pace with the needs of those who use
it.
I suppose we will have to wait and see what you as the maintainer of
SM8 and the company who pays you decide what level of effort they want
to continue to invest in SM8.
David F. Skoll
> Let's turn this around: what do you expect from sendmail 8
> development?
o Timely security fixes.
o Acceptance of well-written and carefully-thought-out patches from
the community to add new features or enhance existing ones (eg Milter.)
I'm a little worried about the future of (open-source) Sendmail,
because I'm afraid that Sendmail 8 will become orphaned, with all new
development effort going into Sendmail X. Meanwhile, the critical
features I require in Sendmail (basically, Milter :-)) are nowhere
near as complete in smX as sm8.
Regards,
David.
Claus Aßmann
> Is there a list of features that will be implemented for
> sendmail X? I've just taken a quick look at the released
I got a TODO file:
$ wc mta/TODO
10439 55750 403655 mta/TODO
and a design document...
sendmail X is open source, contributions are welcome.
> version and I'm already missing several things, e.g. rmail
> and vacation.
You can use those programs from another source code distribution,
e.g, sendmail 8 or your favorite OS.
Claus Aßmann
> New features and fixes, keeping pace with the needs of those who use
> it.
As long as someone tells sendmail.org about those needs...
(and even better: contributes patches to implement them).
Claus Aßmann
> o Timely security fixes.
Let's hope there aren't any more security problems in sendmail 8.
> o Acceptance of well-written and carefully-thought-out patches from
> the community to add new features or enhance existing ones (eg Milter.)
That shouldn't be a problem (it's always good to tell the maintainer
about any plans first in case he is aware of other efforts in that
area.)
> I'm a little worried about the future of (open-source) Sendmail,
> because I'm afraid that Sendmail 8 will become orphaned, with all new
It will depend on the feedback (and contributions) from the users (more
than before when we had up to 4 full-time engineers working on 8.12).
> development effort going into Sendmail X. Meanwhile, the critical
> features I require in Sendmail (basically, Milter :-)) are nowhere
> near as complete in smX as sm8.
sendmail 8.0 didn't have any milter at all :-)
sendmail X.0 has at least policy milter support (and ships with two
useful pmilters).
jma...@ttec.com
>> Let's turn this around: what do you expect from sendmail 8
>> development?
David F. Skoll wrote:
>o Timely security fixes.
>
>o Acceptance of well-written and carefully-thought-out patches from
> the community to add new features or enhance existing ones (eg Milter.)
Well I wouldnt know about well-written or carefully-thought-out, but
almost none of my patches have warranted much attention even though
they cover a wide range of things.
The fault probably lies with my own efforts but some kind of patch
nurturing is neccessary by those in the know if community involvment is
to be encouraged.
However, some fairly widely used features, greylisting,spf and the like
have been pushed out to the "use a milter" and have not appeared in
sendmail 8 proper.
Recently a patch to milter was posted for thread handling. I know I
have only briefly looked at it in the past. Has anyone else?
libmilter has some rough corners to it, where determing the right thing
to do is hard -- such as the recently discussed milter exiting while
servicing requests, milters that run into perhaps temporary limits (and
as such cannot be safely run with ulimits) and respond by exiting and
by libmilters proccessing of rejected recipients (SMX apparently has
decided on the appropriate course of action for this).
Where can sendmail users go to find sendmail patches other than by
searching through pages of google results?
Claus Aßmann
> Well I wouldnt know about well-written or carefully-thought-out, but
> almost none of my patches have warranted much attention even though
> they cover a wide range of things.
Patches need to be considered "generally useful" by the sendmail
consortium.
> The fault probably lies with my own efforts but some kind of patch
> nurturing is neccessary by those in the know if community involvment is
> to be encouraged.
I often suggest to publish the patch on a website and get feedback.
Only in a few cases people came back later and said that they got
positive feedback.
> However, some fairly widely used features, greylisting,spf and the like
> have been pushed out to the "use a milter" and have not appeared in
> sendmail 8 proper.
spf won't be in sendmail as it is broken by design. "Use a milter"
(please, no discussion about this here; thanks).
If you look at greylisting there are many milters available all of
which behave a bit different (and there's also spamd in OpenBSD). In
smX I implemented only a very simple greylisting mechanism, which I did
mostly because none of the existing milters handled the greylisting DB
in a way that I considered efficient.
milters are a great way to extend sendmail 8's features. Why
do you want to put "everything" in the MTA code itself?
sendmail X is intended to have some kind of "plugin" architecture,
maybe similar to Apache, so it can be extended too.
> Recently a patch to milter was posted for thread handling. I know I
> have only briefly looked at it in the past. Has anyone else?
Which one do you mean? The one by Jose? It's on my TODO list,
but needs some more code review (and testing).
> libmilter has some rough corners to it, where determing the right thing
> to do is hard -- such as the recently discussed milter exiting while
> servicing requests, milters that run into perhaps temporary limits (and
Don't exit, keep on running.
Maybe someone can write up some guidelines how to write a milter
properly such that it doesn't need to be restarted for configuration
changes? Or try to design a way how a milter can be restarted without
causing service interruption?
> as such cannot be safely run with ulimits) and respond by exiting and
What's the purpose of limiting the resources of a milter if you
give unlimited resources to sendmail 8?
> by libmilters proccessing of rejected recipients (SMX apparently has
> decided on the appropriate course of action for this).
There was a lot of discussion about this on the smX design list.
Then someone tried to implement this for sm8 and found out that
it wasn't worth the effort...
> Where can sendmail users go to find sendmail patches other than by
> searching through pages of google results?
Some time ago someone suggested a Wiki but I haven't seen any. If
someone would try to organize a "patch page" which lists existing
patches I'll add a link to the sendmail.org website.
jma...@ttec.com
> jma...@ttec.com wrote:
>
> Patches need to be considered "generally useful" by the sendmail
> consortium.
>
Naturally.
The exact process of defining generally usefull is where things would
tend to break down, leading to your next excellent point.
> I often suggest to publish the patch on a website and get feedback.
> Only in a few cases people came back later and said that they got
> positive feedback.
>
Well all my posted patches on http://www.jmaimon.com/sendmail and I can
count the feedback on one hand....but whether that is due to my own
poor efforts or general disinterest, I cant tell. I have certainly
plugged it often enough here. The only reason I keep at it is because I
have some kind of hypnotic fascination with sendmail.
> spf won't be in sendmail as it is broken by design. "Use a milter"
> (please, no discussion about this here; thanks).
not intending one.
>
> If you look at greylisting there are many milters available all of
> which behave a bit different (and there's also spamd in OpenBSD). In
> smX I implemented only a very simple greylisting mechanism, which I did
> mostly because none of the existing milters handled the greylisting DB
> in a way that I considered efficient.
I would think that a sendmail able to write to a map from rulesets
would be able to handle it all inline and fairly efficiently.
>
> milters are a great way to extend sendmail 8's features. Why
> do you want to put "everything" in the MTA code itself?
Not everything, just things that make sense as a kind of enabler, an
extension of services available to all, stuff that fits neatly in
place, operations where logic and efficiency suggest it belongs in the
MTA etc... And of course, all libmilter and sendmail/milter.c
improvements.
>
> > libmilter has some rough corners to it, where determing the right thing
> > to do is hard -- such as the recently discussed milter exiting while
> > servicing requests, milters that run into perhaps temporary limits (and
>
> Don't exit, keep on running.
Not if say they cant allocate memory for 5 seconds while receiving 15
connections.
But if the milter is leaky and is being watched by some script, than it
should be exiting.....like all others, this should be a milter command
line option, that drives a flag to libmilter.
>
> Maybe someone can write up some guidelines how to write a milter
> properly such that it doesn't need to be restarted for configuration
> changes? Or try to design a way how a milter can be restarted without
> causing service interruption?
You dont actually mean this?
Well perhaps libmilter could be extended to pass information to a
"configuration" callback.
POSIX environments should allow a new milter to be started merely by
deleting the old unix socket or by otherwise causing the existing
milter to cease accepting new connections on its socket, while existing
connections proceeded normally.
however I suspect sysv-init scripts may not be happy with non
terminating daemons as they try to restart a milter.
>
> > as such cannot be safely run with ulimits) and respond by exiting and
>
> What's the purpose of limiting the resources of a milter if you
> give unlimited resources to sendmail 8?
Whose to say sendmail 8 is unlimited?
They run on different hosts? pthread programs have different problems
they may cause to machines? They (think spam and virus filters)
potentialy utilize a much larger resource set? They have a much higher
probability of bugs including memory leaks (see clamav-milter devel
history for an example among many)?
>
> > by libmilters proccessing of rejected recipients (SMX apparently has
> > decided on the appropriate course of action for this).
>
> There was a lot of discussion about this on the smX design list.
> Then someone tried to implement this for sm8 and found out that
> it wasn't worth the effort...
My (un-feedbacked) patch does it. And it wasnt easy for me, dancing
around all that code. But then I am an amatuer. And I found it worth
the effort for the other features in the patch.
>
> > Where can sendmail users go to find sendmail patches other than by
> > searching through pages of google results?
>
> Some time ago someone suggested a Wiki but I haven't seen any. If
> someone would try to organize a "patch page" which lists existing
> patches I'll add a link to the sendmail.org website.
>
Well if anyone wants to organize a patch page, to help trap the unwary,
put a link to http://www.jmaimon.com/sendmail
(managed to squeeze in another plug [we all do things we regret when we
get older])
But something to the effect of a savannah patch interface, with
feedback, tracking updates would probably fit the bill. I wouldnt know
where to start with that.
Claus Aßmann
> Well all my posted patches on http://www.jmaimon.com/sendmail and I can
Added to other-sendmail-links.html
> count the feedback on one hand....but whether that is due to my own
> poor efforts or general disinterest, I cant tell. I have certainly
Welcome to open source development :-(
[greylisting]
> I would think that a sendmail able to write to a map from rulesets
> would be able to handle it all inline and fairly efficiently.
What about expiring entries?
> Not if say they cant allocate memory for 5 seconds while receiving 15
> connections.
That's why you want to limit the number of connection and hence
the resource usage via sendmail.
> But if the milter is leaky and is being watched by some script, than it
Fix the milter, don't hack around the problem.
> > Maybe someone can write up some guidelines how to write a milter
> > properly such that it doesn't need to be restarted for configuration
> > changes? Or try to design a way how a milter can be restarted without
> > causing service interruption?
>
> You dont actually mean this?
I do. What's wrong with it? milter-regex checks the configuration
file during execution and reloads it when it has been changed.
> Well perhaps libmilter could be extended to pass information to a
> "configuration" callback.
Do you mean "reload configuration"? That could be done via a signal.
> POSIX environments should allow a new milter to be started merely by
> deleting the old unix socket or by otherwise causing the existing
> milter to cease accepting new connections on its socket, while existing
> connections proceeded normally.
Now this needs to be written down properly and then implemented :-)
One problem is that this works for AF_UNIX, but not AF_INET*.
> > What's the purpose of limiting the resources of a milter if you
> > give unlimited resources to sendmail 8?
> Whose to say sendmail 8 is unlimited?
If you limit the number of connection in the MTA, you automagically
limit the number of threads (sessions) in the milter.
What you need in addition is some kind of feedback mechanism from
the milter to the MTA (like smX has for resource problems in qmgr).
[giving information about unknown recipients to milter]
> My (un-feedbacked) patch does it. And it wasnt easy for me, dancing
> around all that code. But then I am an amatuer. And I found it worth
> the effort for the other features in the patch.
That's why I am reluctant to make those changes. There haven't been
enough requests to justify the effort.
Ok, here's some background information: sendmail 8 has almost no
regression tests. Hence whenever something is changed it takes
a lot of time to "make sure" that it doesn't break something.
As you noticed when you looked at the code this is far from trivial
due to the way "exceptions" are handled, i.e., this isn't just
"flow through" code, but it may "suddenly" jump somewhere else.
AFAIR you had to change your patch at least once as it caused
some unintended side effects.
I spent a lot of time to make sure that sendmail X has code that is
better to maintain and that has lots of regression tests (currently
something like one third of the distribution contains tests).
> But something to the effect of a savannah patch interface, with
> feedback, tracking updates would probably fit the bill. I wouldnt know
> where to start with that.
Maybe someone else can help?
jma...@ttec.com
> Added to other-sendmail-links.html
Thanks
>
> [greylisting]
> > I would think that a sendmail able to write to a map from rulesets
> > would be able to handle it all inline and fairly efficiently.
>
> What about expiring entries?
If its an external map, a cron job would do that.
Or how is expiring host statistics handled?
[libmilter behavior when (temporarily) out of resources]
>
> > Not if say they cant allocate memory for 5 seconds while receiving 15
> > connections.
>
> That's why you want to limit the number of connection and hence
> the resource usage via sendmail.
Being able to limit the input into libmilter from a sendmail doesnt
have to mean that libmilter gets a free pass on coming to a good
compromise between robustness and resource utilization.
Especialy since the rate of connections and the content of the
connections are much more sensitive to libmilter, along with the
possible multiplexing of sendmails into single libmilter hosts makes
managing it via sendmail connections a heavy handed approach.
Additionaly, with my patch, a sendmail can possibly only selectively be
calling into milters. So limiting sendmail connections does not
translate directly, and the problem becomes that sendmail is
unnessecarily bounded by libmilter.
I think libmilters behavior should hinge on the desired outcome from
out of resources conditions, something that should be flagged in the
milter.
Does the milter want to be terminated when "pervasive" out of resources
detected?
Or does it want to simply refuse new connections until something clears
up.
I only brought this up to highlight certain areas that the right thing
to do is a tough call for libmilter.
>
> > But if the milter is leaky and is being watched by some script, than it
>
> Fix the milter, don't hack around the problem.
For a sendmail and libmilter admin, not neccessarily a milter
developer, the choices arent always that clear.
>
[on restarting milters]
>
> I do. What's wrong with it? milter-regex checks the configuration
> file during execution and reloads it when it has been changed.
Milter design is complicated by the fact that libmilter based programs
were perceived to have a low barrier of complexity. So most of them
behave like simple command line argument c programs.
Many who deserve notable mention dont do that. But most started out
life ignoring such niceties.
But they are daemons and all the niceties one expects from daemons
could/should be expected from a nicely produced milter.
>
> > Well perhaps libmilter could be extended to pass information to a
> > "configuration" callback.
>
> Do you mean "reload configuration"? That could be done via a signal.
>
I was under the impression you were referring to libmilter design. In
that case a libmilter command enabling the milter designer to move his
getopt() calls to a callback, while protecting configuration changes
from running connections threads would keep the milter design simple,
and push the complexity into libmilter, which already hides most of it.
> > POSIX environments should allow a new milter to be started merely by
> > deleting the old unix socket or by otherwise causing the existing
> > milter to cease accepting new connections on its socket, while existing
> > connections proceeded normally.
>
> Now this needs to be written down properly and then implemented :-)
> One problem is that this works for AF_UNIX, but not AF_INET*.
AF_INET doesnt allowing the closing of a listen socket without
disrupting already accept()ed connections?
Sendmail itself lets you terminate the listening daemon while
connections are still processing.
[resource limiting]
>
> If you limit the number of connection in the MTA, you automagically
> limit the number of threads (sessions) in the milter.
>
That does not neccessarily help you limit the memory utilization of
those threads. For example, spam and virus scanners can be very much
message content specific.
Also this assumes a one to one relationship between sendmail proccesses
and libmilter threads. Changing that assumption is going to lessen the
effectiveness or desirability of limiting libmilter by limiting
sendmail connections.
The previous mentioned thread handling patch may do just that. Allowing
milter calls to be controlled by rulesets also breaks that scheme.
> What you need in addition is some kind of feedback mechanism from
> the milter to the MTA (like smX has for resource problems in qmgr).
There is one already, its called temp failure. At that point sendmail
milter configuration decides whether to accept anyways or reject or
temp reject the connection. What else can it do? Delay connections for
a reasonable time?
That should be libmilters responsibility.
>
> [giving information about unknown recipients to milter]
>
>
> That's why I am reluctant to make those changes. There haven't been
> enough requests to justify the effort.
And it so happens that that feature is the only one unguarded by _FFR
macros.
So my patch WILL change sendmails internal code path without turning on
anything else.
I understand that it would cause only those who decided that they
couldnt live with receiving bogus rcpts in a milter to use such a
patch.
However, worksforme and I couldnt see any other way at the time.
>
> Ok, here's some background information: sendmail 8 has almost no
> regression tests. Hence whenever something is changed it takes
> a lot of time to "make sure" that it doesn't break something.
Thought it was only me.....
> As you noticed when you looked at the code this is far from trivial
> due to the way "exceptions" are handled, i.e., this isn't just
> "flow through" code, but it may "suddenly" jump somewhere else.
> AFAIR you had to change your patch at least once as it caused
> some unintended side effects.
>
Yep more than once. The last update to it was February 28, 2005.
The only sane way I found to deal with it is with goto statements and
state flagging variables, which may be a barrier enough to its
acceptance.
But then again I have never held the opinion that I held any degree of
skill in my coding attempts.
Anyways, my orginal concern, that Sendmail 8 would stagnate before
everybody (read:me) was ready to migrate to Sendmail X appears to have
been addressed. I can sleep at night now.
Thank you for that and thank you for your kind attention.
gjunk...@sapience.com
How, if at all, does domain keys fit in with sm-X? And is it
also broken?
thanks/
g/
Claus Aßmann
> > spf is broken ..
> How, if at all, does domain keys fit in with sm-X? And is it
It is currently not supported as it requires content modification.
smX.0 is a "pure" MTA as specified by RFC 2821.
> also broken?
Not by design.
@sama.ru Sergey
> Sendmail, Inc., and the Sendmail Consortium announce the availability
> of sendmail X.0.0.0.0.
Some problem
1. In documentation:
CDB_gid: (numeric) group id for CDB, i.e., the group id of smxq, see
Section 2.4.1.
This is not good (numeric only) for installation via package manager:
group id can be not fixed.
2. Some mail prigramms (for example mailx, fetchmail) needed of sendmail
binary for operations. Some MTA provide sendmail warper for it, but
I have not found analogue in SendmailX package. :-(
--
Regards, Sergey
@sama.ru Sergey
> Sendmail, Inc., and the Sendmail Consortium announce the availability
> of sendmail X.0.0.0.0.
Have you the palan of registration of SENDMAIL OPEN SOURCE LICENSE on
http://www.opensource.org/licenses/ ?
--
Regards, Sergey
@sama.ru Sergey
>> Sendmail, Inc., and the Sendmail Consortium announce the availability
>> of sendmail X.0.0.0.0.
>
> Some problem
>
> 1. In documentation:
>
> CDB_gid: (numeric) group id for CDB, i.e., the group id of smxq, see
> Section 2.4.1.
...and. smxq or smxc ? In sm.setup.sh:
CDB_gid = ${SMXCGID};
--
Regards, Sergey
Claus Aßmann
> Have you the palan of registration of SENDMAIL OPEN SOURCE LICENSE on
> http://www.opensource.org/licenses/ ?
Why? What would sendmail gain from that?
I looked at it and found that it requires a lawyer for some legal
review. It doesn't seem to be worth the money.
Claus Aßmann
> CDB_gid: (numeric) group id for CDB, i.e., the group id of smxq, see
> Section 2.4.1.
> This is not good (numeric only) for installation via package manager:
> group id can be not fixed.
Send a patch :-)
The best way is to create a new type for libconf that can read
gids and translates them into the numeric id.
> 2. Some mail prigramms (for example mailx, fetchmail) needed of sendmail
> binary for operations. Some MTA provide sendmail warper for it, but
> I have not found analogue in SendmailX package. :-(
Do you mean a "message submision program" (command line mail
submission)? That's explained in the announcement and in the docs.
@sama.ru Sergey
> Why? What would sendmail gain from that?
I have asked only for the information. :-)
--
Regards, Sergey
@sama.ru Sergey
>> This is not good (numeric only) for installation via package manager:
>> group id can be not fixed.
>
> Send a patch :-)
> The best way is to create a new type for libconf that can read
> gids and translates them into the numeric id.
I not the programmer, unfortunately. But maybe my knowledge "C" will
suffice. I shall try, if anybody will not outstrip me.
:-)
--
Regards, Sergey
Claus Aßmann
> > 1. In documentation:
> > CDB_gid: (numeric) group id for CDB, i.e., the group id of smxq, see
> > Section 2.4.1.
> ...and. smxq or smxc ? In sm.setup.sh:
smxc, it's a typo in the documentation. Thanks for pointing it out!
@sama.ru Sergey
>> 2. Some mail prigramms (for example mailx, fetchmail) needed of sendmail
>> binary for operations. Some MTA provide sendmail warper for it, but
>> I have not found analogue in SendmailX package. :-(
>
> Do you mean a "message submision program" (command line mail
> submission)? That's explained in the announcement and in the docs.
Ok, I created sendmail-submit package from sendmail V8.
Thanks.
--
Regards, Sergey
Claus Aßmann
[expiring entries in a map, e.g., for greylisting]
> If its an external map, a cron job would do that.
Bad Idea(tm)
1. The requires inter-process locking.
2. While the database is locked by the "expire" process, the "main"
process can't update it: this can cause significant delays (unless
record locking is available and the "cursor" operation is "safe"
against DB modification by another process).
I ran into this problem several times and found different "solutions"
all of which have some kind of problem:
1. make the expiration part of the main process and have some thread
periodically expire entries. That task will look only at a few entries
at a time to minimize interruption. Problem: it needs to "walk" through
all entries to find those which need to be expired. It is complicated
to "remember" where the task last stopped ("round robin") because that
element might be updated/removed by some other task.
2. maintain a secondary index which sorts the entries by expiration
time. Now an "expire" task just needs to look at the oldest entries and
remove some of them. The only problem here is to maintain a secondary
index. Berkeley DB can do it "automagically". This approach is used in
smX for greylisting (hey, maybe I should patent that!).
This is a real big problem in multi-threaded programs where one task is
working on a list while a cleanup task comes along. If you want to
allow concurrent access to the list, the locking becomes non-trivial.
PS: the hoststatus "DB" in sendmail 8 is a hack that uses the
filesystem as DB, i.e., the filenames are the key. Expiration
is ugly (see sendmail/mci.c: mci_traverse_persistent()) but
it uses "record" locking, so there is barely any interruption.
David F. Skoll
[Regarding expiring database entries on a production system]
> I ran into this problem several times and found different "solutions"
> all of which have some kind of problem:
We solved it by using a real database (PostgreSQL, in our case) that
automatically handles concurrency issues in a very efficient way.
I realize this is quite heavy-weight, and isn't practical unless you're
already doing some other heavy-weight processing.
Regards,
David.
Jose Marcio Martins da Cruz
> Claus A?mann wrote:
>
>
> 2. Some mail prigramms (for example mailx, fetchmail) needed of sendmail
> binary for operations. Some MTA provide sendmail warper for it, but
> I have not found analogue in SendmailX package. :-(
As explained in section 4.2, you shall use another program to submit messages.
One way is to use the submission part of sendmail 8.
Another one is to use mini_sendmail or nbsmtp (no brain smtp), and rename them
as sendmail in order to allow programs having the sendmail path hardcoded to
work. Configure these programs to connect to localhost:25 (or something like that).
The better solution is to use the submission part of sendmail 8, as it handles
an outgoing queue, if smX was stopped for some reason.
Jose Marcio Martins da Cruz
Hello,
Claus Aßmann wrote:
> jma...@ttec.com wrote:
>>Recently a patch to milter was posted for thread handling. I know I
>>have only briefly looked at it in the past. Has anyone else?
>
> Which one do you mean? The one by Jose ? It's on my TODO list,
> but needs some more code review (and testing).
It's hard to have feedback... This year, it was downloaded 895 times this year,
from 218 different sources.
It's being used at our domain since the first release (a small server 100K
messages a day). The other significant feedback I have is pobox.sk, which uses
it since August 2004, without problems - their server handles between 20K and
40K messages an hour (connections rejected before DATA command not included in
the measure).
The big gain is on Linux machines - this patch drastically slow down memory
consumption by the filter on this OS.
While it's in your TODO list, maybe you can add a pointer to it at sendmail.org
server... http://j-chkmail.ensmp.fr/libmilter
Jose-Marcio
@sama.ru Sergey
> The better solution is to use the submission part of sendmail 8, as it handles
> an outgoing queue, if smX was stopped for some reason.
news:dko2js$2933$1...@berg.samara.net
:-)
--
Regards, Sergey
John Nemeth
: jma...@ttec.com wrote:
: [giving information about unknown recipients to milter]
: > My (un-feedbacked) patch does it. And it wasnt easy for me, dancing
: > around all that code. But then I am an amatuer. And I found it worth
: > the effort for the other features in the patch.
: That's why I am reluctant to make those changes. There haven't been
: enough requests to justify the effort.
I would like to see something. I made a quick and dirty hack,
which basically moves the milter recipient check to after the localuser
check. Without it, my system quickly gets overwhelmed dealing with
bogus messages. I would certainly be interested in seeing other (and
hopefully) better ways of doing the same thing.
I know that isn't suitable as a general patch since some milters
want to see all recipients. David Skoll suggesting setting the mailer
to #error for invalid recipients before passing them to milters. I
have thought about doing something like this, but haven't had to time
to work on it.
jma...@ttec.com
milter with a mailer set to #error thanks to DF Skoll's suggestion.
It also deals with the likely problem you may face if you move the
milter portion to below the sendmail recipient handling -- a rejection
of one recipient may not take effect.
I ran into this for V9 of milter-rrres (currently at V12 or V13)
http://www.jmaimon.com/sendmail/patches/milter-rrres.Changes.v9.txt
Much more interesting would be to make #error configurable on a per
milter basis.