Resent-Date: Sat, 8 Jan 2000 16:14:02 +0100 (MET) Date: 08 Jan 2000 15:13:22 UT From: Erik Naggum Organization: Naggum Software; +47 8800 8879; http://www.naggum.no Message-Id: <3156333203018220@naggum.no> To: SKEPSIS:; In-Reply-To: Subject: Re: Slibrigheter References: <1.5.4.32.20000106103003.006c7564@bgnett.no> <3156156314404940@naggum.no> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Resent-Message-ID: <"5Afh_D.A.q8.nQ1d4"@torget.bgnett.no> Resent-From: skepsis@lists.skepsis.no X-Mailing-List: archive/latest/2284 X-Loop: skepsis@lists.skepsis.no Precedence: list Resent-Sender: skepsis-request@lists.skepsis.no * Thomas Gramstad | Dette er ikke uoverkommelig mye jobb å gjøre, selv om det er mer tungvint | enn den ideelle løsningen ville være. Eller kanskje bare tung | nødvendighet får det til å virke slik. erfaringen er altså at 30% av den aktive brukermassen av en liste faller fra når slike tiltak innføres. det har vært mye diskusjon om dette i Internet Mail Requirements Working Group, en hittil uformell gruppe av de som arbeidet med mail innenfor Internet Host Requirements i 1986-1988. (gruppen har ikke vært aktiv på tre år, da det ble klart at IETF ikke ville gi den formell status på en stund.) det er mulig folk har endret oppfatning om spamming og godtar flere av de mange merkelige tiltak som man "må" innrette seg etter på hver bidige liste man er med på. grunnen til at folk faller fra, er at de jevnt over er utsatt for et utall _forskjellige_ mekanismer for å registrere alternative adresser, av- og påmelding, og ikke minst avvisning dersom noe ikke virker første gang. hver enkelt mekanisme kan synes grei nok alene, men er man på et større antall lav-volum-lister, blir mengden arbeide uoverkommelig stor når man foretar en enkel liten flytteoperasjon eller endring av en eller annen konfigurasjon av mail. | Men er de nødt til å sende fra ? nei, men det har for mange enorme fordeler å gjøre det. f eks kan man internt i et stort foretak sende mail direkte til og ikke minst _innen_ avdelingen med slike adresser, mens man eksternt ikke kan det, og istedet dirigerer alt mailmottak til ett sted (for sentralt spam management, blan andre ting), selv om man lar hver avdeling sende mail direkte ut i verden. dette er endatil en anbefalt konfigurasjon for store interne nett. erfaring viser igjen at i slike nett går over 90% av mailen bare internt. man _kan_ selvsagt skrive om adressen på vei ut i verden, men da mister man også informasjon som for mange oppfattes som verdifull. saken er ofte også at man allerede skriver om den helt interne adressen til nevnte . det er vanlig med et kort login-navn og en maskin som endelig destinasjon: , som skrives om til når det forlater det interne nettet for avdelingen. en egen regel for "verden" ville i en slik konfigurasjon være vanskelig å implementere uten kunnskap om resten av det store nettets konfigurasjon. | Kan ikke den aktuelle programvaren (MTAen?) konfigureres til enten å | fjerne subdomain fra headeren, eller til å opprette en ny header med | subdomain-informasjonen, en ny header som ikke vil skape problemer for | listserveren? (Dette er spørsmål, ikke synsing.) mye kan gjøres, men mail er blitt så utrolig mye vanskeligere å sette opp etter at mange som drifter mail-servere er blitt Microsoft-ofre, og det er oftest i de store organisasjonene at det er Unix-servere sentralt, mens man lar stakkarslige Microsoft-pakker forsøke å ta seg av mail i hver avdeling. Microsoft har aldri skjønt Internet mail, og er den aller største trusselen mot "basic mail interoperability" som var det vi i Internet Mail Requirements Working Group ville definere slik at det ikke skulle være mulig å sette opp et mailsystem som ødela for andre. det er ingen overdrivelse å si at grunnen til at arbeidsgruppen ikke har blitt offisiell er at Microsoft har truet med å droppe alle IETF-standarder om de pålegges å følge mail-spesifikasjonene. de _må_ nemlig bryte enhver standard for at sine egne fortreffelige forbedringer skal brukes overalt. RFC 1123 (Internet Host Requirements) utkom i oktober 1988 og sier at man definitivt bør bruke 4 siffer i årstall. i november 1995 utkommer den første versjonen av Microsofts mailgateway til Internet og det skriver om 4-sifrede årstall til 2-sifrede! løsningen på de fleste problemer som Microsoft skaper for Internet interoperability er faktisk å installere firewalls som hindrer de verste utslagene av deres helt unike forakt for standarder og hensyntagen (best uttrykt i Jon Postel's "be liberal in what you accept, and conservative in what you send"). den overdrevne bruken av firewalls (de øker ikke sikkerheten, og installeres som oftest så feil at de ikke ville ha øket sikkerhet selv om de kunne), er drevet frem av ønsket om å få alle PC'ene som kjører Windows bort fra direkte tilkobling til Internet. slipsene blir innbilt at de må beskytte sine maskiner mot omverdenen, mens faktum er at det er resten av verden som mest beskyttes mot Windows-apparatene. så svaret på spørsmålet ditt er: sålenge folk kjører serversoftware fra Microsoft på avdelingsnivå, er ingen tjent med å konfigurere dem -- de gjør allikevel så mye galt at det er bare såvidt de virker. dersom de hadde kjørt ordentlig _Internet_ mail software på maskinene (det finnes for NT, også, ikke bare alle Unix'ene), ville man med letthet kunne ha implementert den ideelle løsningen overalt. | Et siste spørsmål: Kjenner du til Ron Guilmettes virksomhet FREE | DynamicIP Spam Filtering - http://www.imrss.org/dssl/ -- er dette noe i | overensstemmelse med din løsning eller er det forsøk på å bekjempe | relaying? han nevnte at han skulle lage filtrering mot mail fra sites som ikke har fast oppkobling mot nettet på Internet Mail Requirements-listen for en tid tilbake. jeg har ikke sett på hva han har gjort. hvis det er det sammen som han snakket om, er det bare et forsøk på å forhindre at de som kobler seg opp til Internet gjennom oppringte samband til ISP'er som deler ut IP-adresser dynamisk (DHCP) får lov å sende mail direkte ut på nettet, men må gå gjennom ISP'ene sine. _egentlig_ burde dette løses ved at ISP'ene hindret sine kunder å bruke port 25 direkte ut mot verden, men redirigerte forbindelsene til sine sentrale maskiner, og et var vel klart allerede da han nevnte forslaget sitt for noen år siden. det er godt mulig at han har fortsatt med tiltaktet fordi så mange ISP'er er lite villige til å implementere slike generelle mot-tiltak. #:Erik