The owner of the most spammed sites on the planet is partnering with the biggest spammer arms dealer to ensure open access to your Inbox for their customers
I would say that what sucks is not sendmail. What sucks is the many MTA/SMTP developers writing code that violates the RFC for SMTP and breaks things. Many firewalls do this (SMTPfixup was a good way to break mail routing) and so do other "appliances". This is why sendmail has had to stay as flexible as possible in order to keep email routing itself in a usable state.
To address your points:
1. The configuration system is M4. M4 is not sendmail. Sendmail uses M4. The configuration system is one of the reasons why sendmail has the vast feature set that keeps you using it. This can be improved, I agree, but I'm personally happy that support for LDAP and encryption were given priority because M4 works i.e M4 is not broken. If you administer sendmail for a company, you can get a comercially supported version that is QA tested and easy to configure. Easy to configure does not change the fact that email in general is hard. Those who try to simpify with "I installed this in two seconds and it runs" statements have probably never had to do this for a two merged corporations that acquired a 3rd company all with different internal messaging systems. Sendmail is the only glue for all of the domains, auth, provisioning, and routing mess that this type of business activity can create.
2. There is a brand spanking new Sendmail O'Rielly book that was just released. It does cover the important topics. This is not a fun read.
3. This is an open source project. Like any other open source project, you can dream of shooting it or contribute. Maybe your size of function preferences don't apply to sendmail. You'll only know if you ask the sendmail developer community. They have always given me an accurate answer when I've questioned why some things were done in a certain way. It's usually not their fault, but they will ack if there is something they need to do.
I'm not sure how you have come to believe that sendmail has a bad design. That one sentence from the entire post does not support your assumption.
Sendmail led the concept of relay control (see antiSPAM stuff in the original post) because of the fact that it was there when the network (a.k.a. the internet) went through this change.
"Official" qmail has seen no development since 1997 so many modern features are not implemented (such as TLS) and I don't think there is any prospect of serious delvelopment from now on.
Take a look at an example installation at qmail.org. All those small programs need their own config files. The example install at qmail.org had 34 config files to configure
Sendmail is currently more likeley to keep up with the evolution of e-mail standards.
The sendmail open source has a 20+ year legacy. It has been rewritten 4 times from scratch. It's large feature set is a function of the equally large and diverse user community it serves. Believe it or not, some people still use the DECNet and UUCP delivery settings.
Sendmail continues to evolve, argueably more rapidly and for the better than any other Open Source MTA.
I think an anonymous post with an unsupported claim of a bad design is designed to spread FUD. I call that a bad design.
Sendmail gets a bad name sometimes from folks who gave up on it for various reasons (Too hard?). Sometimes some of these "administrators" can't tell the difference between a Message store and an MTA./var/mail is not sendmail!
I personally like the way the sendmail community handles these issues when they arise. 2 reports in a row is a bummer, but the frequency is exaggerated. I respect the fact that there are other open source MTAs and think they can be made to work well too (postfix, qmail, exim, etc...).
Please keep in mind that this MTA was around when the network was more of a community (not a lot of.com) and having an open relay was normal. Think ARPAnet.
Sendmail pioneered lots of the AntiSPAM/AntiSPAMMER features that are taken for granted today (advanced relay control, ip to dns a record verify, DNS blacklisting etc...).
There are reasons why many (think mega sized corporations around the world) use sendmail in front of their message store systems (Exchange, Notes, Cyrus,/var/mail, etc...). Think scale and way beyond systems for only 10s of thousands or less.
It has/provides:
The ability to use LDAP information for routing.
The ability to use LDAP instead of a flat Alias file.
LDAP intelligence at the port 25 gateway (Think not have unreturnable bounce messages traveling all the way into the network and then getting stuck at your message store) A smart MTA at the gateway will break the connection and not waste time trying to pass the message through.
Pass based (w/crypt options) SMTP Authentication
Certificate base SMTP authentication
Unlimited relay control options (rule sets and milters)
Built in SMTP encryption (TLS/SSL) with support for PKI systems
Multiple queues and deterministic queuing (queue groups)
Fallback MX (this is huge for failover)
Mid-protocol conversation filtering (Milter, do all of your attachment stripping and message scanning without adding extra hops).
Capable of sending email just as fast as any other MTA without violating RFCs (do you really not want to commit your data to stable storage?) and putting your data at risk.
SMTP pipelining (why open a new connection each time?)
Active development with developers developing to the RFC/IETF's standards and the needs of today's internet.
Ability to be configured to avoid port 25 Denial of service attacks that other MTAs are vulnerable to.
My 2 pennies, just another opinion, now leaving verbose mode...
I would guess that the MUA that comes closest to meeting all of your requirements is Microsoft's Entourage which comes with Office X for Mac OS X. Entourage has no per message basis for image loading (that I know of). It is also not cross platform. IMAP standards are supported better than in M$ lookOut. I would call it the offspring of Outlook and a good standards based IMAP 4 client. GPG integration and Palm Sync are both available. I think it would be an interesting example if you ever get to writing your dream mail client. I don't use it anymore since Mozilla 1.3 runs much better now on OS X.
I do understand. The point I was trying to make was that your company's policy exists because control over that port, and the applications using it, is limited by what the IMAP server and MUA are able to do. Mozilla tls over IMAP is part of the solution. Certificate based authentication improves that enough to open the port in the firewall. BTW, this can also be used for SMTP auth and encryption. I'll assume they don't close port 25 because you receive inbound email. They just use an MTA that they trust (I hope).
I must admit that I do not understand what you mean about using mod_proxy and apache virtual hosts to get through your firewall without a web based MUA. I am familiar with the module and the web server, but without using a web based MUA and ssl you would just be un-securing the port for your company. Please forgive me if I am missing something obvious. Also, pure IMAP proxy daemons exist. I know of at least one that works well. Good luck with your search for a solution.
An IMAP Server and an MUA that can use certificates to authenticate people and TLS/SSL to encrypt their email activities is all you need here. Mozilla mail supports this and that's why it is still a very good MUA for business. The spinoffs never pay much attention to these features and end up with nice looking MUAs that cannot truly secure email routing and access. The company I work for can safely allow IMAP access without VPN or SSH because of this.
Slashdot Mirror
The owner of the most spammed sites on the planet is partnering with the biggest spammer arms dealer to ensure open access to your Inbox for their customers
I would say that what sucks is not sendmail. What sucks is the many MTA/SMTP developers writing code that violates the RFC for SMTP and breaks things. Many firewalls do this (SMTPfixup was a good way to break mail routing) and so do other "appliances". This is why sendmail has had to stay as flexible as possible in order to keep email routing itself in a usable state.
To address your points:
1. The configuration system is M4. M4 is not sendmail. Sendmail uses M4. The configuration system is one of the reasons why sendmail has the vast feature set that keeps you using it. This can be improved, I agree, but I'm personally happy that support for LDAP and encryption were given priority because M4 works i.e M4 is not broken. If you administer sendmail for a company, you can get a comercially supported version that is QA tested and easy to configure. Easy to configure does not change the fact that email in general is hard. Those who try to simpify with "I installed this in two seconds and it runs" statements have probably never had to do this for a two merged corporations that acquired a 3rd company all with different internal messaging systems. Sendmail is the only glue for all of the domains, auth, provisioning, and routing mess that this type of business activity can create.
2. There is a brand spanking new Sendmail O'Rielly book that was just released. It does cover the important topics. This is not a fun read.
3. This is an open source project. Like any other open source project, you can dream of shooting it or contribute. Maybe your size of function preferences don't apply to sendmail. You'll only know if you ask the sendmail developer community. They have always given me an accurate answer when I've questioned why some things were done in a certain way. It's usually not their fault, but they will ack if there is something they need to do.
I'm not sure how you have come to believe that sendmail has a bad design. That one sentence from the entire post does not support your assumption.
Sendmail led the concept of relay control (see antiSPAM stuff in the original post) because of the fact that it was there when the network (a.k.a. the internet) went through this change.
"Official" qmail has seen no development since 1997 so many modern features are not implemented (such as TLS) and I don't think there is any prospect of serious delvelopment from now on.
Take a look at an example installation at qmail.org. All those small programs need their own config files. The example install at qmail.org had 34 config files to configure
Sendmail is currently more likeley to keep up with the evolution of e-mail standards.
The sendmail open source has a 20+ year legacy. It has been rewritten 4 times from scratch. It's large feature set is a function of the equally large and diverse user community it serves. Believe it or not, some people still use the DECNet and UUCP delivery settings.
Sendmail continues to evolve, argueably more rapidly and for the better than any other Open Source MTA.
I think an anonymous post with an unsupported claim of a bad design is designed to spread FUD. I call that a bad design.
Sendmail gets a bad name sometimes from folks who gave up on it for various reasons (Too hard?). Sometimes some of these "administrators" can't tell the difference between a Message store and an MTA. /var/mail is not sendmail!
.com) and having an open relay was normal. Think ARPAnet.
/var/mail, etc...). Think scale and way beyond systems for only 10s of thousands or less.
I personally like the way the sendmail community handles these issues when they arise. 2 reports in a row is a bummer, but the frequency is exaggerated. I respect the fact that there are other open source MTAs and think they can be made to work well too (postfix, qmail, exim, etc...).
Please keep in mind that this MTA was around when the network was more of a community (not a lot of
Sendmail pioneered lots of the AntiSPAM/AntiSPAMMER features that are taken for granted today (advanced relay control, ip to dns a record verify, DNS blacklisting etc...).
There are reasons why many (think mega sized corporations around the world) use sendmail in front of their message store systems (Exchange, Notes, Cyrus,
It has/provides:
The ability to use LDAP information for routing.
The ability to use LDAP instead of a flat Alias file.
LDAP intelligence at the port 25 gateway (Think not have unreturnable bounce messages traveling all the way into the network and then getting stuck at your message store) A smart MTA at the gateway will break the connection and not waste time trying to pass the message through.
Pass based (w/crypt options) SMTP Authentication
Certificate base SMTP authentication
Unlimited relay control options (rule sets and milters)
Built in SMTP encryption (TLS/SSL) with support for PKI systems
Multiple queues and deterministic queuing (queue groups)
Fallback MX (this is huge for failover)
Mid-protocol conversation filtering (Milter, do all of your attachment stripping and message scanning without adding extra hops).
Capable of sending email just as fast as any other MTA without violating RFCs (do you really not want to commit your data to stable storage?) and putting your data at risk.
SMTP pipelining (why open a new connection each time?)
Active development with developers developing to the RFC/IETF's standards and the needs of today's internet.
Ability to be configured to avoid port 25 Denial of service attacks that other MTAs are vulnerable to.
My 2 pennies, just another opinion, now leaving verbose mode...
I would guess that the MUA that comes closest to meeting all of your requirements is Microsoft's Entourage which comes with Office X for Mac OS X. Entourage has no per message basis for image loading (that I know of). It is also not cross platform. IMAP standards are supported better than in M$ lookOut. I would call it the offspring of Outlook and a good standards based IMAP 4 client. GPG integration and Palm Sync are both available. I think it would be an interesting example if you ever get to writing your dream mail client. I don't use it anymore since Mozilla 1.3 runs much better now on OS X.
I do understand. The point I was trying to make was that your company's policy exists because control over that port, and the applications using it, is limited by what the IMAP server and MUA are able to do. Mozilla tls over IMAP is part of the solution. Certificate based authentication improves that enough to open the port in the firewall. BTW, this can also be used for SMTP auth and encryption. I'll assume they don't close port 25 because you receive inbound email. They just use an MTA that they trust (I hope).
I must admit that I do not understand what you mean about using mod_proxy and apache virtual hosts to get through your firewall without a web based MUA. I am familiar with the module and the web server, but without using a web based MUA and ssl you would just be un-securing the port for your company. Please forgive me if I am missing something obvious. Also, pure IMAP proxy daemons exist. I know of at least one that works well. Good luck with your search for a solution.
An IMAP Server and an MUA that can use certificates to authenticate people and TLS/SSL to encrypt their email activities is all you need here. Mozilla mail supports this and that's why it is still a very good MUA for business. The spinoffs never pay much attention to these features and end up with nice looking MUAs that cannot truly secure email routing and access. The company I work for can safely allow IMAP access without VPN or SSH because of this.