From: SMTP%"MX-List@WKUVX1.WKU.EDU" 22-DEC-1994 10:22:55.09 To: EVERHART CC: Subj: RE: MXmas wishlist - some remarks X-ListName: Message Exchange Discussion List Warnings-To: <> Errors-To: owner-mx-list@WKUVX1.WKU.EDU Sender: owner-mx-list@WKUVX1.WKU.EDU X-Newsgroups: vmsnet.mail.mx Subject: RE: MXmas wishlist - some remarks Message-ID: <3dc1g9$p7u@gap.cco.caltech.edu> From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) Date: 22 Dec 1994 14:12:25 GMT Reply-To: MX-List@WKUVX1.WKU.EDU Distribution: world Organization: HST Wide Field/Planetary Camera NNTP-Posting-Host: sol1.gps.caltech.edu Lines: 60 To: MX-List@WKUVX1.WKU.EDU X-Gateway-Source-Info: USENET In article <0098951E.B9B92D6A.1@vms.gmd.de>, Juan Altmayer Pizzorno writes: ="Mario Meyer, Phys.-Techn. Bundesanstalt" writes: = =>I'd like to have more restrictive SMTP protocol validation. =>If HELO-domain doesnt match the partner it should be possible =>to abort the transfer or to generate an audit message. =>To find violations I must analyze all SMTP-Server-DEBUG-logs now, =>when a sender tries to hide or modify his location. => =>[...] => =>I know: this is a common SMTP problem. I only want to be alerted to avoid =>escalation. My assumption is, that this would require only little =>modifications for MX. A switch for SMTP server "cancelifnotverified" may be =>appropriate in the future and added to MX easily too. = =(I've been too busy for MX-List lately, so I may have missed a previous =response; Hopefully I'm not repeating a previous response) = =Indeed it would take just a trivial modification to MX's SMTP Server to make =it reply "501 HELO domain doesn't verify", since it does look up the HELO =domain already. Unfortunately, that change won't help you much, because =only SMTP connections opened *directly* to your server would be verified. =The faker would simply have to open a SMTP connection to some other server, =anywhere in the world, and in 99.999+% of the cases that server will be happy =to forward the message to your server (and that would succeed, since it would =come from an "official" server.) Looking at Received: lines might help =detecting the source (if a message with a local users' From: comes with =several Received: lines, I'd doubt it really comes from the local user), but =Received: lines can be faked as well (you can insert more Received: lines =to make tracing harder). It's much worse than that: The forger would merely have to connect directly to his machine, use the correct name of his system in the HELO line, and use the bogus address in the "MAIL FROM" line. The system will accept that without complaint, and will use thee "MAIL FROM" information for the return address. This behavior is an integral part of the way mail systems which honor MX records in the domain server databases work. Once again: The software change he wants has absolutely nothing to do with eliminating the problem he wants to deal with. It you don't believe me, try it yourself: Telnet to port 25 of a system with an SMTP serever, and enter the following: HELO {your host name} MAIL FROM: nobody@nowhere.nodomain RCPT TO: {your e-mail address} DATA . QUIT If you want to be a bit more clever, include some Received: lines in the body of the message as you send it, to make it look as if your system received the mail from elsewhere and was simply forwarding it along. -------------------------------------------------------------------------------- Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My understanding of astronomy is purely at the amateur level (or below). So unless what I'm saying is directly related to VAX/VMS, don't hold me or my organization responsible for it. If it IS related to VAX/VMS, you can try to hold me responsible for it, but my organization had nothing to do with it.