Slashdot Mirror

Mail aliasing is a really great way to filter out based on who you gave your email to.
I don't know if you are familiar with "plus addressing", but it is available in postfix and let's you quickly create aliases on the fly. and you don't even have to use the plus sign if you think to many people are on to that with gmail offering it.
http://www.postfix.org/postcon...

With this one, simple trick I eliminated 80% of my spam. Spammers hate this trick! Read it now before they take it down.

It's better to do it now than 5 years ago. Because it's easier to so now.

Also for mailservers like Postfix they now support the use of DNSSEC+DANE-TLS-certificates:
http://www.postfix.org/TLS_REA...

This means: encrypted SMTP connections between mailservers and man-in-the-middle is not possible.

I can't stand web-based mail readers, so, yes, I do use a PC email client, and I think many others do for the same reason.
Furthermore, I couldn't stand to have to actively check for new email, so for me it's:

1. postfix with sender-dependent relay hosts and -authentication
2. fetchmail to periodically poll all email addresses i have for new mail, handing it the local postfix for delivery, which then "delivers" it to
3. procmail in order to sort the incoming mail into various maildirs, triggering
4. a script that watches ~/.maildir/new for new files, and if positive, puts a 'new mail' label into my WM's status bar, which causes me to fire up
5. mutt to read the mail. it doesn't even need to be compiled with IMAP/POP3 support this way, which is neat.

It's a bummer browsers haven't enabled DANE yet. You can try an experimental addon for firefox. Good news is Postfix supports DANE for email!

Fantasic example of code written in a procedural language (C) in an object-oriented way,with clear separation of responsibilities.

http://www.postfix.org/

The framework that Wietse created to structure Postfix is, from my perspective, a thing of beauty. I don't doubt that this has been done elsewhere, but Postfix is the first real example that I came across of a somewhat-large application structured in a very clean and understandable way.

Well worth spending some time perusing the code.

Any decent MTA will be able to handle aliases, this is by no means limited to internal mail systems. When you write to some.address@example.org, the destination SMTP server will look that address up. If it does not exist the message will be bounced with an error, if it is an alias for real.address@example org it will be delivered to just that account.

Yes, and IBM also originally wrote Postfix. Of course, using Postfix with Postgres is easy: http://www.postfix.org/PGSQL_README.html. Or apt-get install postfix-pgsql. I can't address whether than includes support for "hashes and Btrees", since I haven't tried, but seems implausible that it wouldn't. Postfix has been developed as open-source for a long time! OP does seem remarkably confused. But I'm not completely sure whether he's simply blaming the wrong company, or just plain wrong. I suspect the latter, but can't prove it.

This was a server to server connection, from one of Slashdot's SMTP hosts to my MX.

Connections to IMAP are also protected by TLS, but they look different - like this:

May 19 08:03:31 xxx cyrus/imaps[28590]: accepted connection
May 19 08:03:31 xxx cyrus/imaps[28590]: starttls: TLSv1 with cipher AES128-SHA (128/128 bits reused) no authentication
May 19 08:03:31 xxx cyrus/imaps[28590]: login: lan.xxx.com [vvv.www.xxx.yyy] tftp plaintext+TLS User logged in
May 19 08:03:31 xxx cyrus/imaps[28590]: seen_db: user tftp opened /var/lib/cyrus/user/t/tftp.seen

As you can see, here it's Cyrus who reports the login. TLS between SMTP hosts is handled by Postfix. There is not much in common between the two, except that Postfix delivers to Cyrus. When I send an email, my MUA uses TLS to connect directly to Postfix (the submission port, or 25/tcp.) It looks like this:

