With MailHop Backup MX they have no way to validate addresses
Not necessarily. Backup MX services could do address validation if they're given a userlist. Of course, this entails some security concerns (example: why trust a backup service with a userlist?), but that can be figured out satisfactorily (answer: use a backup service you can trust, and engineer a secure solution).
Further thoughts:
There is little reason to avoid address validation these days. As for the argument against address validation -- that spammers can determine valid addresses by seeing which ones don't fail, and that's a reason not to validate -- that's not much of an argument:
- Accept and discard, and spammers think all addresses are real.
- Accept and generate an NDR, and spammers never get it, because their sender address/domain is usually bogus.
- Reject unknown addresses, and reduce massive CPU overhead from spam/virus-scanning. Bonus!
Finally, implement some form of connection throttling based on address validation. Some connection's doing what appears to be a dictionary attack, trying a jillion usernames starting with the "a"s? Or even multiple connections doing it, subdividing the alphabet between themselves? Trip a threshold of, say too many connections or too many bad recipients per minute, and refuse further SMTP connections from the given IP address -- or even slip it into a packet-filter rule to blackhole -- for an interval of time, and the problem's solved.
Once spam makes it past the DNS blocklists, the connection throttling, etc. there's enough intelligence in the anti-spam middleware to accurately identify the ham from spam 99% of the time or better.
And of course there's DomainKeys Identified Mail (DKIM) which is now RFC 4871 and is excellent for this middle section of the anti-spam defense wherein one also has to determine whether a message is an elaborate phishing scam or the real deal. SpamAssassin can do a bit of this as well as SPF, etc., and there's a high-performance dkim-milter implementation on sourceforge, too.
SMTP isn't dead, just a tad more complex on the server level, and defenses are improving against the soft areas of the protocol. What I've suggested works pretty darn well as a starting point.
> The reason Exchange uses a database can be summed up in three words: Single Instance Store.
Or, on Unix, you could just use hard links for a given message to multiple recipients -- as long as their mailboxes reside on a single partition. (Hard links don't span filesystems.)
> Run sshd on a different port. The scripts won't find you there. I don't like this option, > because it requires me to specify the alternative port every time i ssh, scp, rsync, > or svn. It's still about the easiest and most effective method.
Just create a.ssh/config file for your host and spec the port there, along with other neat-o options. See ssh_config(5).
Semantics, please. Most water we drink today comes directly from wells and reservoirs, not sewage treatment plants.
Sewage treatment plants pipe the processed water back into various bodies of water, which through the act of evaporation, precipitation, etc. end up back in our reservoirs.
Using X across the Internet is a pain. Why not run Mozilla locally and use its automatic-proxy feature to redirect internal-work URLs to the localhost ssh port forward?
Works great for me. Automatic proxy comes in the form of a proxy.pac file, and you specify characteristics of URLs, hosts, IPs, etc. that require direct/redirect/other actions. Google can help you find the details.
My biggest gripe with X is that remotely spawned windows don't reward you with instant mouse- and keyboard-event gratification. Now that I think about it, I have the same issues with Java browser-side applets and interfaces that are butt-slow because of the latency in toggling the widget appearances. (Hope that made sense.)
The storage method has nothing to do with the mail-user agent reading the mail. If the MUA speaks IMAP, and the server speaks IMAP, then the server just relates the IMAP command to the filesystem/database and presents the mail to the MUA.
Conceptually, only the email protocol matters between the client and server.
2. I migrated from a Linux laptop to an iBook running MacOS X. vi and emacs run on OS X. So does XFree86. Aside from some speed issues, MacOS X is pretty much a complete solution.
Or you could just connect via ssh to a localhost-only IRC server and yak to friends there..
Link a few of those localhost-only IRC servers together via ssh tunnels, and voila, secure network. However, accounts on the machines hosting the IRC servers are required.
Given the above, one could create an account with the shell pointing to an IRC client binary, so specific user accounts wouldn't always be necessary.
The pro: Don't have to retrofit existing IRC clients on any platform for SSL or other PKI compatibility. Just ssh forward ports 113 (identd) and 6667 (ircd), and point your favorite program to localhost on 6667. Or whatever port on which you've got ircd listening.
The con: You need an account on the localhost-only IRC server's host.
Email headers are generated for a good reason: mail routing depends on knowing the path from whence mail came. Otherwise, where do mail bounces go? And what happens when errant or spam mail originates from within an internal network? How do you tell which internal machine spouted the mail?
As another poster said, any attempt at obscurity (especially in this case) results in an exponentially greater burden of maintenance.
MTA-to-MTA encryption protocol : STARTTLS. It doesn't specifically encrypt the body as does S/MIME and PGP/MIME, but it encrypts the entire MTA-to-MTA session. However, once the mail reaches another MTA that doesn't support STARTTLS (or doesn't have the SSL/TLS certs from the connecting server) the mail is in plaintext. There are a few RFCs for STARTTLS in IMAP and MTA if you want to look into that.
STARTTLS answers all of your requirements as stated. Sendmail 8.11+ in particular is very good with STARTTLS and notes whether one, several, or all of the MTA-MTA connections in a given message's route used STARTTLS successfully.
Side note: if you are concerned about performance and security in Sendmail, look no further than 8.12b10. I've heard it rips postfix to shreds and drops setuid entirely now.
I read up on the Solaris VM model a few days ago while trying to debug some Solaris boxen at work. It's an interesting read and covers the basic VM model and system diagnostic tools, including helpful detail of vmstat(1). Not as straightforward as Mr. Dillon's excellent FreeBSD VM article, but worth the look for comparison purposes.
The link to the PDF file is the first one on this page; check out the others as well if you're interested in finding out about more Solaris internals:
I'm a systems administrator at a large ISP in Tokyo, and we completed our first few rounds of systems testing and nervous anxiety after the 2000 rollover.
Nothing to report, which is good. One interesting note, perhaps: I was asked to power down the Linux systems a few minutes before midnight because if the power went out, the filesystems would take too long to fsck (we have a large RAID connected to a couple of them).
No power outages, sewage overflows, or anything abnormal. I'm ready to pop this bottle of Möet champagne now!
Slashdot Mirror
Whoops. Remind me to read an entire post before replying. I see you've covered what I just said.
I agree that standards to present userlists would help increase adoption of address validation on secondary MXes.
Not necessarily. Backup MX services could do address validation if they're given a userlist. Of course, this entails some security concerns (example: why trust a backup service with a userlist?), but that can be figured out satisfactorily (answer: use a backup service you can trust, and engineer a secure solution).
Further thoughts:
There is little reason to avoid address validation these days. As for the argument against address validation -- that spammers can determine valid addresses by seeing which ones don't fail, and that's a reason not to validate -- that's not much of an argument:
- Accept and discard, and spammers think all addresses are real.
- Accept and generate an NDR, and spammers never get it, because their sender address/domain is usually bogus.
- Reject unknown addresses, and reduce massive CPU overhead from spam/virus-scanning. Bonus!
Finally, implement some form of connection throttling based on address validation. Some connection's doing what appears to be a dictionary attack, trying a jillion usernames starting with the "a"s? Or even multiple connections doing it, subdividing the alphabet between themselves? Trip a threshold of, say too many connections or too many bad recipients per minute, and refuse further SMTP connections from the given IP address -- or even slip it into a packet-filter rule to blackhole -- for an interval of time, and the problem's solved.
Once spam makes it past the DNS blocklists, the connection throttling, etc. there's enough intelligence in the anti-spam middleware to accurately identify the ham from spam 99% of the time or better.
And of course there's DomainKeys Identified Mail (DKIM) which is now RFC 4871 and is excellent for this middle section of the anti-spam defense wherein one also has to determine whether a message is an elaborate phishing scam or the real deal. SpamAssassin can do a bit of this as well as SPF, etc., and there's a high-performance dkim-milter implementation on sourceforge, too.
SMTP isn't dead, just a tad more complex on the server level, and defenses are improving against the soft areas of the protocol. What I've suggested works pretty darn well as a starting point.
Huh? The "Security" link on the front page of http://sendmail.org/ works fine.
> The reason Exchange uses a database can be summed up in three words: Single Instance Store.
Or, on Unix, you could just use hard links for a given message to multiple recipients -- as long as their mailboxes reside on a single partition. (Hard links don't span filesystems.)
> Run sshd on a different port. The scripts won't find you there. I don't like this option,
.ssh/config file for your host and spec the port there, along with other
> because it requires me to specify the alternative port every time i ssh, scp, rsync,
> or svn. It's still about the easiest and most effective method.
Just create a
neat-o options. See ssh_config(5).
Semantics, please. Most water we drink today comes directly from wells and reservoirs, not sewage treatment plants.
Sewage treatment plants pipe the processed water back into various bodies of water, which through the act of evaporation, precipitation, etc. end up back in our reservoirs.
Using X across the Internet is a pain. Why not run Mozilla locally and use its automatic-proxy feature to redirect internal-work URLs to the localhost ssh port forward?
Works great for me. Automatic proxy comes in the form of a proxy.pac file, and you specify characteristics of URLs, hosts, IPs, etc. that require direct/redirect/other actions. Google can help you find the details.
My biggest gripe with X is that remotely spawned windows don't reward you with instant mouse- and keyboard-event gratification. Now that I think about it, I have the same issues with Java browser-side applets and interfaces that are butt-slow because of the latency in toggling the widget appearances. (Hope that made sense.)
IMAP, shared folders and ACLs.
RFCs 2086 and 2342.
The storage method has nothing to do with the mail-user agent reading the mail. If the MUA speaks IMAP, and the server speaks IMAP, then the server just relates the IMAP command to the filesystem/database and presents the mail to the MUA.
Conceptually, only the email protocol matters between the client and server.
1. Use VirtualPC. 5.02 is particularly snappy.
2. I migrated from a Linux laptop to an iBook running MacOS X. vi and emacs run on OS X. So does XFree86. Aside from some speed issues, MacOS X is pretty much a complete solution.
Or you could just connect via ssh to a localhost-only IRC server and yak to friends there ..
Link a few of those localhost-only IRC servers together via ssh tunnels, and voila, secure network. However, accounts on the machines hosting the IRC servers are required.
Given the above, one could create an account with the shell pointing to an IRC client binary, so specific user accounts wouldn't always be necessary.
The pro: Don't have to retrofit existing IRC clients on any platform for SSL or other PKI compatibility. Just ssh forward ports 113 (identd) and 6667 (ircd), and point your favorite program to localhost on 6667. Or whatever port on which you've got ircd listening.
The con: You need an account on the localhost-only IRC server's host.
Email headers are generated for a good reason: mail routing depends on knowing the path from whence mail came. Otherwise, where do mail bounces go? And what happens when errant or spam mail originates from within an internal network? How do you tell which internal machine spouted the mail?
As another poster said, any attempt at obscurity (especially in this case) results in an exponentially greater burden of maintenance.
MTA-to-MTA encryption protocol : STARTTLS. It doesn't specifically encrypt the body as does S/MIME and PGP/MIME, but it encrypts the entire MTA-to-MTA session. However, once the mail reaches another MTA that doesn't support STARTTLS (or doesn't have the SSL/TLS certs from the connecting server) the mail is in plaintext. There are a few RFCs for STARTTLS in IMAP and MTA if you want to look into that.
STARTTLS answers all of your requirements as stated. Sendmail 8.11+ in particular is very good with STARTTLS and notes whether one, several, or all of the MTA-MTA connections in a given message's route used STARTTLS successfully.
Side note: if you are concerned about performance and security in Sendmail, look no further than 8.12b10. I've heard it rips postfix to shreds and drops setuid entirely now.
Jubal
I read up on the Solaris VM model a few days ago while trying to debug some Solaris boxen at work. It's an interesting read and covers the basic VM model and system diagnostic tools, including helpful detail of vmstat(1). Not as straightforward as Mr. Dillon's excellent FreeBSD VM article, but worth the look for comparison purposes.
The link to the PDF file is the first one on this page; check out the others as well if you're interested in finding out about more Solaris internals:
http://www.sun.com/sun-on-net/perfo rmance/
----
Jack of all trades, master of none: http://whole.net/~pup/
I'm a systems administrator at a large ISP in Tokyo, and we completed our first few rounds of systems testing and nervous anxiety after the 2000 rollover.
Nothing to report, which is good. One interesting note, perhaps: I was asked to power down the Linux systems a few minutes before midnight because if the power went out, the filesystems would take too long to fsck (we have a large RAID connected to a couple of them).
No power outages, sewage overflows, or anything abnormal. I'm ready to pop this bottle of Möet champagne now!
----
Jack of all trades, master of none: http://whole.net/~pup/