sslug-teknik team mailing list archive

[Jon Bendtsen <bendtsen@xxxxxxx>]

On Tue, Apr 27, 2004 at 09:55:25AM +0200, Claus Alboege wrote:
> Jon Bendtsen <bendtsen@xxxxxxx> writes:
> 
> > On Tue, Apr 27, 2004 at 12:18:56AM +0200, Claus Alboege wrote:
> >> Jon Bendtsen <bendtsen@xxxxxxx> writes:
> >> 
> >> > On Mon, Apr 26, 2004 at 09:55:03PM +0200, Claus Alboege wrote:
> >> >> Jon Bendtsen <bendtsen@xxxxxxx> writes:
> >
> >> >> Enten har man en "almindelig" TXT record, en TXT record med
> >> >> SPF-information eller slet ingen TXT records for et domaene. Hvis SPF
> >> >> bliver vidt udbredt, kan man blive tvunget til at slette sine
> >> >> "almindelige" TXT records for at kunne pushe SPF-information.
> >> >
> >> > kan der ikke være flere TXT records?
> >> 
> >> Jo. 
> >
> > hvad er så problemet med at der gemmes extra information i dem ?
> 
> Selvom SPF er gearet til kun at hive SPF relevant information ud af en
> TXT record for et givet domaene, er det ikke ensbetydende med at andre
> applikationer, der benytter TXT recorden til dens oprindelige formaal
> er. Hvorfor risikere at give andre problemer ved at hijacke TXT records,
> naar man istedet kunne benytte SRV records eller definere en ny RR til
> formaalet?

Fordi txt kan bruges til alt? Så må applicationerne der bruger den være
robuste. Desuden søger de jo om en ny record. Det er da ikke et spørgsmål
om at de har hijacket den.

 
> >> >> Det er lidt det samme som at lave en ny service der lytter paa port 70,
> >> >> overbevise folk om at de ikke kan leve uden, og saa ellers skide hoejt
> >> >> og flot paa de faa der stadig benytter gopher.
> >> >
> >> > nogle gange må man altså videre.
> >> 
> >> Skal vi ikke blive enige om at det havde vaeret en hel del smartere og
> >> mindre destruktivt at vaelge port 2170 istedet?
> >
> > Kommer an på hvad man vil opnå. SPF "ødelægger" jo kun modtagerens SMTP
> > server. Så jeg kan ikke se hvorfor at man ikke skulle bruge port 25.
> 
> I det her eksempel snakker vi om gopher og folk der hijacker port 70 til
> en ny type service, som ligesaa godt kunne have vaeret afviklet paa port
> 2170, hvorved det ikke ville goere livet surt for de folk, der stadig
> benytter port 70 til dens oprindelige formaal - nemlig gopher. 

Jamen der er jo minimal forskel på din SPFgopher og gopher.


> >> >> Anyway, hijacking af TXT records er af marginal betydning i forhold til
> >> >> mange af de andre af SPF's problemer.
> >> >
> >> > jeg er kun enig i af at det er af marginal betydning.
> >> 
> >> Du mener altsaa ikke at det er et problem at SPF oedelaegger forwarding
> >> og VERP?
> >
> > det er da uheldigt, men ikke verdens undergang.
> 
> Maaske ikke for dig, men det er tilladt at taenke paa hvilken problemer,
> det giver andre.

nej, det er ikke nødvendigt, de må jo selvom hvad de gøre på deres domaine
og på deres mailserver. SPF giver mig en mulighed for at foretage yderligere
filtrering på oplysningerne fra SPF.

 
> > Måske fordi jeg ikke bruger særlig meget forwarding.
> 
> Saa derfor sker der ikke noget ved at man goer livet surt for milioner
> af andre? :(

Det gør man jo ikke, for der er ingen der sender via min mailserver, og
den email jeg modtager... det er min email, og den må jeg da gøre med hvad
jeg vil.

 
> > Og hvordan kan det ødelægge VERP?
> 
> Kan du ikke lige laese op paa SRS?

Kan du ikke lige stikke mig en url

 
> > I VERP er envelope sender da en afsender fra mailing listens domaine,
> > således at bounce beskeden kommer tilbage til mailinglisten, så
> > den rette adresse kan fjernes fra listen ?
> 
> Jo, men VERP er mere end det.

hvad mere? og hvad er det der bliver brudt?

 
> >> Skal vi lege at der gaar 10 minutter fra de foeste personer modtager en
> >> spam-mail til den er meldt. I det tidsrum kan en spammer, med sine 2500 
> >> 0wnede hosts, der alle er tilfoejet under
> >> <random>.spam-and-throw-away.com's SPF records, sende - lad os blot sige
> >> - 1000 mails for hver, svarende til 2.5 milioner spammails. Og saa er
> >> det jo bare tage naeste domaene i brug. 
> >
> > Ja, men det er jo ikke alle der læser deres email på det tidspunkt.
> > Nogle bruger længere tid, og så kan der foretages yderligere filtrering
> > før det vises i mailprogrammet.
> 
> Spammailen er jo stadig havnet i modtagerens postkasse, hvor den optager
> plads. Grundideen med SPF var vel netop at blive i stand til at afvise
> post i SMTP-sessionen?

Det gør folk jo allerede baseret på blacklists. Andre bruger blacklists
til at filtrere på. Hvad folk gør på deres egen modtagne mailserver er
sku da folks eget problem.

 
> >> >> Der findes langt simplere (og mindre aggressive) forslag til det
> >> >> formaal, som fx.
> >> >>
> >> >>   http://www.space.net/~maex/Drafts/dns-mtamark/
> >> >> 
> >> >> der fx. ikke oedelaegger forwarding og VERP, og som virker med den
> >> >> software folk benytter i dag. 
> >> >
> >> > Den bruger jo også TXT. 
> >> 
> >> Ja, men i in-addr.arpa zonen!
> >
> > Og den har folk ikke kontrol over. Den har ISP'en kontrol over.
> 
> Ja, og saa du lover din ISP ikke at sende spam, og de lister din IP som
> gyldig afsender. Man kan nu paa en kontrolleret maade uddelegere
> ansvaret for at godkende MTA'er. Sender du alligevel spam, lister din
> ISP din IP som ugyldig. Reagerer din ISP ikke, tilfoejer man ISP'en i
> en (evt. privat) blockliste. Samtidig glaeder man sig over at man ikke
> har gjort skade paa eksisterende installationer :)

Du lover jo allerede i dag at du ikke sender spam. Alligevel er både
TDC's og tele2's mailserver havnet i spamcop.


> Men som sagt, dns-mtamark er blot eet eksempel paa hvordan man kan
> mindske maengden af spam og virus uden at goere skade paa eksisterende
> installationer. 

Jamen, den er også fin, jeg har foreslået at få den installeret på
"mine" ip adresser. Men det er ikke nok.

 
> Hvis man alligevel vil oedelaegge den nuvaerende mail-infrastruktur, som
> med SPF, kunne man lige saa godt tage skridtet fuldt og droppe SMTP, til
> fordel for et nyt system, der ikke lider af de samme problemer som
> SMTP. Det kunne vaere noget i retningen af IM2000.

det kommer nok også, men det er et størrer skridt at tage at implementere
en ny protokol i stedet for en lille ændring.

 
> Anyway, SPF har vaeret diskuteret til hudloeshed adskillige gange
> foer; og selvom der har vaeret en artikel i LinuxJournal(?) er der
> stadig for mange alvorlige og uloeste problemer.
 
Selvom den har problemer kan den godt være brugbar


JonB