Harmeet, Danny, Good I see that you guys have the idea now. Given your more advanced SMTP knowledge, you can take it way further than I can.
I'd like to say one more thing in the defence of RUOR. Before I do that I'd like to remind you both that RUOR is also a reach-back query (it is not mail-header element): If all the differnet servers implemented it truthfully, then it would be good, we can all agree that. I think this is likely to be the massive majority case, because the open relay SMTP servers on the net are not there because the administrator is a malicious person, they are there because of ignorance and poor configuration. Hackers do not currenly mount trojan horse SMTP servers, they take advantage of other poorly configured ones. If we had a situation where one SMTP server could ask another RUOR, we have a simple RFC endorsed, if a little brute-force, way of rejecting incoming mail from servers that are possibly open relay. It is up to the administrator of the querying mail server to decide what to do with the mail item from non-RUOR servers. Email extremists could silently reject all email from non-RUOR mail servers. The overly trusting could accept all and perhaps not even do the RUOR query. Somewhere in the middle the attitude might be to accept it but email the sender back again with a warning about non RFC compilance and future blocking of their sending of email. Now I am sure that new techniques would be used once these holes are closed, but is that not the nature of hacking? We all think it weird that all other servers are given massive attention and their holes closed rapidly, but SMTP seems to have been given up on years ago. Regards, - Paul >>>If it is that the mail server accepts the incoming because it is >>>apparently from another server it trusts, maybe the second part of the >>>RFC could be used to tackle that. It reaches back, post connection, to >>>the mail server that was proportedly the sender, and checks the message >>>ID and a digest of the message with it. If that mail server replies >>>"whatare you on about?" then the mail was very craftily faked. >>> >>This is a sensible approach, but it would increase server workloads, as >> >they > >>would have to maintain lists of message_id's that they sent. >> > > >DYST seems like a good idea. > >One thing to remember though is that a message could be recieved from >MUA(Client) or fowarded from an MTA(Server). The 'Did you send this' cannot >be sent to clients. > >This combination should help out: >- SMTP Auth, >- Close Relay >- (DYST) Did You Send This. This command could be sent to servers with 2 >options (a) Message ID or (b) Message Digest. > >Some issues could be >Mail Servers need to remember the messages sent. This may be not that easy >to add to existing mail servers. Mail servers may need to mentain history of >messages sent for a guaranteed and agreed upon time span. 6 hours or 1 >day could be the timeout for sent messages. >If the recieving server has not been able to check a set of messages for >DYST >within the set time, the recievrng server must assume mail message has >passed DYST test. > >I will do a writeup on this over the weekend and send it to the list. It can >then be ignored/expanded/implemented as you all like. > >Harmeet > > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
