So, in other words, it's ok to rant and stomp our feet about the end-to-end
architecture and how critical it is to support in order to diss NAT, but
we're required to ignore it when discussing SMTP?
If you are sending direct SMTP on behalf of your domain from essentially random locations, how are we supposed to pick you out from spammers that do the same?
Use your MX or SPF senders as your outbound mail agent, especially if they are properly configured with full DNS records so we can tell they are the correct machines to be sending on your behalf, or expect that you will get more mail bounced and lost than the average user because you are being unpredictable and unverifiable.
This is why tcp port 25 filtering is totally effective and will remain so
forever. Definitely worth breaking basic function principles of a
global communications network over which trillions of dollars of commerce
occur.
But as someone pointed out further back on this thread people who want to
have their mail servers available to people who are on the other side of
port 25 filtering just use the alternate ports. So then what does filtering
port 25 accomplish?
1. Restricting outbound port 25 is nothing new. It's been in use since before SPF or DKIM were under development, yet it hasn't been defeated/bypassed. Henry didn't specify whether the DKIM-valid messages he received were forged or if they just came from a random spam domain. If the latter, of course that's trivial for spammers to make appear legitimate because the only goal of such systems is to verify that the sender controls or is approved by the domain the message claims to be from.
2. The reason port 25 blocks remain effective is that there really isn't a bypass. If you want to spam, at some point you must establish a TCP connection to port 25 on the destination mail server. You can either do this from your own machines (where a good hosting provider will cut you off in a hurry) or by using someone else's illegitimately. Servers tend to be located in datacenters where again a good provider will take action, so botted end-user machines are obviously a huge thing to spammers. Eliminate the ability for the majority of those bots to make said port 25 connections, you've now forced them in to a much smaller operating area where they're more likely to be found. The only "bypass" is to go back to using their own machines or compromised equipment on higher-grade connections.
The alternate port 587 is for users of that mail server to send mail through it, presumably authenticated, not for receipt of random mail from the internet. This allows those users to relay email through their server unaffected while behind a port 25 block. Configuring it to accept all messages on that port would defeat the purpose.
Which is why DKIM does not really address any concerns. The spammers
have reduced its value.
I am retired now, but do run my own mail server from home. It is a
challenge. Not all static IP's provided by ISP's are outside of "home
IP groups", so you will find some of them blocked at some large domains.
SPF and DKIM do help, a bit. What I have found really makes the home
MTA possible are
1. a "real" static IP
2. proper DNS (A and PTR; PTR must at least exist)
3. tuning your MTA to respect the restraints of various large ISP's
Lacking 1 & 2, it is just not worth the effort attempting direct
delivery, if you value actual delivery of your email. I would never
even attempt such from a peripatetic laptop.
Well, if you've got proper forward and reverse DNS, and your portable SMTP server identifies itself properly, and you are using networks that don't filter outbound port 25, AND you have DKIM configured correctly and aren't using it for a situation for which it is inappropriate, then you'll get the same results with a portable SMTP server that you would sending through a properly configured static server.
So, no, "use DKIM" does not address the delivery difficulties inherent to using a portable SMTP server.
My how the goalposts are moving. DKIM solves the problem of producing
a stable identifier for a mail stream which is what your originally positioned
goalposts was asking for. It also makes reverse dns lookups even more
useless than they already are.
"Use your MX or SPF senders as your outbound mail agent, especially if they are properly configured with full DNS records so we can tell they are the correct machines to be sending on your behalf, or expect that you will get more mail bounced and lost than the average user because you are being unpredictable and unverifiable."
That you so conveniently trimmed from the post that you replied to.
Just putting the goalposts back where I left them.
Proper DNS configuration is essential to reliable SMTP delivery. SPF and DKIM can help ensure you don't get mistakenly tagged as a spammer, but they are no substitute for proper technical configuration of your mail server, and you don't get proper configuration if you are using other people's networks.
I suspect your ISP is also stripping <sarcasm> tags. Let's try it out
again:
You can tell that tcp port 25 filtering is a highly effective spam
mitigation technique because spam levels have declined in direct
proportion to their level of deployment. Today, we barely see any
spam on the internet due to amazing ability of these filters to
prevent bad people from sending bulk email.
Was that properly marked? Or this one?
Since tcp25 filtering has been so successful, we should deploy
filters for everything except tcp80 and tcp443 and maaaybe tcp21 --
but NAT already does so much to enhance the user experience there
already. And what with ISP customers using their provided DNS and
mail service exclusively, there's no reason to permit udp53, tcp110,
tcp143, tcp993, tcp995 either. Really, only evil people use anything
but the web. Any other traffic undoubtedly a bot from which they
ought to be protected.
Thing is, spam levels *are* down a good 20% in the last couple years,
that being about the time ISPs began doing this. More, 20% *is* in
rough proportion the impacted customer counts on the handful of cable
and DSL providers that implemented it.
And if you remind me that correlation is not causation I'll have to
point out the same flaw in your more sarcastic version.