I'd say your only choice is to go with a closed system - then you solve the problem - it's what anything like the measures you are looking for amount to anyways...
Many companies do it - they have an internal zone - not accessible through the normal internet, and run internal corp mail through it. No Spam ever. People who have to communicate with the rest of the world do it optionally - and accept the problems it brings. I'm afraid there is no holy grail which serves both goals - openness and security... I have seen systems which only accept mail from people who are on a whitelist, and bounce all others with a "skill testing question" - answering the question allows you to be auto-added to the whitelist - prevents the bots from getting through - could be interesting to do something like that, but wouldn't be acceptable for many - could be a good option for the ultra peeved at the world types though. m/ Mark Trostler ([EMAIL PROTECTED]) wrote*: > >There needs to be a generalized way to correctly associate the >address given in the MAIL FROM with the sending client. >Given the current infrastructure of a lot of ISPs perhaps that's currently >not possible as I had hoped - which SUCKS. >Sure running SpamAssasin or Bogofilter is fine & dandy & works really well >but now there's got to be a solution to stop endless email hijacking. >If that means a total redo of the email infrastructure then I'm all for it. > Mark (this is what happens when I reach my wit's end) > >On Tue, 19 Aug 2003, James A Baker wrote: > >> On Tuesday, Aug 19, 2003, at 16:41 US/Central, [EMAIL PROTECTED] >> wrote: >> >> >After having email addresses in my domains hijacked (both users that >> >exist >> >& those that don't) left, right, and center I can't take it anymore! >> >Is it possible/insane to have esmtpd (& any other MTA) do a reverse >> >DNS check on the MAIL FROM address to ensure that the domain specified >> >there match the domain of the sending machine? >> >I don't care if it takes a couple extra seconds to do that check, >> >endless >> >email hijacking is totally ridiculous & HAS to stop. I'm stick of >> >seeing zillions of bounces from spam emails no one in my domain ever >> >sent. >> >SO someone please tell me what's so horrible about: >> > >> >1. client connects & sends MAIL FROM address >> >2. server reverse DNSs the client's IP >> >3. if the domain doesn't match the domain in the FROM address or >> > the IP is not resolvable the email is rejected >> >> >> Lots of mail would NEVER get delivered to you in this situation. Take >> mine for instance. >> >> My mail host is set up to allow me to send with any of several >> different From: addresses (to support multiple accounts) as long as I'm >> submitting it from my LAN or via an authenticated connection. However, >> because I send all my mail through that server (regardless of the From: >> addresses' domains) this solution would block those mails -- because >> the From: domain doesn't match my server's domain name in a reverse >> lookup. >> >> This would also be the case with mail that EVER got relayed from one >> domain to another before final delivery. And also would stop all mail >> from anyone else who -- like me -- uses one server to send mail from >> multiple accounts on various domains. ... Think of a Bellsouth user who >> sends mail from their Yahoo! address, using their mail client instead >> of the Yahoo! web interface. >> >> Also, what about the cases (such as this list at Sourceforge) where the >> address is in a sub-domain, but the IP of the client (i.e. the >> sending/relaying server) is in a different sub-domain. You couldn't >> even get mail from this list using this method, I don't think. >> >> >> >OR >> > >> >1. client connects & sends MAIL FROM address >> >2. server DNSs the MX record for the domain in the FROM address >> >3. if the IP of client does NOT match one of the MX records for that >> >domain >> > the email is rejected. >> > If domains want to allow other machines than their mail servers to >> >be able >> > to send emails using their domain they can add them with a very >> >high MX >> > priority so they never actually get used as a mail server BUT do >> >show >> > as legtimate sources of mail traffic for that domain >> > >> > >> >of course everyone across the internet would have to do this BUT if >> >they DID >> >then we REALLY cut down on spam - & virtually totally eliminate email >> >hijacking. >> >> >> ...And you kill off any chance I had of debugging connection problems >> to your domain, when I can't manually telnet to port 25 and talk SMTP >> from a random workstation, instead of logging into a server listed in >> my domain's MX records. Though that's more of an annoyance than >> anything, of course, since there'd be ways around the problem. >> >> >> But much more seriously -- and just like in the first case -- you also >> rule out any relaying of mail between domains (those along the way to >> you) with this kind of restriction in place. >> >> Personally, I consider that a big disadvantage. =) >> >> >> >Again who really cares about the extra 1 second or so the DNS lookups >> >will >> >take - & of course most likely they're cached locally anyway after the >> >first hit. >> > >> >Currently our mail infrastructure is setup to first accept and THEN see >> >if there's something wrong with the message - HOWEVER with the tidal >> >wave >> >of spam that now is more numerous than legit email this paradigm needs >> >to >> >be switched: email should first be REJECTED UNLESS there's compelling >> >reasons to be accepted... >> > >> >Of course these same checks could also be done the 'From:' & >> >'Reply-To:' >> >headers - which I also think is a good idea but requires more >> >intervention >> >& maybe someone has a problem with looking into the headers BUT with >> >spam being WAY out of control we gotta take more serious steps to stem >> >the >> >tide. >> > >> >whatcha'll think? >> > Mark >> >> I agree in *theory* that proactive filtering is better than reactive >> filtering. However, most solutions of a proactive nature are flawed in >> that they attempt to still use non-trustworthy mechanisms such as SMTP. >> >> IMHO, you simply cannot trust the SMTP service *at all* if you want to >> stop SPAM. Someday, people will (probably/hopefully?) find a way to >> stop SPAM... but I seriously doubt that it will include using SMTP to >> transfer mail. There quite simply is no way to set up a "trust" network >> -- other than using SSL for all connections which is "non-trival" at >> best, assuming that you don't want to *seriously* limit the number of >> domains that can talk to you... particularly since not all domains will >> ever bother with installing a "trusted" SSL cert on their systems while >> they cost as much as they typically do. >> >> Just my $.02 worth. >> >> -jab >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by Dice.com. >> Did you know that Dice has over 25,000 tech jobs available today? From >> careers in IT to Engineering to Tech Sales, Dice has tech jobs from the >> best hiring companies. http://www.dice.com/index.epl?rel_code=104 >> _______________________________________________ >> courier-users mailing list >> [EMAIL PROTECTED] >> Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users >> > > >------------------------------------------------------- >This SF.net email is sponsored by: VM Ware >With VMware you can run multiple operating systems on a single machine. >WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines >at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 >_______________________________________________ >courier-users mailing list >[EMAIL PROTECTED] >Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users > ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
