From owner-lir-wg@ripe.net Mon Jan 12 09:27:45 1998 From: Sami Koskinen <tossu@katiska.clinet.fi>
On Fri, 9 Jan 1998, Poul-Henning Kamp wrote:
One of the best things to do, would probably be to make a simple turnkey kind of sendmail config available to people.
What I think as the best solution is to patch sendmail to check from the name service if we really are in the mx list for the incoming mail. This would eliminate the need to store the same information to some other place, as we already have the information stored in the name service.
The idea is good indeed. I am, however, somewhat concerned about the following potential dangers: 1. The DNS can contain bogus info (including MX records). 2. You could be a victim of a malicious setup. For example, the primary of foo.domain puts an MX to one of your hosts protected in the way you suggest. When the secondaries have updated the zone, you get a large number of spam destined for foo.domain. Your resources may be abused, and you can even suffer a DoS. (At the same time, foo.domain may even filter out SMTP connections from you, to make sure *his* resources are not wasted...). To summarize, I feel it would be very good to use the info in the DNS, (in order to avoid redundancy in configuration and possible misconfigurations), however the DNS data may not be trustworthy, especially for the zones you are not authoritative for. One should balance between the advantages the suggested patch would bring and the dangers it exposes the user to... I personally would feel more confortable to explicitely allow myself the domains I want to relay, in spite of the extra work and possible misconfiguration. Just my 0.02$. Janos
One of the best things to do, would probably be to make a simple turnkey kind of sendmail config available to people.
What I think as the best solution is to patch sendmail to check from the name service if we really are in the mx list for the incoming mail. This would eliminate the need to store the same information to some other place, as we already have the information stored in the name service.
The idea is good indeed. I am, however, somewhat concerned about the following potential dangers:
Here are some of my personal thoughts on spam problem and one idea on how to deal with it. I've had these for quite some time, but somehow was unsure about applicability, and actually still isn't. Maybe you'll find it interesting, or find it unusable pretty fast. Anyway, I'd like to hear any comments. Spam will not be gone until it is either impossible or technically much too troublesome. Legal regulations don't work and won't until most of the world follows this. What might worry ISP-s is that when actually major fake-mail case will pop up, causing some party major losses due to maliceous intent, lawyers would ask ISP's what have they done to restrict fake-mail possibility? Long before such case it can be easy to keep an URL on a web page stating that email is not secure, but when someone gets really bitten, they would claim its not enough. You SHOULD do something about it. And currently there is almost nothing you can do. Some SMTP mail software have to be modified, some RFC-s be written, followed and enforced. Who would do that? Whatever we might wish, fake mail and spam will not be gone until it is taken under the control. Who else should start the process if not the ISP-s who are the major cause of the damn trouble and the most victims? Spamming methods. 1) spam is anonymous fake email with fake headers almost always. 2) spam is injected to open relays with no authentication whatsoever. 3) site whose domain the spam is faking usually does not permit spamming, but has no control over its domain being used by spammers. Possible solution: 1) mail Sender is accepted ONLY from an IP address, that is on the list of MX hosts for the sender's domain. Relay on DNS authority. DNS fakings is probably solvable temporary problem. This: a) Rejects non-existing domain senders, configuration errors. b) Rejects mail from relays that are used for injecting unauthenticated email sender. c) Brakes happyness of those people, who love to use single email address but injects mail wherever they can... This is wrong behaviour in the first place, and could be fixed by 3) 2) Mail Recipient is accepted ONLY for domain, which is on the MX list with receiver SMTP server, AND is allowed to be relayed. 3) EMail can be injected into SMTP world only via pop3 or similar, after authenicating senders username/password. Envelope-senders return-path would be out of control of luser and ideally always correct. As dialin PC-s usually don't have MX, they would not be allowed to inject mail via SMTP server, but only via pop3 or similar. Or, ISP that hosts those dialins could define an MX for its mailserver, making it possible to its user population to inject mail via his mail server only and thus make slow transition. It would be needed to add POST method to pop3 or any other authenticated mail protocol widely used. This is the most problem with this scheme, but could be solved if principally accepted. End result: 1) End-users ideally would not be able to inject email into SMTP world otherwise than by authenticating themselves to their home-server. 2) SMTP world operates only with mail messages that are expected to be authenticated by some mail server. Without authentication, users cannot inject mail altogether, thus closed accounts are really cut off. 3) SMTP world relays mail only from valid MX-list to valid MX-list, anything that violates this is rejected. Control over originating sender hosts is given to remote domain DNS administration, control over relaying is given to local DNS administration. It is possible to ensure that no single mail message is faked within a community of SMTP servers implementing this. (IMHO) 4) SMTP servers that do not follow this continue to operate for their valid MX-ed domains, but are unable to deliver "fake" mail to those that do follow this scheme. Eventually this would force to take measures for all sites. 5) the more SMTP server become so strict, the less spam is left around. 6) SMTP servers that follow this scheme, but relay spam, are subject to RBL, blacklists or other means of Internet enforcement. ---------------------------------------------------------------------- Andres Kroonmaa mail: andre@online.ee Network Manager Organization: MicroLink Online Tel: 6308 909 Tallinn, Sakala 19 Pho: +372 6308 909 Estonia, EE0001 http://www.online.ee Fax: +372 6308 901 ----------------------------------------------------------------------
"Andres Kroonmaa" <andre@ml.ee> writes: ... 3) EMail can be injected into SMTP world only via pop3 or similar, after authenicating senders username/password. Envelope-senders return-path would be out of control of luser and ideally always correct. ... It would be needed to add POST method to pop3 or any other authenticated mail protocol widely used. This is the most problem with this scheme, but could be solved if principally accepted.
Some people use a hack sometimes called "submit after POP" which solves this problem. It allows a host that recently -say in the last 15 minutes- has had an authenticated POP session to retrieve mail, to relay mail to external domains. The beauty of this is that you do not need a new protocol or new client software. The only thing you need is to tell your users that they have to pick up mail before sending any. Experience shows that users understand that concept and most of them can successfully implement it. The downside of it is that you end up configuring your SMTP MTA from the POP logfiles... but you can use the authentication info in the log files to veryfy sender addresses ... Summary: A really gross hack but it works. Daniel
Andres, You have some very good ideas, which if concensus could be reached would help a few years down the road. I think most of your ideas a worth persuing and RIPE would be a good forum for doing so. I have been thinking about something much more easily implemented: Participating ISPs adds a TEXT record in DNS for the IP numbers of all their dial-in ports which say W.X.Y.Z.IN_ADDR.ARPA. IN TXT "NOSMTP" Sendmails refuse email from such IP#, unless specifically instructed otherwise (ie: at the home ISP of the ports). How is that for a short term solution ? This allows responsible ISPs to clearly signal to the rest of the net that "Don't trust this guy for SMTP". If we could get UUnet, sprint, ibm.net, compuserve.com and so on to add those records, then life would be much easier over here... -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." "Drink MONO-tonic, it goes down but it will NEVER come back up!"
I have been thinking about something much more easily implemented:
Participating ISPs adds a TEXT record in DNS for the IP numbers of all their dial-in ports which say
W.X.Y.Z.IN_ADDR.ARPA. IN TXT "NOSMTP"
Sendmails refuse email from such IP#, unless specifically instructed otherwise (ie: at the home ISP of the ports).
How is that for a short term solution ?
This allows responsible ISPs to clearly signal to the rest of the net that "Don't trust this guy for SMTP".
I believe there are lots of possible short term solutions, or hacks. Many of them are very good and working. But their most problem is that they call for free cooperation, not a standard. I believe that every single sysop already ten years ago knew dead sure that SMTP is totally unsecure and is calling for trouble. At these days perhaps noone could imagine that the first real trouble would be spam, perhaps people were more afraid of fake mail fraud. It is probably unrealistic to implement SMTP authentication or strict SMTP interdomain (or interAS) routing. SMTP so deeply depends on trust of remote site that it has overgrown for now. Your proposed method perhaps works ok, if all follow that, but it is IMHO allow-all-deny-some policy, and as such, prone to human errors and plain time-shortage (or carelessness). I'd wish to see a kind of follow-rules-or-it-simply-doesn't-work policy. To enforce that for now, we for eg. force all our dialin users to use our mail server as mail relay, thus we can always track down exactly who was the abuser. By also running anti-spam patches we filter our all sort of invalid domains. Spammers are not common here. So, we don't need that TXT record in the dns at all. If we have a spammer, we are very deeply worried about it, because we take responsibility for what our users do under our name. But this is not widely adopted policy, you know. Now, what I'd really like to be sure in, is that no other host on earth ever uses successfully our domain name for spamming, and I feel that the only way to ensure this would be a technical solution that makes this impossible. Simple rule that you can receive a message from a domain _only_ from a host responsible for that domain cuts off all kind of outsiders who might wish to spam with your name. But, for this rule to have any power, it have to be a standard. By implementing widely proposed method, we'd effectively force all internet users to use their home mail server, thus making it possible at least in theory to track down any spammer. And if added the only way to post mail message is via authenticated pop3 session, we can make sure that locked users never appear on the net again. Thus we can still make authenticated SMTP service, sort of.. Only then we can talk about trust between different sites. If you don't trust remote site, you can cut it off in worst case. If you do trust, then you rely on responsibility of remote administration and this usually works ok. What I basically propose, is to reduce anarchy in SMTP world before its too late. I'd love to see new RFC on SMTP, that pretty strictly specifies how SMTP servers and clients MUST behave, leaving out end-nodes and hinting that end-users should (or must) use other means to inject email messages to the SMTP world. Then, ideally, update RFC on pop3 to add method to inject mail from there and call for vendors to follow this RFC. After some time, when enough client software appears, make a slow switch, cutting off non-followers. ---------------------------------------------------------------------- Andres Kroonmaa mail: andre@online.ee Network Manager Organization: MicroLink Online Tel: 6308 909 Tallinn, Sakala 19 Pho: +372 6308 909 Estonia, EE0001 http://www.online.ee Fax: +372 6308 901 ----------------------------------------------------------------------
According to Janos Zsako:
What I think as the best solution is to patch sendmail to check from the name service if we really are in the mx list for the incoming mail.
We have been doing that for half a year now, and it works fine.
The idea is good indeed. I am, however, somewhat concerned about the following potential dangers:
1. The DNS can contain bogus info (including MX records).
Well if the MX record is wrong, you won't get any email anyway.
2. You could be a victim of a malicious setup. For example, the primary of foo.domain puts an MX to one of your hosts protected in the way you suggest. When the secondaries have updated the zone, you get a large number of spam destined for foo.domain. Your resources may be abused, and you can even suffer a DoS. (At the same time, foo.domain may even filter out SMTP connections from you, to make sure *his* resources are not wasted...).
So they setup their *own* nameserver to spam their *own* domain using you as a relay? Not very likely.. No, the real problem is when a MX is moved to another host. Cached MX records on other nameservers will cause the mail to be sent to the old MX, which doesn't accept it anymore. This _can _ cause bounced email if you are not careful (like lowering TTL 1 day before the tranfer, etc) Mike. -- Miquel van Smoorenburg | The dyslexic, agnostic, insomniac lay in his bed miquels@cistron.nl | awake all night wondering if there is a doG
On Mon, 12 Jan 1998, Miquel van Smoorenburg wrote:
So they setup their *own* nameserver to spam their *own* domain using you as a relay? Not very likely..
Well, we have a number of customers, that use mail-software, which is unable to follow the mail the whole way through, and simply dumps it on out mail-server expecting us to do the hard work - which we gladly do, as they pay us to do so :-)
No, the real problem is when a MX is moved to another host. Cached MX records on other nameservers will cause the mail to be sent to the old MX, which doesn't accept it anymore. This _can _ cause bounced email if you are not careful (like lowering TTL 1 day before the tranfer, etc)
Mike. -- Miquel van Smoorenburg | The dyslexic, agnostic, insomniac lay in his bed miquels@cistron.nl | awake all night wondering if there is a doG
Peter B. Juul, DKnet.
On Mon, 12 Jan 1998, Peter B. Juul wrote:
Well, we have a number of customers, that use mail-software, which is unable to follow the mail the whole way through, and simply dumps it on out mail-server expecting us to do the hard work - which we gladly do, as they pay us to do so :-)
Oops, please disregard this mail, as I decided not to finish writing it, and hit ^X instead of ^C. Peter B. Juul, DKnet.
participants (6)
-
Andres Kroonmaa -
Daniel Karrenberg -
Miquel van Smoorenburg -
Peter B. Juul -
Poul-Henning Kamp -
zsakoļ¼ banknet.net