Doug has rediscovered the idea of closing open mail relays to prevent unauthorised use by outsiders sending to outsiders. This was a big thing in the early 90s when email became popular. Doug has also come up with the idea of adding the IP address of the originating client machine (not necessarily using SMTP) in a header so that an attempt can be made to identify it - e.g. Hotmail has done that for years. L. missing mail admin experience, I think. On Mon, 6 Jan 2003, Doug wrote: > I am apparently missing something here but I am going to give it a > shot anyway. > > You can tell the difference between 1, 2, and 3 because they all have > a different DNS/IP footprint. > > You can send email directly to the IETF mail server? Do you have an > account on that server? > > I myself use a SMTP server to send out my email. It goes from my email > client to the SMTP server I happen to be using and it then gets > relayed through the network until it reaches the destination email > server. > > The validation I have been referring to would take place between the > mail client and the originating server. The entire point would be to > verify the identity of the person sending the email or at least the > account it is being sent from. > > I am not suggesting that the destination email server should ask for > authentication for every email it receives before it relays it on to > another mail server or a client. I am saying that the originating > server should ask for it before accepting it and relaying it on to the > network. > > The originating server would then be able to assure correct header > information by not allowing an email to be sent unless the outgoing > email was tagged with the proper DNS/IP footprint (not that of an > unsecured proxy server or a spoofed IP) and a return/reply address > that is associated with the account that the client used to > authenticate with the server. This in effect means that you cannot use > a different return/reply address (or a fake return/reply address) that > cannot be traced back to your account on the originating server by the > recipient or an IP/DNS footprint that cannot be traced back to your > machine or a point on your network by the recipient. This is to force > the person sending the email to be accountable for the email sent. > > I am not suggesting that the recipient or even the relaying server > should be allowed to connect back to the originating mail server or > the client that sent the email. That would create security risks for > networks hosting mail servers and clients sending the email. > > I am suggesting that before someone drops an email onto an originating > mail server that the server should take what I consider to be > reasonable steps to authenticate the user and confirm their identity > and account status on that server. The server would then tag > information onto the email that would identify the machine on which > the email client that sent the email resides (not the information of > an unsecured proxy). In addition, the originating server should tag > information that identifies the account (on the originating > server/network) that the client used to send the email and force the > originating client to provide a valid reply address that is associated > with the account to the recipient of the email. > > I am not suggest that originating servers should be tagging the exact > virtual location of an inbound or outbound server to anything or > changing MX records to reflect the correct virtual location to the > outside world. In fact, if this is not done it helps keep those > outbound email servers hidden from the outside world and helps keep > malicious users from finding them and exploiting them in some way to > send their email without authorization. I do feel that I should be > able to identify the actual network on which that server resides so I > can contact someone there to help track down someone who is sending > spam. > > Does the above clear up any confusion? Is there anything I am missing > here? If so please tell me what because I would welcome the > opportunity to learn something new. There may very well be big gaps in > this plan I am just unaware of what they are so I welcome the > opportunity to learn that you or anyone may pointing them out would > bring. > > Doug > Dougxx2@carolina.rr.com > 704-721-0212 > > P.S. As a side note if anyone thinks this is not a proper forum for > exchanging ideas about this please do tell me. It is not my goal here > to disrupt anything. I am just trying to exchange some ideas with a > large body of professionals in the hopes of learning something and > hopefully contributing something helpful. I would also like to invite > the moderators of this forum to contribute what they think of this > line of discussion. If they think it is unproductive I would be more > than willing to drop it and never breath another word about anything > unless it falls into any guidelines they would like to set forth. > Please, anyone, do feel free to respond with anything you feel would > be helpful constructive or apropriate on this subject. > > > > ----- Original Message ----- > From: <Valdis.Kletnieks@vt.edu> > To: "Doug" <Dougxx2@carolina.rr.com> > Cc: <ietf@ietf.org> > Sent: Monday, January 06, 2003 3:36 PM > Subject: Re: namedroppers, continued > > >> I believe the answer to your first question is you would send mail > >> using > >>your own mail server not someone else's. Although...I do see unique > >> issues > >> involved in people using mail servers that are not part of their > >> network > >> (hotmail, yahoo...) to send email if they try to authenticate you > as > >> part of > >> their network before allowing you to send email. > >You're still missing the point. > > > >How do you tell the difference between: > > > >1) The IETF mail server sending for the IETF list. > >2) The large SUN box across the hall that's the main vt.edu mail > server. > >3) My laptop. > > > >Currently, my laptop will send directly to the destination. The > problem is > >that although it would be trivial to change it so that it uses the > central > >Virginia Tech mail hub, that doesn't fix your problem - there's still > no > >authenticator for the vt.edu mail server at your mail server > either.... > > > >Oh, and don't even suggest chasing MX records - the MX for vt.edu > points > >at one set of boxes, but you will almost certainly *NOT* get a > connection > >from them, as our outbound servers are at different addresses. And > no, we > >won't change this unless you first manage to get hotmail.com and > aol.com > >to not use different inbound and outbound addresses first, as they do > the > >same thing for the same reasons. > >-- > > Valdis Kletnieks > > Computer Systems Senior Engineer > > Virginia Tech > > > > _______________________________________________ > This message was passed through ietf_censored@carmen.ipv6.cselt.it, which is a sublist of ietf@ietf.org. Not all messages are passed. Decisions on what to pass are made solely by Raffaele D'Albenzio. > <http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood@ee.surrey.ac.uk>