[snowwrestler]

Blacklists are run by anti-spam zealots who really don't care about what is fair or a smart idea.

For example my employer's mail server--which has been sending legitimate person-to-person emails for years (no bulk)--has ended up on blacklists several times because some blacklist operator decided to black-hole an entire netblock at our ISP.

From the blacklist operator's perspective, the broad effect of the block is intended to cause headaches for a ISP as a form of punishment for allowing outbound spam. Our deliverability (and many others) was just cannon fodder for that fight.

[overbroad]

I wish we could get these anti-spam zealots to apply the same effort to stopping junk postal mail. The history of direct mail is interesting and perhaps instructive. It has been kept alive by those who do the delivery (cf. those who do the sending). I have sometimes wondered if the same might be true for email.

If your emplyer knows its recipients (e.g. business partners) and can coordinate with them to run an SMTP service for recieving and sending messages on a different port, would that solve the problem?

[snowwrestler]

This is not a workable solution because the problem is not based on what port SMTP is running on. Organizations and ISPs voluntarily subscribe to email blacklists because they are desperate for any help in reducing spam volumes. They would filter email coming from blacklisted IPs regardless of what port it came in on.

You're basically proposing a whitelist solution, which has many known problems: it does not scale well; it does not handle new or unexpected email partners; it relies on the simultaneous cooperation of all parties; etc. In this particular case it also relies on spammers remaining ignorant of the new port for SMTP--which seems unlikely.

[overbroad]

The problem is the open internet. There are ways to establish connections to a peer-to-peer overlay that take this out of the equation. The ISP is unlikely to block UDP traffic on some high port. Throttle perhaps, but not block. That gets us around the port issue. Once you log on to the overlay, the ISP only sees one port.

Then we are free to do our SMTP of other messaging as we desire. Each connected machine can choose what ports it wants to listen on, if any.

And what if this does not need to scale? What if it's only being used for a small group of people? What if all the people know each other? A very specific but very common use case. Not everyone is a celebrity with a gazillion "friends". Nor is everyone constantly conversing with new acquaintances. Some people have old friends and family. So I've heard.

Is it worth the spammer's time to try to find an SMTP daemon for each indivdual email address? Under the current system, things are centralized enough that a spammer can spam hundreds, thousands or even hundreds of thousands of recipients via sending to a single SMTP daemon.

Spammers have to send enormous amounts of spam to be successful. Having to do extra work to find an SMTP daemon just to send email to one recipient, and have to do this repeatedly, seems like it would not be worth a spammer's time. At least, not when it's so easy to just spam people that are using email the usual way: allowing some third party to handle their mail.

[DanBC]

If his employer knows the recipient the employer can ask the recipient to either stop using the block list, or to poke a whole in it and whitelist their email.

[overbroad]

Are you suggesting his employer doesn't know the recipients? Hmm, if true, I wonder what sort of email that might be.

Not the type I'm interested in.

[DanBC]

Read the thread again.

> For example my employer's mail server--which has been sending legitimate person-to-person emails for years (no bulk)--has ended up on blacklists several times because some blacklist operator decided to black-hole an entire netblock at our ISP.

You replied:

> If your emplyer knows its recipients (e.g. business partners) and can coordinate with them to run an SMTP service for recieving and sending messages on a different port, would that solve the problem?

That solution introduces a bunch of problems: you're running more software that's open to the Internet and thus introducing insecurity; you're asking people (who might not be technical) to install and run software and use a different mechanism when they want to communicate with a subset of users.

The other solution is to just ask the people that you're sending email to, but who are using a whitelist / block list to add you to the white list or exclude you from the block list.

[overbroad]

You're making assumptions. About how things would work and about users and what they can and cannot do. Typical online discussion. Lots and lots of assumptions.

I do not understand your last sentence. Didn't he say his ISP is blocking outgoing mail? The recipients are powerless to unilaterally change that situation.

Think about this for a moment. Forget the corporate example. Imagine one user has a daemon listening for mail (no setup, it's all been set up for him:- it's "built-in" to his OS). Imagine there is an authentication method e.g. a shared secret and perhaps even some obfuscation like port knocking to hide the open port. Even assuming a determined spammer can get past this, is it worth his time? He will reach a grand total of one user.

We can even use a small overlay, where the IP addresses are private, not routable on the internet. The spammer needs to get into the overlay network first, again defeating things like shared secrets or perhaps private keys to identify machines before he can even get a shot a access to a listening mail daemon. That's not easy to do if the users stay logged in. And again, if the network is small, with a few hundred users or less, maybe only a handful, is it worth his time?