May 20 00:09:25 xxx postfix/smtpd[2239]: connect from lan.xxx.com[vvv.www.xxx.yyy]
May 20 00:09:25 xxx postfix/smtpd[2239]: setting up TLS connection from lan.xxx.com[vvv.www.xxx.yyy]
May 20 00:09:25 xxx postfix/smtpd[2239]: Anonymous TLS connection established from lan.xxx.com[vvv.www.xxx.yyy]: TLSv1 with cipher AES128-SHA (128/128 bits)
May 20 00:09:25 xxx postfix/smtpd[2239]: D47EC487ED2: client=lan.xxx.com[vvv.www.xxx.yyy], sasl_method=LOGIN, sasl_username=tftp
May 20 00:09:25 xxx postfix/cleanup[2243]: D47EC487ED2: message-id=<050401ce5529$0be9e0e0$23bda2a0$@xxx.com>
May 20 00:09:25 xxx postfix/qmgr[1394]: D47EC487ED2: from=<tftp@xxx.com>, size=2853, nrcpt=1 (queue active)
May 20 00:09:28 xxx postfix/smtpd[2239]: disconnect from lan.xxx.com[vvv.www.xxx.yyy]

Postfix is easy to configure to use TLS. CA-signed certificates give you nice log entries, but in general they are useless because it doesn't help anyone to know what company owns a given server. So I use self-signed certificates (make my own CA.) I then import that CA's certificate for IMAPS use.

Today it doesn't take any effort whatsoever, nor any money, to have all connections of your SMTP/IMAP server encrypted every which way. Many servers on the Internet are already configured this way - and all popular email hosts, like Google and Yahoo, are using TLS. The man with a tap at the router will not gather much.

If you run MS Exchange - even as the dirt cheap Small Business Server - then you get TLS included automatically. SBS generates a self-signed certificate, but you are encouraged to spend money on signed bits. (It is not required.)

It is no longer entirely true that e-mail is not encrypted. Many SMTP servers support encryption using SSL or TLS when communicating with another SMTP server. For example here is an example of an SMTP server receiving an e-mail from one of Google's gmail SMTP servers.

Aug 7 13:33:28 x postfix/smtpd[22642]: setting up TLS connection from mail-gh0-f182.google.com[209.85.160.182]
Aug 7 13:33:28 x postfix/smtpd[22642]: Anonymous TLS connection established from mail-gh0-f182.google.com[209.85.160.182]: TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)

I believe this behavior is defined by RFC 3207
If you manage a Postfix SMTP server and have not enabled TLS support I would suggest you read
http://www.postfix.org/TLS_README.html

It was apparently the only character thought to be unencumbered for this purpose at the time.

But it clearly wasn't, even at the time. It's too late now of course. It sounds ridiculously trivial, but it causes conflicts and ambiguity fucking everywhere an IPv6 address features in a script or config file or parameter, which has now led to the invention of using square brackets as additional quasi-standard outer delimiters for IPv6 (see: URLs, postfix config, shorewall (now - initially they picked something else), etc., etc.) - but unfortunately only most of the time, not always. If it was globally agreed "IPv6 address literal? let it begin with [ and end with ]", even if they kept the unfortunate colons, then you could at least write them unambiguously as part of larger strings featuring colons for other purposes, like so many command line args, config files and urls do.

At the very least, if you're implementing IPv6 support, please be aware of the de-facto conventional choice of [ and ] for extra outer delimiters, don't go inventing different ones like shorewall initially did (then fixed, to their credit).

