Date: Mon, 8 Sep 1997 20:54:54 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: gurney_j@resnet.uoregon.edu Cc: hackers@hub.freebsd.org Subject: Re: spam and the FreeBSD mailing lists Message-ID: <199709082054.NAA07610@usr09.primenet.com> In-Reply-To: <19970907200445.27869@hydrogen.nike.efn.org> from "John-Mark Gurney" at Sep 7, 97 08:04:45 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > This neglects the case of a machine acting as the domain for which it > > is a member in order to send mail. > > oh, your talking about if the machine is somehost.domain.com, and that > it users recieve their mail at username@domain.com?? Yes. > well. then it's > your job as an admin to fix those machines to properly identify itself... They do. They identify the reverse path to the user sending the mail, which is all that is required. You seem to be trying to place additional requirements on them, above that. This doesn't work for single user hosts. It also doesn't work for top level domains. Consider the following arrangement: 1) I have a DNS MX record for bob.com; it states that the mail exchanger is "mail.bob.com". 2) I have a host "mail.bob.com" that accepts mail for "bob.com" as if it were the local machine. 3) I have a machine called "pc35.bob.com". It is on an internal network, and is, in fact, running a Winsock proxy server (named "proxy.bob.com") to access the net. It is a POP3/SMTP client like Eudora, NetScape, Internet Explorer, Windows PINE, etc.. 4) The user on pc35 sends mail. The net effect will be: a) proxy connection from mail client to proxy server b) proxy server connects to destination mail server (not all PC clients allow designation of a "marter host") c) client injects mail claiming to be "pc35user@bob.com" (or whatever username the user has for his maildrop on the machine "bob.com"). His HELO/EHLO claimed him to be "bob.com" 5) The user on pc35 gets mail. The net effect will be: a) proxy connection from mail client to proxy server b) proxy server connects to mail.bob.com, the mail server configured in the mail program's setup c) POP3 authentication takes place d) user agent pulls down mail delivered to maildrop "pc35user@bob.com" via exchanger to "mail.bob.com" 6) Clearly, the user will not claim to be the machine named "proxy.bob.com", though that is the machine making the connection. THe actual machine name can not be reversed. You can build all sorts of scenarios like this one, even if you don't use PC's or proxy servers. I can have the same wituation with a UNIX network which must relay outbound mail through a firewall. > > It also neglects the point of browsers on PCs that you yourself raised > > earlier: Eudora, IEx.x, and NetScape all can send mail without a valid > > return address. As can "cyberbomber", etc.. Consider someone like > > that, who nevertheless subscribes to the list with a valid return address. > > umm... can you refer to me the message that I brought about about how > browsers can send fine? (mesg-id will do nicely, I archive all out > going mail)... Sorry; I don't archive inbound mail unless it tells me something I don't already know. That's mostly Bruce, John, jmb, et. el. talking about technical issues, various announcements, patches, and source code (they aren't the only ones, they're just example names). You said something like "Browsers should be configured correctly and all machines should have reverse information". Or that was the logical effect that would have depended from implementing what you had suggested. It's just not possible. You in effect said that browsers could *not* "send fine"; the effect of the ":" above is to provide counterexample to the issue you raised, not illustrate your side. > yes.. but that's because those programs do the masquerading for you.. > I believe they take your from address and just present it in the "mail > from:" part... nothing says that the return-path has to include the > local machine... by default sendmail doesn't masquerade or read your > mail to grab the reply-to to preset a valid mail from:... it just > assumes that the machine addressing the envelope knows what it's doing.. > and if you tell sendmail to rewrite addresses.. it will happily whiteout > your invalid info.. and replace it with valid info (that you tell it).. Here's the problem, then: I can lie about my machine name, and your DNS check in this case will still work. Typically, when one is talking about DNS checking, one wants to call getpeername() to get the IP addr of the machine which has connected to you. Then one calls gethostbyaddr() to get the host name, and then compares the zone data to see if they match. The zone data in this case is the TLD, and the domain name in the TLD, without the name of the host(s). So if I send mail from "pc35.bob.com" and the revers lookup for my IP addr is "proxy.bob.com", "bob.com" == "bob.com" and I allow the message. This fails to address DNS spoofing, however, where the spammer has a netblock, and had the reverse lookup return "FreeBSD.ORG" instead of "Cyberpromo.COM" (purely as an example), and you allow the mail because the reverse lookup "matches". DNS fails to provide for the determination of ownership, in a machine comparable way, of the netblock in which the client exists. This is why many SPAM countermeasures operate by netblock instead of by address. Really, I want to accept mailfrom a.b.c.d without a reverse record claiming to be "bob.com", IFF a.b.c.d is in a netblock owned by the entity that owns "bob.com". This doesn't solve the next set of issues; I hesistate to raise them on a public list: 1) What if someone legitimate allows a relay through them, such that I believe that it's a legitimate host, and they claim to be the legitimate host to the legitimate host? 2) What if the spammers break up their netblocks into tiny and non-contiguous segments? Cyberpromo and Hotmail are already known to do this. Personally, I believe it's going to get down to trusted, criteria-based key signing authorities. You send spam, and next week your key doesn't get signed by the it's-not-spam-authority, and no one ever accepts mail from you again. As soon as spammers start using the above techniques in earnest, you are going to see most spammers go international, in any case, since this type of claiming to be who you aren't already violates Federal wire fraud statutes; it just needs someone to prosecute. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709082054.NAA07610>