So what's so bad about forwarding all tcp/25 traffic over that relay and
letting that relay decide if the MAIL FROM: is allowed to be relayed?
Because I want to send mail through my own SMTP server that speaks
STARTTLS and uses certificates that are under my control.
Maybe I don't want my email sitting around in your MTA queue for
your sysadmins to read.
Or maybe you just don't have a clue about how to configure and run
an MTA, therefore any mail I send through your enforced gateway
gets silently black-holed.
And if a client wants to mail from another domain which isn't relayed by
it's upstream ISP, he/she could ask it's ISP to do so.
Yes this will add an administrative hassle, but doesn't spam imply that
also?
Do you *honestly* believe what you wrote above? Do you have any experience
trying to actually get these sort of changes made? Can you provide
statistically valid numbers showing this is a realistic solution in
the real world? (Frankly, this proposal is so absurd I have to wonder
if you've even dealt with *an* ISP ...)
The Internet is a peer-to-peer network, whether you like it or not.
--lyndon
Lizzie Borden took an axe,
And plunged it deep into the VAX;
Don't you envy people who
Do all the things YOU want to do?
Because I want to send mail through my own SMTP server that speaks
STARTTLS and uses certificates that are under my control.
That's a valid concern. Indeed, that's exactly the sort of thing I will want to be doing in the near future.
Maybe I don't want my email sitting around in your MTA queue for
your sysadmins to read.
Given the volumes of mail that pass through these kinds of things, that's not likely to be a problem. More likely to be a problem would be the fact that the mail might sit there for a week before it gets retried a second time. That takes careful system engineering for load, making sure to retry old messages often enough, etc....
Or maybe you just don't have a clue about how to configure and run
an MTA, therefore any mail I send through your enforced gateway
gets silently black-holed.
I have a clue how to configure and run an MTA. This is my specialty. I still recommend setting up a transparent proxy for port 25, but if I set up a separate machine (or set of machines) for that function, I will probably do the same as AOL and explicitly request that this machine be on the MAPS RBL (and certain other blacklists).
So, yes. Most anything you send through that machine would definitely be black-holed, at least if I set up a separate system to handle that traffic.
The Internet is a peer-to-peer network, whether you like it or not.
That's changing, whether you like it or not. For that matter, whether I like it or not.
Maybe I don't want my email sitting around in your MTA queue for
your sysadmins to read.
Given the volumes of mail that pass through these kinds of
things, that's not likely to be a problem. More likely to be a
problem would be the fact that the mail might sit there for a week
before it gets retried a second time. That takes careful system
engineering for load, making sure to retry old messages often enough,
etc....
I'm afraid the technology to rapidly sift through large volumes of
information to search for specific areas of interest is widely available. It
is totally reasonable to not want to send mail through your ISP's mail
servers and perhaps directly to a trusted mail distributor over an encrypted
link. Of course, you can easily use a port other than 25 for this purpose.
The problem comes when the recipient tries to validate your origin address
against your secure mail server.
DS
Your secure mail server (i.e. me) just has to be named in a MAIL-FROM MX record. We do DNS for some of our customers, and can add this trivially; the others control their own zones. Works for me.
How would this stop the destination mailservers from rejecting the mail
forwarded by the secure server? Remember, the situation is that I don't trust
my ISP to see my outbound mail (because that's where warrants are likely to
be served or interception hardware would likely be surreptitiously inserted).
So I don't want my outbound mail passing through my ISP unencrypted.
And I can't just use an email address that is hosted by the secure mail
server, because then that's where the warrant will be served or the interest
will be focused, and my mail is decrypted there. Nobody inspecting the secure
link could necessarily even tell that it was mail that was going over it or
where it was actually decrypted -- the next hop could just be a forwarded
outputting encrypted data to the ultimate decrypter.
I don't think it's unreasonable to simply say that email can't provide this
kind of feature unless the recipient and sender are part of the system. And
in that case, all the problems go away because the recipient will do the
right thing and no intermediate mail servers that don't know what to do are
needed.
DS
Given this extraordinary requirement, either you wouldn't be my customer, or you'd better encrypt at the endpoint (though pipes leak best out the ends). Or you can pony up the money for your own host on a dedicated circuit so _it_ can be in the MAIL-FROM MX for your domain (of course you'll need your own domain), and then you and your ISP can argue about traffic analysis and acceptable use.
Still doesn't fundamentally break the proposal in hand, it seems to me. You always get to not publish the repudating information if you don't want people to use it.
I'm afraid the technology to rapidly sift through large volumes of
information to search for specific areas of interest is widely available.
Really? Where? I'd like to know what they are and where.
It
is totally reasonable to not want to send mail through your ISP's mail
servers and perhaps directly to a trusted mail distributor over an encrypted
link.
Fair enough.
Of course, you can easily use a port other than 25 for this purpose.
Indeed.
The problem comes when the recipient tries to validate your origin address
against your secure mail server.
Well, if you use TLSSMTP, I would think that would be resolved during the connection, by the authentication of the key.
I'm afraid the technology to rapidly sift through large volumes of
information to search for specific areas of interest is widely available.
Really? Where? I'd like to know what they are and where.
There are a few thousand people and more computers than you can shake a
stick at located at Fort Meade for just this purpose.
The problem comes when the recipient tries to validate your origin address
against your secure mail server.
Well, if you use TLSSMTP, I would think that would be resolved
during the connection, by the authentication of the key.
Who says the recipient's mail server has TLS capability? It's really the
same problem as what happens when joe@aol.com wants to send email with his
personal origin address from his work machine which has nothing to do with
the AOL network. Except it's a bit harder to solve because in the AOL case,
AOL could just offer some solution. The problem occurs when I have an
@aol.com email address but don't trust AOL to handle my outbound email.
Again, though, it's reasonable to say, "If you don't trust AOL to handle
your outbound email, then don't use an @aol.com address. You have to trust
them for inbound anyway."
DS
I'm not worried about Fort Meade for something like this. Moreover, this is not "widely available".