http://www.netbsd.org/docs/guide/en/chap-mail.html
Note:
Since NetBSD 4.0, postfix is the default MTA (Mail Transport Agent)
and sendmail was removed.
--
[pl>en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
On Dec 20, 12:46 am, Andrzej Adam Filip
> http://www.netbsd.org/docs/guide/en/chap-mail.html
>
> Note:
> Since NetBSD 4.0, postfix is the default MTA (Mail Transport Agent)
> and sendmail was removed.
>
NetBSD does not represent much of a percentage in usage out there....
No big loss. Too bad though. I used to recommend NetBSD over all other
free BSDs available as a viable alternative in some installations due
to
its wonderful cross platform portability. Now maybe not so...
At least sendmail is in the ports section
I am curious about how this decision was reached and why the core team
approved this little gem of an idea.
I recognise only one name in the core team now.
Are they are on a path of obscurity to nowhere?? : >
I am surprised that anyone is still using NetBSD.
That said, I have administered sendmail for about 11 years, and had a
large amount of hard to diagnose frustrations over the years. I am not
qualified to say that postfix is better.
For new computers that are not mail servers, I use debian and exim4.
i
usenetpersongerryt@gmail.com writes:
> On Dec 20, 12:46 am, Andrzej Adam Filip
>> http://www.netbsd.org/docs/guide/en/chap-mail.html
>>
>> Note:
>> Since NetBSD 4.0, postfix is the default MTA (Mail Transport Agent)
>> and sendmail was removed.
>>
>
> NetBSD does not represent much of a percentage in usage out there....
NetBSD *alone* may be not too important but do not try to pretend that
it is not YASD (Yet Another Similar Decision) in a pretty long string
of similar moves.
> No big loss. Too bad though. I used to recommend NetBSD over all other
> free BSDs available as a viable alternative in some installations due
> to its wonderful cross platform portability. Now maybe not so...
> At least sendmail is in the ports section
>
> I am curious about how this decision was reached and why the core team
> approved this little gem of an idea.
> I recognise only one name in the core team now.
> Are they are on a path of obscurity to nowhere?? : >
IF you pretend that there is no problem (long trend of pting-out from
sendmail use or sendmail as default MTA) THEN you pretend that there is
nothing to fix.
--
[pl>en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
Ignoramus31412
> I am surprised that anyone is still using NetBSD.
>
> That said, I have administered sendmail for about 11 years, and had a
> large amount of hard to diagnose frustrations over the years. I am not
> qualified to say that postfix is better.
>
> For new computers that are not mail servers, I use debian and exim4.
Who are you? Anonymous opinions count less (usually).
--
[pl>en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
On 2007-12-20, Andrzej Adam Filip
> Ignoramus31412
>
>> I am surprised that anyone is still using NetBSD.
>>
>> That said, I have administered sendmail for about 11 years, and had a
>> large amount of hard to diagnose frustrations over the years. I am not
>> qualified to say that postfix is better.
>>
>> For new computers that are not mail servers, I use debian and exim4.
>
> Who are you? Anonymous opinions count less (usually).
>
What do you want, my name?
i
usenetpersongerryt@gmail.com wrote:
: On Dec 20, 12:46 am, Andrzej Adam Filip
: > http://www.netbsd.org/docs/guide/en/chap-mail.html
: >
: > Note:
: > Since NetBSD 4.0, postfix is the default MTA (Mail Transport Agent)
: > and sendmail was removed.
: >
: NetBSD does not represent much of a percentage in usage out there....
: No big loss. Too bad though. I used to recommend NetBSD over all other
: free BSDs available as a viable alternative in some installations due
: to
: its wonderful cross platform portability. Now maybe not so...
: At least sendmail is in the ports section
Where it is always up to date and has more options (i.e. STARTTLS,
SASL, LDAP, etc).
Just a nitpick... In NetBSD nomenclature a "port" is support for
a particular architechure (i.e. i386, amd64, macppc, sparc64, etc).
The packaging system is called "pkgsrc". Of note, is that pkgsrc
supports multiple platforms including, NetBSD, Linux, Interix
(Microsoft Services for Unix), Solaris, etc. In this way, modern
sendmail is brought to a number of platforms that may not otherwise
have a current version of sendmail available.
: Are they are on a path of obscurity to nowhere?? : >
Keep your eyes open, there's a lot of great stuff happening in
NetBSD.
In article <476ae895$1@news.victoria.tc.ca>,
jnemeth@vtn1.victoria.tc.ca (John Nemeth) writes:
> usenetpersongerryt@gmail.com wrote:
>: On Dec 20, 12:46 am, Andrzej Adam Filip
>: > http://www.netbsd.org/docs/guide/en/chap-mail.html
>: >
>: > Note:
>: > Since NetBSD 4.0, postfix is the default MTA (Mail Transport Agent)
>: > and sendmail was removed.
>: >
>
>: NetBSD does not represent much of a percentage in usage out there....
>: No big loss. Too bad though. I used to recommend NetBSD over all other
>: free BSDs available as a viable alternative in some installations due
>: to
>: its wonderful cross platform portability. Now maybe not so...
>: At least sendmail is in the ports section
>
> Where it is always up to date and has more options (i.e. STARTTLS,
> SASL, LDAP, etc).
>
> Just a nitpick... In NetBSD nomenclature a "port" is support for
> a particular architechure (i.e. i386, amd64, macppc, sparc64, etc).
> The packaging system is called "pkgsrc". Of note, is that pkgsrc
> supports multiple platforms including, NetBSD, Linux, Interix
> (Microsoft Services for Unix), Solaris, etc. In this way, modern
> sendmail is brought to a number of platforms that may not otherwise
> have a current version of sendmail available.
>
>: Are they are on a path of obscurity to nowhere?? : >
>
> Keep your eyes open, there's a lot of great stuff happening in
> NetBSD.
As Mark Twain (Samuel Clemens) said on reading his own
obituary, "The reports of my death are greatly exaggerated."
This strikes me as typical FUD from a member of that segment
of the community that knows nothing about the BSDs. Pity.
Bob Melson
--
Robert G. Melson | Rio Grande MicroSolutions | El Paso, Texas
-----
Thinking is the hardest work there is, which is the probable
reason so few engage in it. -- Henry Ford
On 2007-12-20, Ignoramus31412
> I am surprised that anyone is still using NetBSD.
>
> That said, I have administered sendmail for about 11 years, and had a
> large amount of hard to diagnose frustrations over the years. I am not
> qualified to say that postfix is better.
>
> For new computers that are not mail servers, I use debian and exim4.
I use FreeBSD, NetBSD, and linux. FreeBSD runs the mail server
(sendmail) and apache, NetBSD runs a tor client for my network, and
linux on the desktop and a tor exit node.
--
John (john@os2.dhs.org)
On Dec 20, 2:11 pm, jnem...@vtn1.victoria.tc.ca (John Nemeth) wrote:
> usenetpersonger...@gmail.com wrote:
> : On Dec 20, 12:46 am, Andrzej Adam Filip
> : >http://www.netbsd.org/docs/guide/en/chap-mail.html
> : >
> : > Note:
> : > Since NetBSD 4.0, postfix is the default MTA (Mail Transport Agent)
> : > and sendmail was removed.
> : >
> : NetBSD does not represent much of a percentage in usage out there....
> : No big loss. Too bad though. I used to recommend NetBSD over all other
> : free BSDs available as a viable alternative in some installations due
> : to
> : its wonderful cross platform portability. Now maybe not so...
> : At least sendmail is in the ports section
> Where it is always up to date and has more options (i.e. STARTTLS,
> SASL, LDAP, etc).
I thought maybe this was the case.
Not familiar with postfix so I didnt FUD anything : >
> Just a nitpick... In NetBSD nomenclature a "port" is support for
> a particular architechure (i.e. i386, amd64, macppc, sparc64, etc).
> The packaging system is called "pkgsrc". Of note, is that pkgsrc
> supports multiple platforms including, NetBSD, Linux, Interix
> (Microsoft Services for Unix), Solaris, etc. In this way, modern
> sendmail is brought to a number of platforms that may not otherwise
> have a current version of sendmail available.
yes
> : Are they are on a path of obscurity to nowhere?? : >
> Keep your eyes open, there's a lot of great stuff happening in
> NetBSD.
I try to keep them open : >
I still like NetBSD for reasons Ive already stated but it seems weird
to
"remove" sendmail. Especially sendmail, as it's been a core app from
the beginning of BSD days.
I'll drop in what Andrei says here and comment:
>NetBSD *alone* may be not too important but do not try to pretend that
>it is not YASD (Yet Another Similar Decision) in a pretty long string
>of similar moves.
You dont have to tell a person whose thing is Sun/Solaris/SPARC THAT.
One could get the impression that sendmail itself is getting a bit
stale.
First we had Sendmail X and then Herr Claus moved over to something
else.
Patches for 8.14 yes but momentum seems to be drifting a bit?
People goto postfix because ... the perception is its "easier" to
configure?
Or is it just that to run sendmail competently you might actually have
to know
something about your JOB..??
[appalling article formatting fixed]
In article
<48b65bee-0e26-4a64-b535-3b587c964c72@e6g2000prf.googlegroups.com>,
usenetpersongerryt@gmail.com wrote:
> People goto postfix because ... the perception is its "easier" to
> configure?
As someone who uses both Postfix and Sendmail, I think that is not
purely perception. More important than the "easiness" is the clarity of
the configuration of a system. If you work with Sendmail all the time
and have done so for a long time, the quirks don't feel so quirky, but
if you are not so experienced with Sendmail specifically and/or are not
continuously immersed in working with it, the nature of the
configuration makes it hard to just read the files and understand.
Postfix's configuration is substantially more accessible and
comprehensible for the general admin whose work with email is almost
entirely maintenance of a generally functional system. A large fraction
of people managing Sendmail systems are cargo-cultists who don't really
understand their configs, they just know the rituals of tweaking a .mc
with whatever they can find here or on some web page and running Build.
Postfix
> Or is it just that to run sendmail competently you might
> actually have to know something about your JOB..??
The same is true of non-trivial Postfix systems, because any mail system
has to map the complexity of what people want their mail system to do
onto the non-obvious details of how that can be implemented with
Internet email.
A significant issue in this general realm is that for the majority of
modern Unix(ish) systems, the local MTA really isn't supposed to be
doing anything terribly complex in concept and does not need any changes
for very long periods, so is likely to be maintained by a person or team
that mostly just relies on the MTA doing the right thing until the rare
event requires some small change. For the admin whose main job is more
about a half-dozen other arcane areas than it is about email, Postfix
provides an alternative that is less likely to require a day of research
to make small changes to.
More generally, Postfix has some objective advantages over Sendmail in
the area of modular design with the resulting security advantage and in
the support of facilities like kqueue, epoll and /dev/poll (on systems
that do them well) that make it feasible to handle huge numbers of
concurrent connections. It has become very hard to make an argument for
Sendmail on any basis other than "It's what I know" and that's pretty
weak.
--
Now where did I hide that website...
Bill Cole wrote:
> More generally, Postfix has some objective advantages over Sendmail in
> the area of modular design with the resulting security advantage and in
> the support of facilities like kqueue, epoll and /dev/poll (on systems
> that do them well) that make it feasible to handle huge numbers of
> concurrent connections. It has become very hard to make an argument for
> Sendmail on any basis other than "It's what I know" and that's pretty
> weak.
We sell a commercial anti-spam system implemented as a milter, and we
have had pushback for being tied to Sendmail. Some large customers and
potential customers grumble about the need to have a Sendmail relay, and
typically they propose Postfix as the alternative. Postfix now fully
supports milter, so at some point we will look at integrating with it.
One of the big problems is the lack of direction from the Sendmail
developers. On the one hand, I can understand the reluctance to provide
a roadmap because roadmaps are typically guessed at to appease PHBs and then
developers find themselves constrained by the roadmap and can't react quickly
to changing circumstances.
On the other hand, having at least some inkling of the future direction
of Sendmail would be nice. Is Sendmail 8.x going to continue to be
developed? What's the official status of MeTA1? Will there be an
upgrade path from Sendmail 8 to MeTA1?
http://www.sendmail.org/news/ is stale by more than a year.
http://www.sendmail.com/ is just an ad that (incorrectly) claims
to be the "first" appliance to filter both inbound and outbound mail.
(There are supposed to be navigation menus on that page, I guess,
but they do not render in Firefox.)
Regards,
David.
"David F. Skoll"
> [...]
> We sell a commercial anti-spam system implemented as a milter, and we
> have had pushback for being tied to Sendmail. Some large customers
> and potential customers grumble about the need to have a Sendmail
> relay, and typically they propose Postfix as the alternative. Postfix
> now fully supports milter, so at some point we will look at
> integrating with it.
Have you heard about any *serious* attempt to provide core functionality
provided by milter protocol via *open* protocol? [e.g. LMTP based]
[AFAIK Milter *protocol* (not API) has never been documented by sendmail.org ]
> [...]
--
[pl>en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
Live within your income, even if you have to borrow to do so.
-- Josh Billings
Andrzej Adam Filip wrote:
> Have you heard about any *serious* attempt to provide core functionality
> provided by milter protocol via *open* protocol? [e.g. LMTP based]
No, not really. Postfix does have an open SMTP-based filtering
protocol, but it's not as full-featured or flexible as Milter.
> [AFAIK Milter *protocol* (not API) has never been documented by
> [sendmail.org ]
Correct, and it's theoretically an internal API subject to change.
However, it's stable enough that the Postfix author(s) felt comfortable
reverse-engineering it and implementing the MTA side of milter.
Samba has succeeded quite nicely in implementing undocumented and
ever-shifting protocols; Milter is at least two orders of magnitude
simpler to reverse-engineer and support.
Regards,
David.
In article <983a4$476d3206$d1d97a75$4156@PRIMUS.CA>,
"David F. Skoll"
> Bill Cole wrote:
>
> > More generally, Postfix has some objective advantages over Sendmail in
> > the area of modular design with the resulting security advantage and in
> > the support of facilities like kqueue, epoll and /dev/poll (on systems
> > that do them well) that make it feasible to handle huge numbers of
> > concurrent connections. It has become very hard to make an argument for
> > Sendmail on any basis other than "It's what I know" and that's pretty
> > weak.
>
> We sell a commercial anti-spam system implemented as a milter, and we
> have had pushback for being tied to Sendmail. Some large customers and
> potential customers grumble about the need to have a Sendmail relay, and
> typically they propose Postfix as the alternative. Postfix now fully
> supports milter, so at some point we will look at integrating with it.
FWIW, I've been running a small Postfix system with MIMEDefang for 4
months and haven't run into any significant problems. If the commercial
product isn't too far from MD, you may not have much work to do...
You also might want to look at Dr. Venema's latest post on this to the
Postfix Users list. He discusses the gaps between his 'version 6' milter
implementation and the latest Sendmail implementation, complete with
reasons why some gaps are likely to never be closed.
> One of the big problems is the lack of direction from the Sendmail
> developers. On the one hand, I can understand the reluctance to provide
> a roadmap because roadmaps are typically guessed at to appease PHBs and then
> developers find themselves constrained by the roadmap and can't react quickly
> to changing circumstances.
>
> On the other hand, having at least some inkling of the future direction
> of Sendmail would be nice. Is Sendmail 8.x going to continue to be
> developed? What's the official status of MeTA1? Will there be an
> upgrade path from Sendmail 8 to MeTA1?
>
> http://www.sendmail.org/news/ is stale by more than a year.
> http://www.sendmail.com/ is just an ad that (incorrectly) claims
> to be the "first" appliance to filter both inbound and outbound mail.
> (There are supposed to be navigation menus on that page, I guess,
> but they do not render in Firefox.)
I can't discuss Sendmail Inc. without coming across cattier than they
deserve. It's an exasperating situation.
--
Now where did I hide that website...
In article <242b$476d4072$d1d97a75$20187@PRIMUS.CA>,
"David F. Skoll"
> Andrzej Adam Filip wrote:
>
> > Have you heard about any *serious* attempt to provide core functionality
> > provided by milter protocol via *open* protocol? [e.g. LMTP based]
>
> No, not really. Postfix does have an open SMTP-based filtering
> protocol, but it's not as full-featured or flexible as Milter.
>
> > [AFAIK Milter *protocol* (not API) has never been documented by
> > [sendmail.org ]
>
> Correct, and it's theoretically an internal API subject to change.
> However, it's stable enough that the Postfix author(s) felt comfortable
> reverse-engineering it and implementing the MTA side of milter.
>
> Samba has succeeded quite nicely in implementing undocumented and
> ever-shifting protocols; Milter is at least two orders of magnitude
> simpler to reverse-engineer and support.
Or better...
After all, Samba has a reference implementation which it has to match
that can only be examined as a black box, while anyone trying to
replicate Milter has BSD-licensed source code for the reference
implementation.
The problem there is apparently that some of Milter requires an MTA
design better suited to the last century. MeTAl and Postfix have had
similar gaps in their implementations, and while I have not dug deep
into the code to get a direct understanding of the details, I trust Dr.
Venema's descriptions of the challenges.
--
Now where did I hide that website...
David F. Skoll wrote:
> On the other hand, having at least some inkling of the future direction
> of Sendmail would be nice.
[line breaks added to make it simpler to insert answers]
> Is Sendmail 8.x going to continue to be developed?
Yes. However, it should be obvious to everyone that there
is no need for any major changes (ESMTP isn't changing,
almost all extensions can be done via milters.) All open
source MTAs basically "simply work", so everyone can choose
an MTA based on her/his personal preferences.
> What's the official status of MeTA1?
MeTA1 is NOT a Sendmail Consortium project. MeTA1 is under
development, and the website is updated whenever a new
version is released.
> Will there be an upgrade path from Sendmail 8 to MeTA1?
If someone writes the code... (it won't be me; I consider
other parts more interesting so I'm working on those as
MeTA1 is something I do in my spare time).
Claus AÃmann
> David F. Skoll wrote:
>
>> On the other hand, having at least some inkling of the future direction
>> of Sendmail would be nice.
>
> [line breaks added to make it simpler to insert answers]
>> Is Sendmail 8.x going to continue to be developed?
>
> Yes. However, it should be obvious to everyone that there
> is no need for any major changes (ESMTP isn't changing,
> almost all extensions can be done via milters.) All open
> source MTAs basically "simply work", so everyone can choose
> an MTA based on her/his personal preferences.
ESMTP does not change but spam fighting changes requirements for
"bleeding edge" MTA.
>> What's the official status of MeTA1?
> [...]
--
[pl>en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
NOWPRINT. NOWPRINT. Clemclone, back to the shadows again.
-- The Firesign Theater
Post removed (X-No-Archive: yes)
Post removed (X-No-Archive: yes)
Claus Aßmann wrote:
>> Is Sendmail 8.x going to continue to be developed?
> Yes. However, it should be obvious to everyone that there
> is no need for any major changes (ESMTP isn't changing,
> almost all extensions can be done via milters.)
I don't agree with that. I think there are many useful things that
can still be done with/to Sendmail 8. Here are a few off the top of
my head:
1) Dynamically-loadable extensions. For example, new map types. Having
an official API for writing and loading a shared library would make other
requests (for example, MySQL support) much easier. One could even envision
a dynamically-loaded filtering extension that might be more efficient
than Milter.
2) Code cleanup and removal of obsolete features (how many people still
use UUCP for mail?) Or segregation of obsolete features into
dynamically-loadable modules.
3) APIs for queue manipulation. Right now we have queue groups and
rulesets to choose queue groups, but an API for managing and aging
queues could be pretty useful for very busy sites. Basically, "qtool"
integrated into Sendmail.
> All open source MTAs basically "simply work", so everyone can choose
> an MTA based on her/his personal preferences.
Well, sure, but one of the criteria (and an important one) by which many
judge an open-source project is by the "liveliness" of its
development. By this standard, Qmail is moribund, Sendmail is OK, and
Postfix is pretty good. There are very few widely-used open-source
projects whose developers consider them "finished". About the only
one I can think of is TeX.
>> What's the official status of MeTA1?
> MeTA1 is NOT a Sendmail Consortium project. MeTA1 is under
> development, and the website is updated whenever a new
> version is released.
OK, so has the Sendmail Consortium abandoned the idea of building an
MTA with a completely new architecture? They're going to stick with a
Sendmail-8-like system? (That's OK with me; it'd just be nice to
know!)
Regards,
David.
David F. Skoll wrote:
> I don't agree with that. I think there are many useful things that
> can still be done with/to Sendmail 8. Here are a few off the top of
Sure, but are they worth the effort? If you think they are:
feel free to do it... it's open source after all.
> OK, so has the Sendmail Consortium abandoned the idea of building an
> MTA with a completely new architecture? They're going to stick with a
> Sendmail-8-like system? (That's OK with me; it'd just be nice to
> know!)
Quoting the website:
"The development of sendmail X has been stopped."
In article
Res
> On Sun, 22 Dec 2007, Claus Assmann wrote:
> > Yes. However, it should be obvious to everyone that there
> > is no need for any major changes (ESMTP isn't changing,
> > almost all extensions can be done via milters.) All open
> > source MTAs basically "simply work", so everyone can choose
> > an MTA based on her/his personal preferences.
>
> Well it would be nice to have native MySQL support, nobody I know
> actually uses ldap so please dont suggest that :)
That says more about you than it does about the world.
> Every person, and I mean every person I know whos left Sendmail to
> postfix says for one of two reasons only these days-
>
> 1/ its ability to natively work with MySQL and virtual domains not
> requiring local user accounts.
> * I agree with this but I still rather use vpopmail with qmail as I
> know it works well.
>
> 2/ its simpler config files
> * I disagree with this, but that might be because I'm a long time
> sendmail user and understand the mc file options, for a newbie it
> could be a daunting task.
The existence of the .mc file is enough to make the case.
The reasons I have seen also include the perception of Postfix's design
being more suited to good security and (more recently) better handling
of very high concurrency through the use of kernel-based event filter
mechanisms like kqueue.
--
Now where did I hide that website...
Claus Aßmann wrote:
[David Skoll wrote some ideas]
> Sure, but are they worth the effort? If you think they are:
> feel free to do it... it's open source after all.
One of the criteria I use to select (or not) open-source projects is
the response "do it yourself... it's open-source after all", which
counts as a strong negative. I don't mean to be ungrateful, but
that's not a helpful response. It's pretty much the response I got
from the GNOME team when I suggested adding the ability for Evolution
to compose e-mails in an external editor.
I've long since given up on all things GNOME because of the GNOME
developers' attitude. The OP made the point that Sendmail seems to be
losing ground. This could be another factor. Sendmail after all
(supposedly) has a commercial enterprise driving its development. If
that's its official response to enhancement suggestions...
Regards,
David.
In comp.mail.sendmail Andrzej Adam Filip
> http://www.netbsd.org/docs/guide/en/chap-mail.html
>
> Note:
> Since NetBSD 4.0, postfix is the default MTA (Mail Transport Agent)
> and sendmail was removed.
>
Poor choice, if I had to replace sendmail, I'd use exim any day.
For now I am using both sendmail and exim, each were it suits
best.
--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 456: Noobs anywhere...
David F. Skoll wrote:
> (supposedly) has a commercial enterprise driving its development. If
> that's its official response to enhancement suggestions...
Obviously I don't speak for anyone but myself. If you want
an answer from "a commercial enterprise" you have to ask
them.
Anyway, maybe I should give you some "insider information":
it is obvious that there is very little interest in new
sendmail 8 features that are useful for many people (based
on the mailing list to which I subscribe: postfix, exim,
qmail, ... this applies to other MTAs as well). However,
there is a lot of work going on in other areas, e.g.,
dkim: there are many patches from "users" coming in almost
daily (just look at the release notes and the frequency of
releases). As I wrote before: MTAs are very mature and
basically a "commodity". The interest shifted elsewhere
(filtering, authentication, etc). However, some people
obviously have their own little item(s) which they consider
"important" or at least "interesting", but there are no
overwhelming requests which show me that something needs to
be added.
"Removing UUCP": Why should we do that? What would sendmail
gain? As long as there are people out there who use this it
will stay in. They are in a minority, but at least they
still have an MTA to use.
"Adding support for other maps": someone asks for MySQL and
says "no LDAP", someone else might ask for Postgres or some
other (open source) DB. That's why the "socket" map was
integrated (it was also donated code): it provides a
generic interface. Moreover, if you take a look at map.c
you will find the API for maps documented. That might be a
reason why many implementations for map types were
"donated".
"Queue control": the queue group implementation was a
mistake (just like some other things that happened in
8.12). However, it is "good enough" for most users (it lets
them do almost all of what they want to do).
In article
"David F. Skoll"
> Claus Aßmann wrote:
>
> [David Skoll wrote some ideas]
>
> > Sure, but are they worth the effort? If you think they are:
> > feel free to do it... it's open source after all.
>
> One of the criteria I use to select (or not) open-source projects is
> the response "do it yourself... it's open-source after all", which
> counts as a strong negative. I don't mean to be ungrateful, but
> that's not a helpful response. It's pretty much the response I got
> from the GNOME team when I suggested adding the ability for Evolution
> to compose e-mails in an external editor.
>
> I've long since given up on all things GNOME because of the GNOME
> developers' attitude. The OP made the point that Sendmail seems to be
> losing ground. This could be another factor. Sendmail after all
> (supposedly) has a commercial enterprise driving its development. If
> that's its official response to enhancement suggestions...
I'm guessing that you've never been a paying customer of Sendmail Inc.
with a need for support, or else you'd likely know the answer to that
'if' pondering.
Their responsiveness was a useful part of a successful pitch I made some
time ago to make a migration from their commercial products to regular
sendmail and a stack of open-source additions.
--
Now where did I hide that website...
Res
> On Sat, 22 Dec 2007, Andrzej Adam Filip wrote:
>
>> ESMTP does not change but spam fighting changes requirements for
>> "bleeding edge" MTA.
>
> It does a good job with greet pause, bad helo, require rdns and dns, RBL
> options..
> I dont think there much more it could do,
I can assure you there is a lot more and I dead sure I can not even
imagine big part of it :-)
> ok, it could change 'access.db' to use CIDR's, but I know why it
> doesnt use them and it makes perfect sence and I agree with it.
I do not share your view.
More effective implementation of access lookups is possible based on
btree maps (or future SQL maps) but sendmail.org decided to keep only
solution "fit for all supported database types" (hash,dbm,btree,text).
> It's not really an MTA's job to scan messages for spam and viruses,
> theres already MIMEDefang, MailScanner and a myriad of milters that hook
> spamassassin and virus scanners in to take care of that.
But sendmail can do a lot to help them make the job easier (among many
other things).
--
[pl>en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
There are many times when you want it to ignore the rest of the string just
like atof() does. Oddly enough, Perl calls atof(). How convenient. :-)
-- Larry Wall in <1991Jun24.231628.14446@jpl-devvax.jpl.nasa.gov>
## http://groups.google.com/groups?selm=873att5mjv@helen.fsf.ho bby-site.com ##
"David F. Skoll"
> Claus AÃmann wrote:
>
>>> Is Sendmail 8.x going to continue to be developed?
>
>> Yes. However, it should be obvious to everyone that there
>> is no need for any major changes (ESMTP isn't changing,
>> almost all extensions can be done via milters.)
>
> I don't agree with that. I think there are many useful things that
> can still be done with/to Sendmail 8. Here are a few off the top of
> my head:
>
> 1) Dynamically-loadable extensions. For example, new map types.
> Having an official API for writing and loading a shared library would
> make other requests (for example, MySQL support) much easier.
1) *maps provided by dynamic libraries*
IMHO the best way would be to create *one* new map loading external
a library specified by file path and capable to support many libraries
at once (ala ldap/socket-map to mutiple host:port/sockets).
It would require slight variation of the already provided interface.
Making it work on a selected platform may be easy, porting it to other
platform may be "laborious". Which OS/release do you use? :-)
Allowing sendmail to use libraries provided and maintained by other
project (under possibly different licences) may be helpful.
It may be a great idea for some if we can create template for creating
libraries capable to work with sendmail and exim (and possibly other MTA).
2) *mbdb provided by dynamic libraries*
As above we can use a variation of already defined interface
[ it is an interface "unused" for far ]
3) new interface for "built in" mailers (delivery *without* extra forking)
> One could even envision a dynamically-loaded filtering extension that
> might be more efficient than Milter.
Let's use (or abuse) already existing interfaces first ;-)
> [...]
--
[pl>en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
If it's working, the diagnostics say it's fine.
If it's not working, the diagnostics say it's fine.
-- A proposed addition to rules for realtime programming
## http://groups.google.com/groups?selm=87hci945ph@jason.fsf.ho bby-site.com ##
"David F. Skoll"
> Claus AÃmann wrote:
>
> [David Skoll wrote some ideas]
>
>> Sure, but are they worth the effort? If you think they are:
>> feel free to do it... it's open source after all.
>
> One of the criteria I use to select (or not) open-source projects is
> the response "do it yourself... it's open-source after all", which
> counts as a strong negative. I don't mean to be ungrateful, but
> that's not a helpful response.
It is the right answer
*IF* you can contribute without "understanding *full* design"
*IF* they help you a little to make you contribute a lot :-)
> It's pretty much the response I got from the GNOME team when I
> suggested adding the ability for Evolution to compose e-mails in an
> external editor.
>
> I've long since given up on all things GNOME because of the GNOME
> developers' attitude. The OP made the point that Sendmail seems to be
> losing ground. This could be another factor. Sendmail after all
> (supposedly) has a commercial enterprise driving its development. If
> that's its official response to enhancement suggestions...
Sendmail is slowly loosing ground for a long time as it could be
expected based on sendmail history and its previously dominant position.
The problem (as I see it) is that sendmail loses ground without
a proper fight and faster than it should.
--
[pl>en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
Therefore it is necessary to learn how not to be good, and to use
this knowledge and not use it, according to the necessity of the cause.
-- Machiavelli
## http://groups.google.com/groups?selm=8763yp45e5@tana.fsf.hob by-site.com ##
Claus AÃmann
> [...]
> "Adding support for other maps": someone asks for MySQL and
> says "no LDAP", someone else might ask for Postgres or some
> other (open source) DB. That's why the "socket" map was
> integrated (it was also donated code): it provides a
> generic interface. Moreover, if you take a look at map.c
> you will find the API for maps documented. That might be a
> reason why many implementations for map types were "donated".
What is you opinion about new map capable to use external dynamic
libraries specified by path? [initially for one platform only]
> [...]
--
[pl>en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
Perl programming is an *empirical* science!
-- Larry Wall in <10226@jpl-devvax.JPL.NASA.GOV>
## http://groups.google.com/groups?selm=87y7bl2qpf@jean.fsf.hob by-site.com ##
Bill Cole wrote:
[...]
> I'm guessing that you've never been a paying customer of Sendmail Inc.
> with a need for support, or else you'd likely know the answer to that
> 'if' pondering.
No, I've never been a paying customer of Sendmail Inc.
> Their responsiveness was a useful part of a successful pitch I made some
> time ago to make a migration from their commercial products to regular
> sendmail and a stack of open-source additions.
Like Sendmail Inc., we sell commercial software with an open-source
core. However, I listen very carefully to feature requests from
people using the free product, even if they're not paying customers,
for two reasons: (1) their suggestions improve both the free and the
commercial product, and (2) the free product "buys" us incalculable
marketing, so making it as good as possible is in our own interest.
Regards,
David.
Claus Aßmann wrote:
> As I wrote before: MTAs are very mature and
> basically a "commodity". The interest shifted elsewhere
> (filtering, authentication, etc).
Just curious, then: Why are you working on MeTA1? If the existing
free MTAs are good enough and MTAs are commodities, what's the point
of the MeTA1 project?
Regards,
David.
Andrzej Adam Filip wrote:
> What is you opinion about new map capable to use external dynamic
> libraries specified by path? [initially for one platform only]
I'm against specific solutions. It's generic or it's not of
much use. AFAICT there is not good cross-platform support
for doing this (libtool might work, but I heard too many
bad things about it.)
Moreover, it seems loading dynamic libraries is useful for
people who don't have source code, i.e., they can't compile
the code themselves.
David F. Skoll wrote:
> Just curious, then: Why are you working on MeTA1? If the existing
> free MTAs are good enough and MTAs are commodities, what's the point
> of the MeTA1 project?
Because none of the existing MTAs does what I want to do.
Hence I'm working on my own (instead of asking others to
change their MTA or add features that I consider
important). As you certainly have noticed, I appreciate the
input from others, and even if I disagree sometimes, I'm
willing to incorporate their requests, e.g., using
/etc/resolv.conf to find the nameserver addresses, as long
as the basic design (which has been written down in detail)
is not violated.
Once upon a time, Andrzej Adam Filip
>What is you opinion about new map capable to use external dynamic
>libraries specified by path? [initially for one platform only]
How about using an external map server via the socket map type? That
way sendmail doesn't have to be modified for every database type/schema
somebody wants to use.
--
Chris Adams
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
On Dec 23, 1:45 pm, Andrzej Adam Filip
> "David F. Skoll"
>
> > Claus Aßmann wrote:
>
> > [David Skoll wrote some ideas]
>
> >> Sure, but are they worth the effort? If you think they are:
> >> feel free to do it... it's open source after all.
>
> > One of the criteria I use to select (or not) open-source projects is
> > the response "do it yourself... it's open-source after all", which
> > counts as a strong negative. I don't mean to be ungrateful, but
> > that's not a helpful response.
>
> It is the right answer
> *IF* you can contribute without "understanding *full* design"
> *IF* they help you a little to make you contribute a lot :-)
I did find it possible to learn enough about the specific sections to
write patches.
I did not find any special interest in including any of them.
"Do it yourself" is always true and possible, but people are looking
for the "and I will try to help you" part of the setnence.
jmaimon@ttec.com wrote:
> I did find it possible to learn enough about the specific sections to
> write patches.
>
> I did not find any special interest in including any of them.
We sometimes get patches but there doesn't seem to be a
"demand" (by others) for including them. To include a new
feature into sendmail 8 requires at least one of two
things:
a) the maintainer(s) see the value of it;
b) there have been requests from several people to include it.
(there are several other requirements for patches to be
considered of course, e.g., good code quality, doesn't open
security holes, ...)
Currently only the "BadRCPTShutdown" patch seems to fulfill
at least b).
Moreover, if a new feature requires constant maintenance
(because it interfaces with some evolving software), then
it is less likely to be included unless the original author
is willing to maintain the code (e.g., nph map). That's
one way to become a member of the Sendmail Consortium:
provide good code and support...
Anyway, all of this should be well-known (if not from old
postings, then from other open-source projects).
cmadams@hiwaay.net (Chris Adams) writes:
> Once upon a time, Andrzej Adam Filip
>>What is you opinion about new map capable to use external dynamic
>>libraries specified by path? [initially for one platform only]
>
> How about using an external map server via the socket map type? That
> way sendmail doesn't have to be modified for every database type/schema
> somebody wants to use.
*Dynamic Libraries as plug-ins*
With a code to load dynamic libraries (implementing specified
interface) as "plug-ins" specified by library name/path there would
be no need to modify sendmail code to support "yet another plug-in"
*Socket map adoption*
"socket map protocol" is not widely supported by "non sendmail" programs.
I am aware only about support socket map support by Cyrus-IMAP.
The support was included even before sendmail move socket map to
official (non FFR) code.
I think socket map protocol misses simple reference implementations
in perl/C/java/python/... under licences typical for the for programs
created in these languages.
[ e.g. its a customary for perl module: "under licence as perl itself"]
*Socket map improvements*
I miss socket map implemented via UDP protocol (connection less
communication). IMHO it would provide much better "decoupling" of MTA
and "map server provider" architectures.
[Pretty good candidate for plug-in (IMHO) :-) ]
--
[pl>en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
The last thing one knows in constructing a work is what to put first.
-- Blaise Pascal
----
http://groups.google.com/groups?selm=87fxxsjvo2@roger.fsf.ho bby-site.com
Claus AÃmann
> Andrzej Adam Filip wrote:
>
>> What is you opinion about new map capable to use external dynamic
>> libraries specified by path? [initially for one platform only]
>
> I'm against specific solutions. It's generic or it's not of
> much use. AFAICT there is not good cross-platform support
> for doing this (libtool might work, but I heard too many
> bad things about it.)
I expected that making it fully portable would be a nightmare :-)
*But* implementing it on a few best suited platforms form set of
platform sendmail is mainly used on should be not too hard
[ if *somebody else* is going to do it ;-) ]
> Moreover, it seems loading dynamic libraries is useful for
> people who don't have source code, i.e., they can't compile
> the code themselves.
From perspective of sendmail source code maintainer it allows to
properly "decouple" maintenance of code.
--
[pl>en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
Before destruction a man's heart is haughty, but humility goes before honour.
-- Proverbs 18:12
----
http://groups.google.com/groups?selm=878x3kjvcc@francis.fsf. hobby-site.com
On Dec 24, 12:06 am, Claus Aßmann
> To include a new
> feature into sendmail 8 requires at least one of two
> things:
>
> a) the maintainer(s) see the value of it;
> b) there have been requests from several people to include it.
>
> (there are several other requirements for patches to be
> considered of course, e.g., good code quality, doesn't open
> security holes, ...)
>
> Currently only the "BadRCPTShutdown" patch seems to fulfill
> at least b).
>
Do you have an opinion on the patch? Naturally, I am of the opinion
that its inclusion would benefit everyone, assuming a code review
checked out clean.
> Anyway, all of this should be well-known (if not from old
> postings, then from other open-source projects).
As a frequent participant in these old postings, I suppose this is as
good a rant cue as any.
Where it came down to is a sort of chicken and egg problem, where
inclusion doesnt happen without demand, but demand doesnt happen
without use, which would seem to require some kind of inclusion.
I have tried in the past to spark some demand by suggesting the
potential applicability of patches to people/posters who could
possibly benefit by them. However, the required downloading, patching,
compiling and installing, with the resulting "unofficial" build most
likely dissuades most from even trying.
Where are these patches that come in everyday? Are they for public
consumption? Is there any support for testing any of them?
I thought this was exactly what "_FFR" was supposed to accomplish and
the vast majority of my patches are completely encapsulated by that.
Free floating patches dont seem to make impressions easily. However,
that doesnt mean that inclusion isnt warranted.
Witness the badmx feature in 8.14, which duplicates functionality
here.
http://www.jmaimon.com/sendmail/#checkmx
Or how about samenames patch, fixing the bug reported in 8.14.2?
http://www.jmaimon.com/sendmail/#dnsmap-samename.v1
Or how about this release note from milter-rrres
http://www.jmaimon.com/sendmail/patches/milter-rrres.Changes .v9.txt
There are lots more patches there which certainly couldnt hurt and
would provide very nice functionality, like multiline error messages
(I wasnt the only one to inquire about that), rulesets to require
authorized senders for various recipients, new map type allowing full
manipulation of classes and lots more.
For examples of potential uses of milter functionality included in
milter-rrres, http://www.jmaimon.com/sendmail/callahead-milter/
includes the ability to reference sendmail on many things, up to and
including utilizing the sendmail DNS map for full resolution (idea was
from five-ten milter alternate resolver approach).
I myself have been running MTA's with nearly all of the patches
available from http://www.jmaimon.com/sendmail with no ill-effects,
and actually using functionality made available.
I will be updating the patches to 8.14, as applicable, eventually.
Sooner if there is any specific demand.
There are two distinct problems with maintaining compatibility of my
patches to sendmail.
1) New features "stealing" option codes, letters, milter command
numbers etc
2) Functionality being duplicated or supplied in slightly different
ways, requiring restructuring of the patch
jmaimon@ttec.com wrote:
> Where it came down to is a sort of chicken and egg problem, where
> inclusion doesnt happen without demand, but demand doesnt happen
> without use, which would seem to require some kind of inclusion.
That's not my experience. Demand happens because someone
has a problem ("an itch to scratch"). Then they search for
an existing solution (which is not too hard nowadays due to
all the search engines), they write one themselves, or they
pay someone to do it.
For example: anti-relaying. I wrote those rules because
someone abused the mail server at my university. I
published them and they got downloaded and used _many_
times. Eventually they got integrated (in some different
form) into the sendmail 8 distribution.
There are of course other features that aren't really
"needed", but "cool to have". For those demand is harder to
demonstrate. However, let's face it: every additional line
of code in the MTA makes it harder to maintain (and might
introduce new bugs). Having no regression tests (for
existing functionality) and no unit tests for those new
features makes me even more reluctant to add them.
> Where are these patches that come in everyday? Are they for public
> consumption? Is there any support for testing any of them?
There are no "patches that come in everyday" (for
sendmail). Maybe you misread a posting (related to dkim)?
I just checked: for 2007 a total of 7 patches have been
submitted (most of them for minor bugs), not counting
your mail with all the references to your webpage.
Once upon a time, Andrzej Adam Filip
>*Dynamic Libraries as plug-ins*
> With a code to load dynamic libraries (implementing specified
> interface) as "plug-ins" specified by library name/path there would
> be no need to modify sendmail code to support "yet another plug-in"
However, then you have to work within sendmail's design for everything.
For example, I wrote a socket map that tracks messages sent per user (so
eventually I can have a threshold kick in where messages get quarantined
for inspection, e.g. due to spam bot possibility). That would be
difficult to impossible to do within sendmail, due to forking processes.
Also, plug-in APIs and ABIs can be difficult to work out and maintain.
This is Unix, where separate processes are the norm. Socket map and
milter allow you to extend sendmail across a network socket. Very few
Unix programs have successful plug-in APIs, except for very specific
applications (e.g. media codecs, which is a much simpler problem to
solve than a general server extension).
>*Socket map adoption*
> "socket map protocol" is not widely supported by "non sendmail" programs.
> I am aware only about support socket map support by Cyrus-IMAP.
> The support was included even before sendmail move socket map to
> official (non FFR) code.
> I think socket map protocol misses simple reference implementations
> in perl/C/java/python/... under licences typical for the for programs
> created in these languages.
> [ e.g. its a customary for perl module: "under licence as perl itself"]
There are sample socket map client and server perl scripts included in
the sendmail distribution. In any case, it isn't a complicated thing
(as opposed to milter); it is a simple request/answer system.
>*Socket map improvements*
> I miss socket map implemented via UDP protocol (connection less
> communication). IMHO it would provide much better "decoupling" of MTA
> and "map server provider" architectures.
> [Pretty good candidate for plug-in (IMHO) :-) ]
That would be nice (it would probably be a better fit even); I'm sure
code would be welcome. I don't see why a plug-in would be needed, since
such a plug-in would have to re-implement the current socket map (and
code duplication sucks). It would probably be a pretty simple
modification of the existing code.
--
Chris Adams
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
Post removed (X-No-Archive: yes)
Res
> On Tue, 24 Dec 2007, Claus AÃmann wrote:
>>
>> jmaimon@ttec.com wrote:
>>
>>> Where it came down to is a sort of chicken and egg problem, where
>>> inclusion doesnt happen without demand, but demand doesnt happen
>>> without use, which would seem to require some kind of inclusion.
>>
>> That's not my experience. Demand happens because someone
>> has a problem ("an itch to scratch"). Then they search for
>> an existing solution (which is not too hard nowadays due to
>> all the search engines), they write one themselves, or they
>> pay someone to do it.
>
> If >60% of the postfix community uses MySQL as a backend to handle
> countless thousands of users and virtual domains, how is that a demand
> that you're 'not' interested in filling to help keep Sendmail users?
http://en.wikipedia.org/wiki/Not_Invented_Here
Not Invented Here (NIH) is a term used to describe a persistent
sociological, corporate or institutional culture that avoids using
already existing products, research or knowledge because of its
different origins. It is normally used in a pejorative sense.
Sendmail is no longer at position allowing to simply ignore
"research of users' demands" generated by "competing MTAs".
[ Especially open source MTAs ]
--
[pl>en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
"Paul Lynde to block..."
-- a contestant on "Hollywood Squares"
----
http://groups.google.com/groups?selm=87lk7jd52o@luis.fsf.hob by-site.com
Post removed (X-No-Archive: yes)
cmadams@hiwaay.net (Chris Adams) writes:
> Once upon a time, Andrzej Adam Filip
>>*Dynamic Libraries as plug-ins*
>> With a code to load dynamic libraries (implementing specified
>> interface) as "plug-ins" specified by library name/path there would
>> be no need to modify sendmail code to support "yet another plug-in"
>
> However, then you have to work within sendmail's design for everything.
> For example, I wrote a socket map that tracks messages sent per user (so
> eventually I can have a threshold kick in where messages get quarantined
> for inspection, e.g. due to spam bot possibility). That would be
> difficult to impossible to do within sendmail, due to forking processes.
>
> Also, plug-in APIs and ABIs can be difficult to work out and maintain.
> This is Unix, where separate processes are the norm. Socket map and
> milter allow you to extend sendmail across a network socket. Very few
> Unix programs have successful plug-in APIs, except for very specific
> applications (e.g. media codecs, which is a much simpler problem to
> solve than a general server extension).
map interface is the first obvious target for "pluginisation".
mbdb interface (mailbox database) is the second.
>>*Socket map adoption*
>> "socket map protocol" is not widely supported by "non sendmail" programs.
>> I am aware only about support socket map support by Cyrus-IMAP.
>> The support was included even before sendmail move socket map to
>> official (non FFR) code.
>> I think socket map protocol misses simple reference implementations
>> in perl/C/java/python/... under licences typical for the for programs
>> created in these languages.
>> [ e.g. its a customary for perl module: "under licence as perl itself"]
>
> There are sample socket map client and server perl scripts included in
> the sendmail distribution. In any case, it isn't a complicated thing
> (as opposed to milter); it is a simple request/answer system.
If we talk specifically about socket maps in perl then
I am unaware about any CPAN module providing socket map designed to take
advantage of other existing CPAN modules.
[Feel free to narrow my ignorance.]
>>*Socket map improvements*
>> I miss socket map implemented via UDP protocol (connection less
>> communication). IMHO it would provide much better "decoupling" of MTA
>> and "map server provider" architectures.
>> [Pretty good candidate for plug-in (IMHO) :-) ]
>
> That would be nice (it would probably be a better fit even); I'm sure
> code would be welcome. I don't see why a plug-in would be needed, since
> such a plug-in would have to re-implement the current socket map (and
> code duplication sucks). It would probably be a pretty simple
> modification of the existing code.
Have you read Claus answers in the thread?
Somehow it strengthened *my impression* that sendmail.org is "not eager"
to accept code donations. it makes "reduction" of necessary code changes
in sendmail.org distribution *a very big advantage*.
--
[pl>en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
Nothing astonishes men so much as common sense and plain dealing.
-- Ralph Waldo Emerson
----
http://groups.google.com/groups?selm=87ejdbd4m7@donald.fsf.h obby-site.com
Post removed (X-No-Archive: yes)
Res
> On Sun, 23 Dec 2007, Bill Cole wrote:
>
>>> Well it would be nice to have native MySQL support, nobody I know
>>> actually uses ldap so please dont suggest that :)
>>
>> That says more about you than it does about the world.
>
> Actually it says more about me, my local geographical area (Aus/NZ),
> the various network admins from all over the world that subscribe to
> a netops mailing list where a survery early this year found of the 700
> odd repsondants, 100 odd used ldap, PostGreSQL, Oracle with the
> remainding vast majority using MySQL.
Have you tried to use socket map to integrate MySQL with sendmail?
[ e.g. using perl script as "man in the middle"]
[BTW the extra layer should allow to reuse db connections]
>> [...]
>> of very high concurrency through the use of kernel-based event filter
>> mechanisms like kqueue.
>
> define very high concurrency
>
> I have no problems on my ecartis list server which is the hardest working
> beast I have, lists with >1700 members are all delivered under a minute,
> the 'same time' it takes postfix to deliver, both which are slighty faster
> than Qmail (never tried Exim on that server, so can't comment there)
What percentage of first try delivery failures do you get?
P.S.
The quote in the footer have not been had picked, it has been chosen
randomly by the script I use.
--
[pl>en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
-- Seen on #Linux
----
http://groups.google.com/groups?selm=873atrd434@william.fsf. hobby-site.com
Post removed (X-No-Archive: yes)
Andrzej Adam Filip wrote:
> If we talk specifically about socket maps in perl then
> I am unaware about any CPAN module providing socket map designed to take
> advantage of other existing CPAN modules.
> [Feel free to narrow my ignorance.]
MIMEDefang does Sendmail socketmap communication as well. It's an easy
way to hook up your CPAN modules to Sendmail. However, it's not exactly
low-overhead.
Regards,
David.
On Dec 24, 12:52 pm, Claus Aßmann
> jmai...@ttec.com wrote:
> > Where it came down to is a sort of chicken and egg problem, where
> > inclusion doesnt happen without demand, but demand doesnt happen
> > without use, which would seem to require some kind of inclusion.
>
> That's not my experience. Demand happens because someone
> has a problem ("an itch to scratch"). Then they search for
> an existing solution (which is not too hard nowadays due to
> all the search engines), they write one themselves, or they
> pay someone to do it.
This kind of intelligent and targeted demand is only going to come
from a certain segment of the tech population. That doesnt translate
to a feature/improvement being unwanted/unneeded.
>
> For example: anti-relaying. I wrote those rules because
> someone abused the mail server at my university. I
> published them and they got downloaded and used _many_
> times. Eventually they got integrated (in some different
> form) into the sendmail 8 distribution.
Thats not a good data point.
1) There wasnt much else at the time
2) People trust you, your stuff is the next best thing to being
included with sendmail, cause it usualy is.
>
> There are of course other features that aren't really
> "needed", but "cool to have". For those demand is harder to
> demonstrate.
I would have been of the opinion that features that implement
functionality that isnt controversial at all should have a much lower
bar of acceptance then those which are, regardless of the level of
demand.
> However, let's face it: every additional line
> of code in the MTA makes it harder to maintain (and might
> introduce new bugs). Having no regression tests (for
> existing functionality) and no unit tests for those new
> features makes me even more reluctant to add them.
Wasn't this what the _FFR framework is explicitly designed for? Define
it, it is in. Undefined, it doesnt exist.
(I am of the opinion that _FFR_* should be more heavily documented and
promoted, large numbers probably went unused due more to lack of
education/comfort than lack of demand)
>
> > Where are these patches that come in everyday? Are they for public
> > consumption? Is there any support for testing any of them?
>
> There are no "patches that come in everyday" (for
> sendmail). Maybe you misread a posting (related to dkim)?
> I just checked: for 2007 a total of 7 patches have been
> submitted (most of them for minor bugs), not counting
> your mail with all the references to your webpage.
My mistake, I was referring to your post where you mentioned patches
coming in almost every day.
jmaimon@ttec.com wrote:
> On Dec 24, 12:52 pm, Claus Aßmann wrote:
> > For example: anti-relaying. I wrote those rules because
> 2) People trust you, your stuff is the next best thing to being
Why should people have trusted me back then? That was in 1996,
at that time I was just some guy in Germany, not even a member
of the Sendmail Consortium.
> My mistake, I was referring to your post where you mentioned patches
> coming in almost every day.
For dkim (milter), not for sendmail.
"David F. Skoll"
> Andrzej Adam Filip wrote:
>
>> If we talk specifically about socket maps in perl then
>> I am unaware about any CPAN module providing socket map designed to take
>> advantage of other existing CPAN modules.
>> [Feel free to narrow my ignorance.]
>
> MIMEDefang does Sendmail socketmap communication as well. It's an easy
> way to hook up your CPAN modules to Sendmail. However, it's not exactly
> low-overhead.
The direct question you have "indirectly asked for":
Have you considered moving socket map handling functions present in
MIMEDefang perl milter to separate module available separately via CPAN?
--
[pl>en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
Even the best of friends cannot attend each other's funeral.
-- Kehlog Albran, "The Profit"
----
http://groups.google.com/groups?selm=87wsr3gl7b@denise.fsf.h obby-site.com
Res
> On Tue, 25 Dec 2007, Andrzej Adam Filip wrote:
>
>> Have you tried to use socket map to integrate MySQL with sendmail?
>
> nope
The obvious next question: Would like to test it? ;-)
I may publish the *tiny* module missing in CPAN.
Its needed to make handpicked collection of *already existing* CPAN
modules capable to support pretty advanced socket map daemons by
*small* perl scripts. [ CPAN modules support MySQL too ].
> [...]
--
[pl>en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
Young men want to be faithful and are not;
old men want to be faithless and cannot.
-- Oscar Wilde
----
http://groups.google.com/groups?selm=87d4svf254@alyse.fsf.ho bby-site.com
On Dec 24, 10:34 pm, Claus Aßmann
> jmai...@ttec.com wrote:
> > On Dec 24, 12:52 pm, Claus Aßmann wrote:
> > > For example: anti-relaying. I wrote those rules because
> > 2) People trust you, your stuff is the next best thing to being
>
> Why should people have trusted me back then? That was in 1996,
> at that time I was just some guy in Germany, not even a member
> of the Sendmail Consortium.
Your original work was basically the only thing readily available for
sendmail anti-abuse (at least thats what I found trying to retrofit it
to older version of sendmail ported to NT). Sendmail was basically the
only real game in town at the time. Sendmail was fairly stagnant.
The rest followed, your earned trust followed your first mover
advantage and was applied to all the rest of the work you still have
posted.
Things dont seem to work that way anymore, except that Sendmail looks
to be heading into stagnation in the not to distant future.
In the past sendmail development went through a develop-stagnate-
develop cycle. This was due in part to pent-up demand.
Now that there is elsewhere for demand to go, that dynamic may no
longer hold true.
Andrzej Adam Filip wrote:
> The direct question you have "indirectly asked for":
> Have you considered moving socket map handling functions present in
> MIMEDefang perl milter to separate module available separately via CPAN?
No, because MIMEDefang relies on a fair amount of C glue code and
doesn't (yet) lend itself to being made into a CPAN module. (MIMEDefang
is not really a "perl milter". The Perl code does not speak the Milter
protocol; instead, C glue code converts milter calls into an internal
protocol used by the Perl code.)
We have plans to clean up MIMEDefang and modularize it, but that is unlikely
to happen soon because we are forced to work on projects that bring in
actual revenue. :-)
Regards,
David.
"David F. Skoll"
> Andrzej Adam Filip wrote:
>
>> The direct question you have "indirectly asked for":
>> Have you considered moving socket map handling functions present in
>> MIMEDefang perl milter to separate module available separately via CPAN?
>
> No, because MIMEDefang relies on a fair amount of C glue code and
> doesn't (yet) lend itself to being made into a CPAN module.
> (MIMEDefang is not really a "perl milter". The Perl code does not
> speak the Milter protocol; instead, C glue code converts milter calls
> into an internal protocol used by the Perl code.)
>
> We have plans to clean up MIMEDefang and modularize it, but that is
> unlikely to happen soon because we are forced to work on projects that
> bring in actual revenue. :-)
You know how to give Claus good arguments/excuses to use ;-)
--
[pl>en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
Sometimes, when I think of what that girl means to me, it's all I can do
to keep from telling her.
-- Andy Capp
----
http://groups.google.com/groups?selm=87zlvymzne@karen.fsf.ho bby-site.com
In article
Res
> On Sun, 23 Dec 2007, Bill Cole wrote:
>
> >> Well it would be nice to have native MySQL support, nobody I know
> >> actually uses ldap so please dont suggest that :)
> >
> > That says more about you than it does about the world.
>
> Actually it says more about me, my local geographical area (Aus/NZ),
> the various network admins from all over the world that subscribe to
> a netops mailing list where a survery early this year found of the 700
> odd repsondants, 100 odd used ldap, PostGreSQL, Oracle with the
> remainding vast majority using MySQL.
Just a WAG: mostly ISP folks, right?
It's really hard to get a generally representative sample of mail
admins, and it is especially hard in anything that vaguely resembles a
public forum. It's not hard to figure out that most non-trivial mail
systems are not run by entities that can be called ISP's by any
reasonable definition, but rather by other sorts of businesses, with
their mail systems handling mail for users who are not paying customers
buying mail and maybe other network services, but rather are employees.
In short: most mail systems are corporate systems. LDAP is ubiquitous in
that world, but most corporate sysadmins have little or no interaction
with professional communities outside their own companies.
A view of the world that does not see anyone using LDAP is a service
provider view.
> >> Every person, and I mean every person I know whos left Sendmail to
> >> postfix says for one of two reasons only these days-
> >>
> >> 1/ its ability to natively work with MySQL and virtual domains not
> >> requiring local user accounts.
> >> * I agree with this but I still rather use vpopmail with qmail as I
> >> know it works well.
> >>
> >> 2/ its simpler config files
> >> * I disagree with this, but that might be because I'm a long time
> >> sendmail user and understand the mc file options, for a newbie it
> >> could be a daunting task.
> >
> > The existence of the .mc file is enough to make the case.
>
> But its just another configuration file.
No, it is not. It is a control file for a complex structure of m4 files
that you have to keep available anywhere you want to use any .mc to
build the real config file.
How often have you seen people show up here with 'problems' that boil
down to a failure to rebuild their sendmail.cf or to restart the
sendmail daemon? It's easy to sneer at such errors, but the
> > The reasons I have seen also include the perception of Postfix's design
> > being more suited to good security and (more recently) better handling
>
> Oh please! the 'better security' might have been the case 5 years ago, but
> hardly stands today, infact your not subscribed to full disclosure lists
> are you :) There was a post about 2 weeks ago about postfix.
That seems to be a response to something I did not write. I did not say
and would not dream of saying that Postfix or any other MTA is immune to
security bugs.
I know many people who have made the active choice to switch from
Sendmail to Postfix. I have not made that choice anywhere although I do
now run some small Postfix systems as well as some rather larger
Sendmail systems. The reasons people do things are often based more in
perception than demonstrable fact.
> > of very high concurrency through the use of kernel-based event filter
> > mechanisms like kqueue.
>
> define very high concurrency
The case I am most familiar with handles >2k simultaneous inbound smtp
sessions for extended periods, with connection rates in the hundreds per
second without losing or significantly delaying connections.
> I have no problems on my ecartis list server which is the hardest working
> beast I have, lists with >1700 members are all delivered under a minute,
> the 'same time' it takes postfix to deliver, both which are slighty faster
> than Qmail (never tried Exim on that server, so can't comment there)
That doesn't seem particularly impressive, and delivery usually isn't as
sensitive to local concurrency problems as acceptance. The bottleneck on
delivery of large lists (at least for the lists a couple orders of
magnitude higher than yours that I've worked with) is usually failure of
receivers to accept mail as fast as it could be sent.
--
Now where did I hide that website...
Post removed (X-No-Archive: yes)
In article
Res
> >> But its just another configuration file.
> >
> > No, it is not. It is a control file for a complex structure of m4 files
> > that you have to keep available anywhere you want to use any .mc to
> > build the real config file.
>
> Are you that bored you want 'a play on words'? a control file is a
> configuration file, they both dictate how software X behaves.
The .mc file does not control how sendmail works at all.
> >>> The reasons I have seen also include the perception of Postfix's design
> >>> being more suited to good security and (more recently) better handling
> >>
> >> Oh please! the 'better security' might have been the case 5 years ago, but
> >> hardly stands today, infact your not subscribed to full disclosure lists
> >> are you :) There was a post about 2 weeks ago about postfix.
> >
> > That seems to be a response to something I did not write. I did not say
>
> OK, sorry, someone else must have partook in this thread using html whoch
> we both know couldnt hold format in usenet or email if its existence
> depended on it :)
I mean that you read something I wrote and ignored some of the words,
not that someone else wrote them.
> >> define very high concurrency
> >
> > The case I am most familiar with handles >2k simultaneous inbound smtp
> > sessions for extended periods, with connection rates in the hundreds per
> > second without losing or significantly delaying connections.
>
> I see that all the time, using DL380 (g3's and g4's) with 4 gigs ram
> handling all the connections, doing anti spam tests and talking via
> milter to the backend mail routers, the loads go from 1 to 5 (and this is
> attributed to spammassassin, virus scanning uses no load at all)
Over 2000 sendmail daemon children plus subsidiary processes for
scanning in 4g? That's a bit surprising.
--
Now where did I hide that website...
Post removed (X-No-Archive: yes)
Res
> On Thu, 27 Dec 2007, Bill Cole wrote:
>>> [...]
>>> I see that all the time, using DL380 (g3's and g4's) with 4 gigs ram
>>> handling all the connections, doing anti spam tests and talking via
>>> milter to the backend mail routers, the loads go from 1 to 5 (and this is
>>> attributed to spammassassin, virus scanning uses no load at all)
>>
>> Over 2000 sendmail daemon children plus subsidiary processes for
>> scanning in 4g? That's a bit surprising.
>
> Not really, 2K sendmail sessions and using MailScanner on those boxes
> is a non issue, SA uses localrules, rules emporium, and razor only, virus
> scanner is f-prot, we did see a larger load when using clamav and its very
> slow, the expence of f-prot is very well worth it since it works in the
> order of 30 fold faster, I have had those machines at 2500, but it does
> get iffy then, and rather than double the ram, I took the cheaper option
> and just cut back 500 per box.
For the public record:
1) What do you use *before* deploying filtering based on message content?
[ which DBNSBL do you use?]
2) Have you tried to create special arrangements with top ma mail
sources? [it should help to deliver throughput averaging]
> I have on my wish list for next year 360 G5's with 8G memory,
> the 380's are overkill for front end MTA's, just takes up too much room
> and we dont need the disk space on them.
--
[pl>en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
I DON'T THINK I'M ALONE when I say I'd like to see more and more planets
fall under the ruthless domination of our solar system.
-- Jack Handley, The New Mexican, 1988.
----
http://groups.google.com/groups?selm=87bq8b7m0n@amanda.fsf.h obby-site.com
Post removed (X-No-Archive: yes)
Res
> On Fri, 28 Dec 2007, Andrzej Adam Filip wrote:
>>
>> For the public record:
>> 1) What do you use *before* deploying filtering based on message content?
>> [ which DBNSBL do you use?]
>
> sorbs, spamcop, spamhaus (local) and another more restrive RBL,
> use milter-regex to be rid of dial/dsl/cable/dynamics amongst others,
> spf, require rnds, bad helo and badmx, plus our extensive access file
> list.
1a) Do you use FEATURE(`greet_pause')?
1b) Do you block based on lack of RDNS? Optionally with check strength
fine tuned per source: no check/require PTR/require closed PTR-A loop
1c) Do you tailor DNSBL list to country/ASN of origin?
IMHO it makes sense to "fine tune" strength of DNSBL checks based on
expected ham/spam ratio.
>> 2) Have you tried to create special arrangements with top ma mail
>> sources? [it should help to deliver throughput averaging]
>
> Not sure what you mean on this one
If you receive 5%+ of incoming messages then from pure technical
perspective it may make sense to ask postmaster of the sending domain
to fine tune his/her configuration for sending to you e.g.
instead of sending "at once" send every few minutes many messages over
single SMTP connection. It should reduce number of processes created by
your sendmail.
Yes I know that "pure technical perspective" is usually "distorted" by
non technical factors :-)
--
[pl>en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
"Religion is something left over from the infancy of our intelligence, it will
fade away as we adopt reason and science as our guidelines."
-- Bertrand Russell
----
http://groups.google.com/groups?selm=87ir2jozgf@wilma.fsf.ho bby-site.com
Post removed (X-No-Archive: yes)