Excellent point, and if I ever update that howto (it's in my GTD list - honest!), I'll recommend it highly. If you're using Postfix, check out its new postscreen server. It's so good that I dropped greylisting altogether.

An example from the config file:

query = SELECT forw_addr FROM mxaliases WHERE alias='%s' AND status='paid'

http://www.postfix.org/MYSQL_README.html

Already exists.

Can you give examples of good Exchange replacements?

Yes, for that see DVL. Seriously, though you have to define what activities you need to do before you can ask for a replacement. MS Exchange is marketed in many niches and fails (on the surface) in most. The most spectacular is its failure as a mail server replacement, if you look at it as such. If you look at the wonderful cover of plausible deniability it gives executives by randomly losing and delaying mail, then that is a success.

Anyway, try looking these. Keep in mind that, unlike with M$ products, you can combine pieces of several packages.

• Kolab — http://www.kolab.org/
• Citadel — http://www.citadel.org/
• Dingo Calendar Server — http://andrew.triumf.ca/dingo/
• Darwin CalendarServer — http://trac.calendarserver.org/
• Bedework — http://www.bedework.org/
• Zimbra — http://www.zimbra.com/
• OpenGroupware — http://www.opengroupware.org/

If you are simply looking to improve reliability of e-mail they a plain Mail Transfer Agent (MTA) will do. Before it became too embarrassing for M$, it used to be recommended practice to put one of these in front of MS Exchange to improve reliability and security. Also look up ClamAV, Spamassassin and how to do greylisting.

• simta — http://rsug.itd.umich.edu/software/simta/
• Dovecot — http://www.dovecot.org/
• Postfix — http://www.postfix.org/
• Exim — http://www.exim.org/
• Sendmail — http://www.sendmail.org/
• qmail — http://www.qmail.org/

However, before you can think about "replacing" MS Exchange, you will have to get rid of the staff that selected and deployed it in the first place. They ignored all the licensing shortcomings, the bad reviews, high price and ongoing technical failure to instead push ideology over technology. People making decisions based on ideology are not going to accept any technical or economic arguments...

Can you give examples of good Exchange replacements?

Yes, for that see DVL. Seriously, though you have to define what activities you need to do before you can ask for a replacement. MS Exchange is marketed in many niches and fails (on the surface) in most. The most spectacular is its failure as a mail server replacement, if you look at it as such. If you look at the wonderful cover of plausible deniability it gives executives by randomly losing and delaying mail, then that is a success.

Anyway, try looking these. Keep in mind that, unlike with M$ products, you can combine pieces of several packages.

• Kolab — http://www.kolab.org/
• Citadel — http://www.citadel.org/
• Dingo Calendar Server — http://andrew.triumf.ca/dingo/
• Darwin CalendarServer — http://trac.calendarserver.org/
• Bedework — http://www.bedework.org/
• Zimbra — http://www.zimbra.com/
• OpenGroupware — http://www.opengroupware.org/

If you are simply looking to improve reliability of e-mail they a plain Mail Transfer Agent (MTA) will do. Before it became too embarrassing for M$, it used to be recommended practice to put one of these in front of MS Exchange to improve reliability and security. Also look up ClamAV, Spamassassin and how to do greylisting.

• simta — http://rsug.itd.umich.edu/software/simta/
• Dovecot — http://www.dovecot.org/
• Postfix — http://www.postfix.org/
• Exim — http://www.exim.org/
• Sendmail — http://www.sendmail.org/
• qmail — http://www.qmail.org/

However, before you can think about "replacing" MS Exchange, you will have to get rid of the staff that selected and deployed it in the first place. They ignored all the licensing shortcomings, the bad reviews, high price and ongoing technical failure to instead push ideology over technology. People making decisions based on ideology are not going to accept any technical or economic arguments...

They already do. I've done support for W.A. schools that were having problems with their internal Exchange server. They were shocked when we discussed the 'real' price for Exchange. They paid less than $1000 for it including CALs and hardware. MS has some serious sweetheart deals for schools and I bet if it came down to providing even cheaper Windows and Office for schools they will do it.

That's not the real price, though. The real price also includes all the down time, extra re-builds, malware tools, etc. Add to that also the cost of missing incoming messages, missing outgoing messages and delayed messages -- these last add up to more work for the users, which can number in the 100's, rather than just the maintenance staff which can usually be counted on one hand.

Before MS Exchange was hammered through the back door, e-mail was both so fast and reliable that many used it in ways resembling instant messaging.

Worth a look:
Roundcube: http://roundcube.net/
Kolab: http://www.kolab.org/
Citadel: http://www.citadel.org/
Zimbra: http://www.zimbra.com/

If you need a plain vanilla mail transfer agent instead of all the non-essentials, then postfix, exim, qmail, the new sendmail, and simta each have their niche. They're used pretty much everywhere, even if you don't always see the evidence of them outside the message headers.

...once I started reading his replies on the postfix-user mailing list. He's extremely blunt. While many are VERY helpful and detailed, a number are a sentence or two long that, paraphrased, consist of "you're an idiot."

However, he's nothing compared to Victor Duchovni (who works for Morgan Stanley, and is a major poster on the postfix-users list). His signature, and I'm not making this up:

--
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Yeah, you read that right. 11 lines long...and this asshole thinks he's so fucking important, he lectures you about how to thank him so he can delete your acknowledgment/thank you as quickly as possible. He's often more willing to insult than help, and on numerous occasions, comes to the wrong conclusion. Worse still, he often presents his solution with complete authority and confidence, putting the helpless user on a primrose path.

The trick is to use the "header_checks" and "body_checks" to look for signs of the email having being sent out from your email server in the first place.

Specifically, the closed-source software vendors.

Consider: No matter how much marketing you have, it is ultimately up to the end user of a product to decide if they've gotten the value they expected to get. If said user finds that the closed-source product they paid (possibly) big bucks for isn't worth the media it was recorded on, they're going to cut their losses and try something else.

Alternatively, there are many small businesses that simply can't afford the kinds of prices that closed-source vendors often charge. I know this for a fact, because I'm one of those tiny businesses! If not for FreeBSD, Apache, and Postfix, to say nothing of the surplus hardware market, I would never have been able to get my Internet presence off the ground.

It's not just Freeware, either. How many of us have found low-cost Shareware products to be incredibly useful for the stuff we do, when comparable commercial products would have nearly required a second mortgage? Hex Workshop is, I think, a great example.

If that $60 billion figure is accurate, the commercial software vendors have no one but themselves to blame. Oh, there are some good values Out There, yes, but I think they've been largely drowned out by the flood of questionable products that are turned out with far more marketing than quality engineering.

Happy tweaking.

Postfix has plenty of options to deal with this issue.

The first is check_recipient_maps. See http://www.postfix.org/uce.html#smtpd_recipient_restrictions for details.

The second is reject_unverified_recipient. It is a way for it to check downstream MTA to see if it accepts the e-mail address. This is good for a filtering border MTA, which then passes to the the downstream server. It does this check before queueing. See http://www.postfix.org/ADDRESS_VERIFICATION_README.html#recipient for details.

Postfix has plenty of options to deal with this issue.

The first is check_recipient_maps. See http://www.postfix.org/uce.html#smtpd_recipient_restrictions for details.

The second is reject_unverified_recipient. It is a way for it to check downstream MTA to see if it accepts the e-mail address. This is good for a filtering border MTA, which then passes to the the downstream server. It does this check before queueing. See http://www.postfix.org/ADDRESS_VERIFICATION_README.html#recipient for details.

As an 'expert' system administrator (albeit unpaid) I have four servers. One is running Microsoft Windows Small Business Server 2003, one is running Microsoft Window Server 2003, one is running Ubuntu Linux 5.10 (Server), and the other is running Apple OS X Server (10.4).

I can tell you now that when I first started my company, although I was a major advocate of Linux, I soon found that I did not have the time to maintain a then Gentoo or custom LFS distribution, Debian was far too heavy to pick up, and Slackware felt a little dated. So I took a look at Microsoft Windows Small Business Server 2003, liked what I saw, and bought a Dell PowerEdge 400SC with an OEM install.

At first Small Business Server was a breath of fresh air. It was easy to maintain, with a full complement of features, having been bundled with Microsoft Exchange, Microsoft SQL Server, and Window Sharepoint Services. I actually enjoyed - yes, enjoyed - using it.

Until backup stated to fail. Until my tape drive disappeared. Until the sharepoint website database got corrupted. Until exchange monitoring failed. Until the POP connector started to thrash the CPU. Until the Windows Update website failed to check for updates.

These things happened. I'm not saying that they wouldn't happed with another system, but that is not the point, since they happened to me, and that caused me grief, and time, and money to resolve. I ended up trying to build a new system based on Microsoft Windows Server 2003, since I already had Microsoft specific data (files and tables), but this proved even more difficult to maintain.

I struggled for eighteen months, and then decided to build an Ubuntu 5.10 server. I use Ubuntu on one of my laptop, and had gently learnt the apt- way, and liked it. I set up a server with similar features to the Small Business Server, using Postfix, MySQL, and Plone, and even went some ways to transferring my sharepoint data. It works. It hasn't failed yet.

I bet the guys who took part in the survey only set up a server, installed some applications, and patched it. I bet they didn't try running a business for 18-months, just to see what it was really like.

I must say that we recently purchased an Apple PowerMac, and were so impressed we are now looking at completely switching, hence the OS X Server. It is a dream to install and configure, but we are going to run it for several months until we are satisfied that it can do the job.

Despite having never used Postfix or Dovecot before, in about five minutes of searching, I discovered http://code.softwarefreedom.org/projects/backports/browser/external/standalone/dovecot/current/doc/wiki/LDA.Postfix.txt which led me to http://www.postfix.org/master.5.html where it states a field of "-" requests that the built-in default value be used.. So now not only does God know what it means, so do I and now you.

If you think that's bad, try configuring sendmail one day. Mail servers are not exactly known for their user-friendly GUI tools, and I think it's a stretch to extrapolate from that about the state of Linux configuration in general. Using Active Directory compatibility as a benchmark is pretty unfair too, given how hard Microsoft tries to make that difficult for everyone else.

then I would be inclined to agree with Mr. Ranum's points. But the fact is that there are lots of people out there working on Real Security. Let's see, there's OpenBSD's work to integrate cryptography as a system service, there's Neils Provos' work on systrace, there's GCC's ProPolice stack-smashing protection, there's OpenBSD's write XOR execute protection (which, BTW, Windows now has to some small extent), there are phishing mitigation features in Firefox, there are Free implementations of good authentication systems (e.g., MIT Kerberos, Heimdal), lots of programs now ship with sane defaults (ala Postfix and qmail), there are safe-string libraries of all license stripes, and on and on and on! The fact that Microsoft apparently does not use their own safe-string implementation is indicative of the problem here. Microsoft writes crap. If you want systems where security is a real concern, it's easy to find it. That's not to say that those systems are "secure"-- security is always a work in progress-- but to say that "our responses to those problems also remain the same" is disingenuous. Projects like OpenBSD (among many others mentioned above) have attempted to identify entire classes of problems, and solve them on the big-picture level instead of doing the patch-a-week thing.

Oh dear God no. Chances are good that your MTA supports recipient delimiters which are vastly preferred to catchall addresses. For instance, slashdot@strauser.com will bounce, but kirk+slashdot@strauser.com will go right through.

Security through obscurity, sure, but no more so than is a catchall address and much less friendly to spammers.

A simple workaround is to simply send the message to every user in a different SMTP session. So no repeated RCPT commands means Hotmail will deliver them all, first time, every time.

In Postfix you can set this using default_destination_recipient_limit. Setting this to 10 would solve the problem as after 10 recipients, Postfix will deliver the DATA part and then start a new session for the remaining recipients. I am sure other MTAs will have a similar setting. (and if they don't they should)

I know that postfix runs chroot (in a lot of distro's anyway). I figured they had some solid technical reason for this, but it turns out they actually use this as asecurity mechanism (see here). They know that chroot jails can be broken out of, but they claim that 'every little bit helps'. My intuition says that 'every little bit helps' is not an effective way to think about security, though.

I use postfix, in which it's default behaviour. Although now that you mention it, the default settings are a little more lax than I'd prefer, so I'm going to tweak them a bit. I'm not sure what version this appeared in, but it's been around for an awfully long time. I think even the version in woody had this feature.

That said, it only tracks errors per-session; every new connection the client makes results in a reset counter. So, it could be improved. But making a new connection slows things down on its own.

http://www.postfix.org/rate.html#slowdown

> Email is not an encrypted protocol by default!
While that is true (ie. the default SMTP), there is also a provision for encryption (SMTPS) between mail servers. At work where I also manage the mail server, I have POPS, IMAPS and SMTPS. I have to also have SMTP since, like you said, most sites by default use unencrypted SMTP.
What is encouraging is that in the mail server logs, I do find that there are a number of mail servers out there that are willing to speak TLS and thus auto-negotiate encryption for email exchange. Since we only allow POPS and IMAPS, the email is a private conversation between the sender and the receiver for sites willing to speak TLS.
Since we are the techies here at /., and i'd imagine a bunch of us manage mail servers, if all of us enabled TLS for SMTP, over time, enough mail servers doing TLS would mean that email sniffing would be a thing of the past. (I realize this is a tall order for sites handling massive number of emails but for small to medium sites the additional burden of encryption would be peanuts)
It still does nothing for public servers like gmail - but then that's a conscious decision. You can very well run your own mail server or use PGP.
see this for further info: TLS for postfix

Man... I must have been doing something wrong when I wanted to add another domain to my email server, and just added it to the config file and restarted postfix. A server isn't "simple". That's why Windows gets pwned all the damn time, because they try to make services appear simple. They aren't. Learn a bit about it, do some reading, and you find out that these things really aren't that hard. Text file configs are a hell of a lot easier to deal with than random GUI controls placed seemingly randomly. Go ahead, try to change your computer's name on the network under Windows... it's not under networking configuration where you'd expect it to be, is it?

I also want to ask you... how hard is any of this to understand or get working? And it seems to cover almost anything you'd want to do.

I can implement any protocol I want. If it's similar to SMTP but not compatible with it, is this some sort of crime? Even if I'm a certified monopolist? I'd say no. Now if I claim that I implement a standard and am not compatible I could be sued for fraud or false advertising or something.
The idea of requiring that every protocol Microsoft implements is completely compatible with some standard is just silly. Especially when they can't even read an RFC:
    From http://www.postfix.org/SASL_README.html :
Older Microsoft SMTP client software implements a non-standard version of the AUTH protocol syntax, and expects that the SMTP server replies to EHLO with "250 AUTH=mechanism-list" instead of "250 AUTH mechanism-list". To accommodate such clients (in addition to conformant clients) use the following: /etc/postfix/main.cf:
                broken_sasl_auth_clients = yes

If the sender is forging your From address, chances are they're not using your mail server. Most decent blacklists (e.g. SpamCop, Spamhaus) will blacklist the offending server's IP address, not your mail domain.

Consider implementing SPF (home page wiki) so recipient mail servers can drop the message if it wasn't sent from a server authorized to send mail from your domain.

Most bounce messages will not include your outgoing server's signature. You can consider dropping those messages using the techniques described in the Postfix Backscatter Howto.

Easy...set up a linux box at home and install Postfix and Squirrelmail . These work great and will do as you wished.

Here's a good link for setting up virtual hosting before you put on the webmail front end.

Of course there is a replacement for Outlook and Exchange! It's called sendmail and it's part of every unix-like system. You install an MTA (either the original sendmail or a compatible replacement) and a POP3 server on a machine (an old desktop is fine), configure your firewall to route incoming traffic on port 25 to that machine, log into your DNS control panel, and set its internet hostname as the MX for your domain. Then you run a normal mail client on each desktop. Specify your mail server's inside IP address as the SMTP and POP3 server in your mail client, and away you go.

550 5.7.1 SpamAssassin score is too high.

(My SMTP response is worded somewhat politely because while the probability that the message is spam is quite high, the probability that the message is spam given that someone is reading my response is quite low. Write the message for the friendly mail administrator, not for the evil spammer.)

There are significant downsides to this approach, however. SpamAssassin is very memory-hungry. I can only be spam-checking so many simultaneously. This limits my mailserver's maximum concurrency. And if my system processes messages too quickly, the remote mailserver will give up on me and I'll have to go through it all again when they come back.

I used to say that everyone should be using this approach, but it's probably not realistic for large sites. They need to level out the load by inserting a queue between receipt and spam checking. That means accepting the message for delivery before knowing if it's good and thus bouncing it on failure.

What may be more realistic is rejecting bounces regarding messages that you know were forged. Your system can keep a database of all outbound Message-IDs, and bounces are in a well-defined format. (Aside from those stupid pseudo-bounces from the !@#$ virus checkers; I hate those.) If a bounce refers to a Message-ID that you haven't sent, the bounce can be rejected.

There is a Postfix backscatter HOWTO at http://www.postfix.org/BACKSCATTER_README.html

You start by rejecting outright email for non-existant email addresses. That gets rid of all bounces that come from addresses the spammers have made up. Then you look at the Received headers of the email that you supposedly sent and validate that it did indeed come from your IP and the header is of the form that your MTA generates. If not, somebody was impersonating you and you reject the bounce. See Stopping Backscatter Email.

Why shut down your home system? Why not have it available as a server to make your life easier? I agree with other posters about using "offline" mode of Thunderbird and like clients.

In case you're thinking that you have a particularly repressive ISP...

My ISP blocks ports 80 and 25 - particularly irritating, if you ask me. My ISPs TOS, if read to the letter, would mean that multiple browser windows or tabbed browsing are inappropriate because it's more than one session over the broadband pipe.
 
I agree that it would be ideal if I could use every port I want, block the ones I want to firewall - but I'm too cheap to pay for that kind of access.
 
So I work around it. I use dyndns [dyndns.com] to create a pointer to my dynamic IP address. My ISP does not block https or ssh ports, so I leverage those to get what I want.
 
I use cron, fetchmail [berlios.de],
  procmail [procmail.org],
  spamassassin [apache.org], and
  postfix [postfix.org] to bring mail from my ISP to my local system.
 
I use uw-imapd [washington.edu] to share my mail with other computers on my home network
 
I use ssh and pine, or apache+php+MySQL+https (self-signed cert) with roundcube [roundcube.net] to get remote access to my IMAP server.
 
I use WinSCP [winscp.net] to get access to my files at home when I'm at work. My data is *MINE* and I easily back it up (nightly and offsite qurterly - snapshot backups coming soon thanks to rsnapshot [rsnapshot.org], perl and rsync)
 
Every tool that I use is free of charge and as free as the GPL and apache licenses are free (zealots can feel free to argue with someone else about the relative freedom of the GPL, thanks.)
 
I certainly could pay for more open TOS with an ISP - I could even host my applications at an ISP. I'm cheap, and this solution works well enough for me.
Hope you find a solution that works for you!
 
Respectfully,
Anomaly

My ISP blocks ports 80 and 25 - particularly irritating, if you ask me. My ISPs TOS, if read to the letter, would mean that multiple browser windows or tabbed browsing are inappropriate because it's more than one session over the broadband pipe.

I agree that it would be ideal if I could use every port I want, block the ones I want to firewall - but I'm too cheap to pay for that kind of access.

So I work around it. I use dyndns to create a pointer to my dynamic IP address. My ISP does not block https or ssh ports, so I leverage those to get what I want.

I use cron, fetchmail,
procmail,
spamassassin, and
postfix to bring mail from my ISP to my local system.

I use uw-imapd to share my mail with other computers on my home network

I use ssh and pine, or apache+php+MySQL+https (self-signed cert) with roundcube to get remote access to my IMAP server.

I use WinSCP to get access to my files at home when I'm at work. My data is *MINE* and I easily back it up (nightly and offsite qurterly - snapshot backups coming soon thanks to rsnapshot, perl and rsync)

Every tool that I use is free of charge and as free as the GPL and apache licenses are free (zealots can feel free to argue with someone else about the relative freedom of the GPL, thanks.)

I certainly could pay for more open TOS with an ISP - I could even host my applications at an ISP. I'm cheap, and this solution works well enough for me.

Respectfully,
Anomaly

I know postfix can be configured to do this very easily.

Something along the lines of setting up an archive email address and then configuring always_bcc to that address.

I might add, it would be nice for people to REJECT spam rather than BOUNCE it. When you bounce it, innocent domains get an email complaining about the forged email. With these spambots, it adds up quick! Doing a reject also allows legitimate senders to discover their email was not delivered.

It would be nice, but unfortunately, that runs counter to the time-tested design of essentially every Mail Transfer Agent out there.

Any decent MTA will carefully ensure that the incoming mail message is written out, then signal acceptance of the message, marking that it is now solely responsible for delivery. If spam analysis engines are placed in between those two steps, then it introduces a soft real-time bottleneck and performance impact; it becomes straightforward to perform an email Denial-of-Service by thrashing the spam engine with a number of messages so the MTA can't accept more connections.

To be safe and efficient, then, MTAs will accept the message and drop the connection before performing any costly processing. Once they've done that, there's no way to reject the spam, it can only be dropped or bounced.

There's some discussion of this in the Postfix Content Inspection README. To wit:

Although [before-queue, external, medium-weight filtering options] appear to be attractive, they have some serious limitations that you need to be aware of. First, content inspection software must finish in a limited amount of time; if content inspection needs too much time then incoming mail deliveries will time out. Second, content inspection software must run in a limited amount of memory; if content inspection needs too much memory then software will crash under a peak load. Before-queue inspection limits the peak load that your system can handle, and limits the sophistication of the content filter that you can use.

Simple. Like this,

80.190.252.0/24 550 spam not allowed

(for exmaple)

See this for more info,
http://www.postfix.org/access.5.html

The better place to looks is the Howtos and FAQs.

One of my favorites: http://jimsun.linxnet.com/misc/postfix-anti-UCE.tx t

We block somewhere around 200k spam emails a day. And we have a very similar setup sitting in front of our Exchange server. The kinds of things we can do with Postfix simply aren't possible with Exchange, and once we learned the ins and outs of Postfix, we found it to be easier to use than Exchange. For one, Postfix has real documentation. Not to mention that the main developer posts regularly on the mailing list. Ever talk to MS's corporate support people for Exchange? Exchange is so huge and complex no one person knows the entire program. Postfix is a model of simplicity by comparison.

Dude! Nobody likes Sendmail. That's why they use things like Exim or Postfix. Getting a legit version of Advanced Server 2003 is serious overkill if you just need a mail server.

Having to 'compile' the configuration file is such a farce that I could nearly hear the Laurel and Hardy theme playing whenever I messed around with it. On top of that, the 'compiled' config files have that retarded boilerplate to the effect of "By using this file, you agree to our licence, bloobloobloobloobloo must stuff face with butter". Licence 'agreements' are irritating enough in the best of times; when combined with Sendmail hassles, they're downright unsanitary! So after the nth r00t-clean-patch cycle, I finally got a clue. Hail Postfix! All bow down and praise Postfix! We're not worthy, we're not worthy!

http://www.postfix.org/postconf.5.html#canonical_m aps
http://www.postfix.org/generic.5.html
http://www.postfix.org/ADDRESS_REWRITING_README.ht ml
http://www.postfix.org/transport.5.html

Pretty trivial stuff.

http://www.postfix.org/postconf.5.html#canonical_m aps
http://www.postfix.org/generic.5.html
http://www.postfix.org/ADDRESS_REWRITING_README.ht ml
http://www.postfix.org/transport.5.html

Pretty trivial stuff.

http://www.postfix.org/postconf.5.html#canonical_m aps
http://www.postfix.org/generic.5.html
http://www.postfix.org/ADDRESS_REWRITING_README.ht ml
http://www.postfix.org/transport.5.html

Pretty trivial stuff.