Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
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?
At 11:19 AM -0600 2002/08/27, Lyndon Nerenberg wrote:
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. -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
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
participants (3)
-
Brad Knowles -
David Schwartz -
Lyndon Nerenberg