---

Hejsa,

Hvorfor har ISP'erne blokeret for indgående port-25?

Jeg kan ikke se andre årsager end det at blokere for post
der ikke er afleveret til den host som faktisk har MX'en.

Er der andre grunde? (ud over at det måske kan sælge et
erhvervsprodukt i stedet)


/Morten - som faktisk arbejder hos en ISP, men ikke
rigtig tidligere har funderet over spørgsmålet,
og som her naturligvis skriver på ejne vejne.

---

Morten Guldager wrote:
> Hejsa,
>
> Hvorfor har ISP'erne blokeret for indgående port-25?

Hvis du mener slutbrugerens port 25 - så kan jeg da (heldigvis) stadig
sende mails på min TDC (hjemme) og CC (arbejde) uden problemer.?

---

2006-12-01 Martin wrote
> Morten Guldager wrote:
>> Hejsa,
>>
>> Hvorfor har ISP'erne blokeret for indgående port-25?
>
> Hvis du mener slutbrugerens port 25 - så kan jeg da (heldigvis) stadig
> sende mails på min TDC (hjemme) og CC (arbejde) uden problemer.?

Jeg mener "fra internettet ind til slutbrugeren"


/Morten

---

On Fri, 01 Dec 2006 20:46:27 GMT, Morten Guldager
<Morten.Guldager@gmail.com> wrote:

>Hvorfor har ISP'erne blokeret for indgående port-25?

Det var engang (stadig?) et problem med mailservere der stod som åbne
relays, dvs. accepterede og videresendte e-mails fra en hvilken som helst
IP til hvem som helst på nettet. Blokeringen blev dengang set som et
skridt på vejen til at løse spam-problemet, da det skulle blive lettere at
identificere spammerne... Jeg tror spammerne er blevet lidt klogere

Enhver, der mailede gennem sådan et åbent relay blev kun identificeret med
sin IP i headerens Recieved:-linje, og der var vidst for mange nystartede
spamjægere der ikke kunne læse headeren ordentligt og overbebyrdede
abuse-postkasserne med klager.

>Jeg kan ikke se andre årsager end det at blokere for post
>der ikke er afleveret til den host som faktisk har MX'en.

Det er simpelt for ISPen at sætte en relay-server op til at tjekke, om
modtagerens domæne er hosted på den pågældende server (via et DNS
MX-lookup). Er det ikke tilfældet, så slettes mailen bare, da spammerne
senere fandt ud af at man kunne bounce sin spam på sådan en relay-server.

--
Claus Holm Christensen
<http://www.claushc.dk/>

---

2006-12-02 Claus Holm Christensen wrote
> On Fri, 01 Dec 2006 20:46:27 GMT, Morten Guldager
><Morten.Guldager@gmail.com> wrote:
>
>>Hvorfor har ISP'erne blokeret for indgående port-25?
>
> Det var engang (stadig?) et problem med mailservere der stod som åbne
> relays, dvs. accepterede og videresendte e-mails fra en hvilken som helst
> IP til hvem som helst på nettet.

Det er ifølge en debat der netop var ovre i unix gruppen stadig et problem.

>>Jeg kan ikke se andre årsager end det at blokere for post
>>der ikke er afleveret til den host som faktisk har MX'en.
>
> Det er simpelt for ISPen at sætte en relay-server op til at tjekke, om
> modtagerens domæne er hosted på den pågældende server (via et DNS
> MX-lookup).

Glimrende, så havde jeg fattet det rigtigt.

Problemet med sådan et relæ er at al post til domænet modtages af relæet
og så først derefter bliver forsøgt afleveret til slutbrugerens
"hjemme-post-server".
Det betyder at post til f.eks. ikke-eksisterende@familien-danmark.dk faktisk
bliver modtaget på relæet, og når hjemme-post-servereren så siger "nej tak"
genereres en bounce mail.

Min ide er at erstatte ISP'ens relæ med en proxy som gør følgende:
- tager imod forbindelsen fra internettet.
- finder modtager domæne ud fra rcpt to i smtp
- laver MX opslag
- checker om IP er hos en af ISP'ens kunder
- åbner smtp til kunden
- "kobler de 2 ender sammen", men kun for _en_ mail

Vil det virke? (uden at give spammerene endnu et værktøj)


/Morten

---

On Sat, 02 Dec 2006 07:40:09 GMT, Morten Guldager
<Morten.Guldager@gmail.com> wrote:

>Problemet med sådan et relæ er at al post til domænet modtages af relæet
>og så først derefter bliver forsøgt afleveret til slutbrugerens
>"hjemme-post-server".
>Det betyder at post til f.eks. ikke-eksisterende@familien-danmark.dk faktisk
>bliver modtaget på relæet, og når hjemme-post-servereren så siger "nej tak"
>genereres en bounce mail.

Hvis de overhovedet genererer bounces nu til dags. Spammerne/vira har jo
også lært at bruge den slags... Men måske SPF kan bruges til at undgå
dette problem (nægt en bounce medmindre afsenderen er godkendt i
afsender-domænets SPF-header).

De store ISP'er har også lavet permanente åbninger for de virkeligt store
og legitime afsender-servere, f.eks. slipper Tele2s mailserver(e) direkte
igennem TDCs tcp/25-filter.


[snip -- proxy]
>Vil det virke? (uden at give spammerene endnu et værktøj)

Det vil virke... Indtil næste MX-server er utilgængelig! Hvad skal proxien
så gøre?
(1) Den kan cache mailen og reelt gøre som før,
(2) Den kan afvise mailen midlertidigt eller permanent, ud fra en
formodning om at serveren også ville afvise den (den er jo utilgængelig).

Første mulighed vil udfordre spammerne til at lave et DoS-angreb på lowest
numbered MX-server for at fremprovokere den gamle opførsel, det bliver
ikke populært.

Anden mulighed giver et ramaskrig bl.a. brugerne, da et af
"salgsargumenterne" for at indføre en backup-MX var at den netop ville
cache mails i det stykke tid et nedbrud typisk varer. Den midlertidige
afvisning har dog en vis fordel i at der reelt er tale om greylistning,
hvilket lader til at stige i popularitet.

Du skal også overveje hvilke ressourcer det kræver at implementere din
løsning, jeg tvivler på at det vil være let at gøre det lige så skalerbart
og driftssikkert som de eksisterende systemer.

Til sidst skal du beslutte om proxyen skal være transparant eller synlig.
En transparant proxy er usynlig for brugerne ude i verden, men du er nødt
til at forhindre TLS-kryptering, da det vil ødelægge ethvert forsøg på at
overvåge (og blokere uacceptable) transaktionerne. En almindelig proxy
skal have mere processorkraft for at håndtere den krypteringstrafik der
forhåbentlig stiger med tiden (herunder en stor stigning i beregningstunge
public key operationer).

--
Claus Holm Christensen
<http://www.claushc.dk/>

---

2006-12-02 Claus Holm Christensen wrote
> On Sat, 02 Dec 2006 07:40:09 GMT, Morten Guldager
><Morten.Guldager@gmail.com> wrote:
>
>>Problemet med sådan et relæ er at al post til domænet modtages af relæet
>>og så først derefter bliver forsøgt afleveret til slutbrugerens
>>"hjemme-post-server".
>>Det betyder at post til f.eks. ikke-eksisterende@familien-danmark.dk faktisk
>>bliver modtaget på relæet, og når hjemme-post-servereren så siger "nej tak"
>>genereres en bounce mail.
>
> Hvis de overhovedet genererer bounces nu til dags. Spammerne/vira har jo
> også lært at bruge den slags... Men måske SPF kan bruges til at undgå
> dette problem (nægt en bounce medmindre afsenderen er godkendt i
> afsender-domænets SPF-header).
>
> De store ISP'er har også lavet permanente åbninger for de virkeligt store
> og legitime afsender-servere, f.eks. slipper Tele2s mailserver(e) direkte
> igennem TDCs tcp/25-filter.
>
>
> [snip -- proxy]
>>Vil det virke? (uden at give spammerene endnu et værktøj)
>
> Det vil virke... Indtil næste MX-server er utilgængelig! Hvad skal proxien
> så gøre?
> (1) Den kan cache mailen og reelt gøre som før,
> (2) Den kan afvise mailen midlertidigt eller permanent, ud fra en
> formodning om at serveren også ville afvise den (den er jo utilgængelig).

Den skal gøre (2). Samme reaktion som hvis hjemme-post-serveren sad
direkte på nettet.

> Anden mulighed giver et ramaskrig bl.a. brugerne, da et af
> "salgsargumenterne" for at indføre en backup-MX var at den netop ville
> cache mails i det stykke tid et nedbrud typisk varer.

Det er jeg helt med på. Jeg er nørd, og jeg foretrækker en transperant
netforbindelse. Andre nørder antager jeg har samme syn på sagen.

> Den midlertidige
> afvisning har dog en vis fordel i at der reelt er tale om greylistning,
> hvilket lader til at stige i popularitet.

Ok, endnu en fiks feature så...

> Du skal også overveje hvilke ressourcer det kræver at implementere din
> løsning, jeg tvivler på at det vil være let at gøre det lige så skalerbart
> og driftssikkert som de eksisterende systemer.

Den udfordring bekynrer mig så slet ikke. Proxy maskinen skal ikke gøre
noget der er resourcemæssigt dyrt. (bortset fra at lave mx-opslag)
Intet skal skrives/læses fra en langsom disk.

> Til sidst skal du beslutte om proxyen skal være transparant eller synlig.

Synlig.

I dag laver brugeren 2 MX'er:
prio 10 -> hjemme-server
20 -> ISP relæ

Med min proxy laver han:
10 -> hjemme server
20 -> isp proxy

> En transparant proxy er usynlig for brugerne ude i verden, men du er nødt
> til at forhindre TLS-kryptering, da det vil ødelægge ethvert forsøg på at
> overvåge (og blokere uacceptable) transaktionerne. En almindelig proxy
> skal have mere processorkraft for at håndtere den krypteringstrafik der
> forhåbentlig stiger med tiden (herunder en stor stigning i beregningstunge
> public key operationer).

HOV!!! jeg kender vist slet ikke nok til smtp... Jeg troede ikke det
kunne krypteres. Altså selve protokollen, data delen er jeg helt med på kan.


/Morten

---

On Sat, 02 Dec 2006 19:54:40 GMT, Morten Guldager
<Morten.Guldager@gmail.com> wrote:

>Det er jeg helt med på. Jeg er nørd, og jeg foretrækker en transperant
>netforbindelse. Andre nørder antager jeg har samme syn på sagen.

Læs lidt om mail... Hvis der er en ting dokumentation, FAQ'er og
diskussioner på 'nettet er enige om, så er det vidst at mail er det mest
specialkonfigurerede standard-system på nettet. Alle vil have det
håndteret på deres helt egen måde

>> Den midlertidige
>> afvisning har dog en vis fordel i at der reelt er tale om greylistning,
>> hvilket lader til at stige i popularitet.
>
>Ok, endnu en fiks feature så...

De administratorer der driver ISP'ernes udgående relays forbander vidst
greylistning langt væk... Det giver større ressourceforbrug i form af
diskplads til e-mails der skal gemmes til lidt senere, så de vil helst
undgå det.

Jeg mener jeg har læst et sted med en administrator der overvejede at
droppe mails til sites der benytter greylistning, netop p.g.a. ovenstående
(kan ikke huske hvor, kan sagtens tage fejl).

>Den udfordring bekynrer mig så slet ikke. Proxy maskinen skal ikke gøre
>noget der er resourcemæssigt dyrt. (bortset fra at lave mx-opslag)
>Intet skal skrives/læses fra en langsom disk.

Det skal afsenderens ende...

>> Til sidst skal du beslutte om proxyen skal være transparant eller synlig.
>
>Synlig.

Ok, så er det netop muligt at implementere sig ud af krypteringsproblemet.

Men før du begynder at implementere det helt store, så overvej lige om der
er nogen ISP'er der gider at bruge det. Det er jo meget lettere med det
eksisterende system (men kan du gøre det meget mere effektivt end de
eksisterende systemer, så har du fast arbejde

>HOV!!! jeg kender vist slet ikke nok til smtp... Jeg troede ikke det
>kunne krypteres. Altså selve protokollen, data delen er jeg helt med på kan.

Det er ret simpelt. Start som sædvanligt med en EHLO, og svarer serveren
med 250-STARTTLS, så skriver du STARTTLS\n og begynder at forhandle
SSL/TLS.

Når SSL/TLS er forhandlet færdig starter du forfra med EHLO, denne gang i
en krypteret tunnel...

Blandt eksempler kan nævnes nordea.com og flere andre mailservere.
Problemet i forhold til dit program er at hver ny forbindelse så skal
forhandle TLS/SSL (hvilket er beregningstungt) mod både klienten og
hjemmeserveren, for derefter at dekryptere data fra klienten og kryptere
det igen til serveren.

--
Claus Holm Christensen
<http://www.claushc.dk/>

---

Den Sat, 02 Dec 2006 23:02:45 +0100 skrev Claus Holm Christensen:
>
>>HOV!!! jeg kender vist slet ikke nok til smtp... Jeg troede ikke det
>>kunne krypteres. Altså selve protokollen, data delen er jeg helt med på kan.
>
> Det er ret simpelt. Start som sædvanligt med en EHLO, og svarer serveren
> med 250-STARTTLS, så skriver du STARTTLS\n og begynder at forhandle
> SSL/TLS.
>
> Når SSL/TLS er forhandlet færdig starter du forfra med EHLO, denne gang i
> en krypteret tunnel...

Hvordan virker det med det nuværende backup-MX system? Gemmer backup-MX
serveren de krypterede data? Det kan den da ikke, hvis den ikke kan
læse andet end den første EHLO, har den ingen anelse om hvornår den
skal svare OK. Men hvis krypteringen skal kunne bruges til noget
fornuftigt, må kun den korrekte modtager kunne dekryptere, og ikke
en "man in the middle", der har snabelen ned i ISP'ens server, med
henvisning til diverse love om logning af data.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

On 02 Dec 2006 22:13:36 GMT, Kent Friis <nospam@nospam.invalid> wrote:

>Hvordan virker det med det nuværende backup-MX system? Gemmer backup-MX
>serveren de krypterede data? Det kan den da ikke, hvis den ikke kan
>læse andet end den første EHLO, har den ingen anelse om hvornår den
>skal svare OK. Men hvis krypteringen skal kunne bruges til noget
>fornuftigt, må kun den korrekte modtager kunne dekryptere, og ikke
>en "man in the middle", der har snabelen ned i ISP'ens server, med
>henvisning til diverse love om logning af data.

De nuværende backup-MXer annoncerer ikke understøttelse for STARTTLS, så
afsenderen forsøger bare ikke at kryptere forbindelsen. Så er ISPen en
Man-in-the-Middle alligevel.

Hvis backup-MXen vælger at understøtte STARTTLS, så afsluttes den
krypterede forbindelse på backup-MXen og data gemmes ukrypteret. Man må så
håbe på at den er kvik nok til at benytte kryptering når mailen sendes
videre til rette modtager.


Problemet med lovgivningen er at den tænker på end-to-end kryptering, hvor
SMTP definerer noget der kan sammenlignes med linklevel-kryptering. SMTP
krypterer forbindelsen mellem to servere, men forventer at sikkerheden på
serverne er 100% i orden (er man ikke sikker på det, så bliver man stadig
nødt til at bruge kryptering af selve mailen).

Det er også værd at bemærke, at traditionel SSL/TLS har en række
undtagelser der kræver brugerens indblanding, typisk når certifikatet ikke
tilhører den server du opretter forbindelse til (alvorlig fejl i SSL/TLS
verdenen). Mailservere har ofte et certifikat der ikke er underskrevet af
nogen ordentlig CA, og de bruges alligevel. Se f.eks. MX-serverne for
nordea.com, certifikatet er ugyldigt iflg. alle almindelige browsere, men
det bruges alligevel, da der ikke er en bruger/sysadmin som kan godkende
det fra gang til gang.


--
Claus Holm Christensen
<http://www.claushc.dk/>

---

Den Sat, 02 Dec 2006 23:52:13 +0100 skrev Claus Holm Christensen:
> On 02 Dec 2006 22:13:36 GMT, Kent Friis <nospam@nospam.invalid> wrote:
>
>>Hvordan virker det med det nuværende backup-MX system? Gemmer backup-MX
>>serveren de krypterede data? Det kan den da ikke, hvis den ikke kan
>>læse andet end den første EHLO, har den ingen anelse om hvornår den
>>skal svare OK. Men hvis krypteringen skal kunne bruges til noget
>>fornuftigt, må kun den korrekte modtager kunne dekryptere, og ikke
>>en "man in the middle", der har snabelen ned i ISP'ens server, med
>>henvisning til diverse love om logning af data.
>
> De nuværende backup-MXer annoncerer ikke understøttelse for STARTTLS, så
> afsenderen forsøger bare ikke at kryptere forbindelsen. Så er ISPen en
> Man-in-the-Middle alligevel.

Så ikke nok med at man har tvunget spammerne til at bruge botnets
i stedet for åbne relays, man har samtidig forhindret brugbar
kryptering på SMTP-nivau, til stor glæde for PET, NSA, osv...

> Hvis backup-MXen vælger at understøtte STARTTLS, så afsluttes den
> krypterede forbindelse på backup-MXen og data gemmes ukrypteret.

Hvis kryptering skal kunne bruges til noget, må uvedkommende ikke
kende nøglen. Og uden nøglen kan backup-MX ikke dekryptere noget
som helst.

> Problemet med lovgivningen er at den tænker på end-to-end kryptering, hvor
> SMTP definerer noget der kan sammenlignes med linklevel-kryptering. SMTP
> krypterer forbindelsen mellem to servere, men forventer at sikkerheden på
> serverne er 100% i orden

Og at der ikke er nogen servere imellem, som ikke er under afsender
eller modtagers kontrol.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

On 02 Dec 2006 22:57:47 GMT, Kent Friis <nospam@nospam.invalid> wrote:

>Den Sat, 02 Dec 2006 23:52:13 +0100 skrev Claus Holm Christensen:
[snip]
>Så ikke nok med at man har tvunget spammerne til at bruge botnets
>i stedet for åbne relays, man har samtidig forhindret brugbar
>kryptering på SMTP-nivau, til stor glæde for PET, NSA, osv...

Det er så ikke for at glæde diverse efterretningstjenester, men for at
opfylde de oprindelige mål med SMTP-standarden.

Man ønskede at lave et system hvor e-mails langsomt sprang fra server til
server, hele tiden til en server der var tættere på i den aktuelle
netværkskonfiguration (husk at Internet blev skabt til at overleve et
atomangreb med deraf følgende store huller i infrastrukturen).

For at opfylde det mål kan du ikke ved afsendelsen definere hvilke servere
din mail skal passere undervejs, da de kan være forsvundet inden din mail
kommer frem, og den definition kan du ikke undgå, da serverne skal have at
vide hvem næste mailhop er.

>> Hvis backup-MXen vælger at understøtte STARTTLS, så afsluttes den
>> krypterede forbindelse på backup-MXen og data gemmes ukrypteret.
>
>Hvis kryptering skal kunne bruges til noget, må uvedkommende ikke
>kende nøglen. Og uden nøglen kan backup-MX ikke dekryptere noget
>som helst.

Krypteringen mellem SMTP-servere er ganske fornuftig til at sikre sig mod
myndigheder der lytter på linjen uden ISPens eller brugerens vidende.

Senere, når STARTTLS er udbredt og serverne begynder at bruge anerkendte
CA'er og kontrollerer domænenavnet, så kan det også sikre mod
man-in-the-middle, idet man kun benytter servere som er godkendt af enten
modtager (gennem DNS MX-records) eller afsender (alt efter hvilken server
han sender sin mail til).

Afsender og modtager bliver nødt til at have tillid til, at
administratorerne af de annoncerede/valgte servere er i orden, ellers
skulle de nok vælge en anden server/ISP eller bruge noget public key
kryptering til at sikre at data undervejs er 100% sikkert.

>> Problemet med lovgivningen er at den tænker på end-to-end kryptering, hvor
>> SMTP definerer noget der kan sammenlignes med linklevel-kryptering. SMTP
>> krypterer forbindelsen mellem to servere, men forventer at sikkerheden på
>> serverne er 100% i orden
>
>Og at der ikke er nogen servere imellem, som ikke er under afsender
>eller modtagers kontrol.

Som afsender har du tillid til at din udbyders server ikke mishandler din
mail ved at sende den til utroværdige servere. Det er op til udbyderen at
vurdere om de vil bruge endnu en relayserver (og dermed om din tillid også
dækker denne server) eller sende det direkte til en MX-server (som
modtageren stoler på kan håndtere modtagerens mail sikkert).

Hvis du ikke stoler på udbyderens vurdering i relayserveren, så må du
finde en anden ISP eller gå direkte til modtagerens MX-server. Hvis du
ikke synes om dette, så må du nøjes med fodpost.


--
Claus Holm Christensen
<http://www.claushc.dk/>

---

Den Sun, 03 Dec 2006 19:28:40 +0100 skrev Claus Holm Christensen:
> On 02 Dec 2006 22:57:47 GMT, Kent Friis <nospam@nospam.invalid> wrote:
>
>>Den Sat, 02 Dec 2006 23:52:13 +0100 skrev Claus Holm Christensen:
> [snip]
>>Så ikke nok med at man har tvunget spammerne til at bruge botnets
>>i stedet for åbne relays, man har samtidig forhindret brugbar
>>kryptering på SMTP-nivau, til stor glæde for PET, NSA, osv...
>
> Det er så ikke for at glæde diverse efterretningstjenester, men for at
> opfylde de oprindelige mål med SMTP-standarden.
>
> Man ønskede at lave et system hvor e-mails langsomt sprang fra server til
> server, hele tiden til en server der var tættere på i den aktuelle
> netværkskonfiguration (husk at Internet blev skabt til at overleve et
> atomangreb med deraf følgende store huller i infrastrukturen).
>
> For at opfylde det mål kan du ikke ved afsendelsen definere hvilke servere
> din mail skal passere undervejs, da de kan være forsvundet inden din mail
> kommer frem, og den definition kan du ikke undgå, da serverne skal have at
> vide hvem næste mailhop er.

Tænker du ikke på IP nu? SMTP connecter normalt direkte til den
server der er angivet som MX for destinations-domænet. Hvis da
ikke lige mail'en skal forbi en UUCP forbindelse undervejs, men
så snakker vi vist heller ikke om SMTP-protokollen længere.

>>> Hvis backup-MXen vælger at understøtte STARTTLS, så afsluttes den
>>> krypterede forbindelse på backup-MXen og data gemmes ukrypteret.
>>
>>Hvis kryptering skal kunne bruges til noget, må uvedkommende ikke
>>kende nøglen. Og uden nøglen kan backup-MX ikke dekryptere noget
>>som helst.
>
> Krypteringen mellem SMTP-servere er ganske fornuftig til at sikre sig mod
> myndigheder der lytter på linjen uden ISPens eller brugerens vidende.

Hvilket er relevant når både afsenders og modtagers ISP ikke ligger
i et land. Hvis bare en af ISP'erne ligger i et land, kan man
efterhånden være ret sikker på at myndighederne har muligheden for
at lytte med.

> Afsender og modtager bliver nødt til at have tillid til, at
> administratorerne af de annoncerede/valgte servere er i orden, ellers
> skulle de nok vælge en anden server/ISP eller bruge noget public key
> kryptering til at sikre at data undervejs er 100% sikkert.

Kryptering som løsning på at kryptering er ubrugeligt? Du burde nok
i det mindste have skrevet "en anden form for kryptering end
STARTTLS".

>>> Problemet med lovgivningen er at den tænker på end-to-end kryptering, hvor
>>> SMTP definerer noget der kan sammenlignes med linklevel-kryptering. SMTP
>>> krypterer forbindelsen mellem to servere, men forventer at sikkerheden på
>>> serverne er 100% i orden
>>
>>Og at der ikke er nogen servere imellem, som ikke er under afsender
>>eller modtagers kontrol.
>
> Som afsender har du tillid til at din udbyders server ikke mishandler din
> mail ved at sende den til utroværdige servere.

Nej. Som afsender *forventer* jeg at min udbyder sender en kopi af
mail'en til utroværdige servere, med henvisning til diverse terror-
love.

Jeg har ikke tillid til en maskine jeg ikke selv har installeret.

> Hvis du ikke stoler på udbyderens vurdering i relayserveren, så må du
> finde en anden ISP

Der findes ikke andre ISP'er (se ovenfor: "hvis ISP'en ligger i et
land").

> eller gå direkte til modtagerens MX-server.

Det er jo det jeg ikke kan, da der er blokeret (i begge ender endda)
for direkte SMTP-trafik.

> Hvis du ikke synes om dette, så må du nøjes med fodpost.

Nye reklame-slogans til PostDanmark:

"Vi gemmer ikke din post til PET og NSA".
"Vi forhindrer ikke folk i at putte et brev direkte i din postkasse".

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

On 03 Dec 2006 19:47:50 GMT, Kent Friis <nospam@nospam.invalid> wrote:

>Tænker du ikke på IP nu? SMTP connecter normalt direkte til den
>server der er angivet som MX for destinations-domænet. Hvis da
>ikke lige mail'en skal forbi en UUCP forbindelse undervejs, men
>så snakker vi vist heller ikke om SMTP-protokollen længere.

Ja, sådan fungerer SMTP typisk i dag, men jeg forsøgte at give en
historisk forklaring på hvorfor SMTP ser ud som den gør i dag, og
protokollen voksede ud af UUCP-baserede netværk.

>Hvilket er relevant når både afsenders og modtagers ISP ikke ligger
>i et land. Hvis bare en af ISP'erne ligger i et land, kan man
>efterhånden være ret sikker på at myndighederne har muligheden for
>at lytte med.

Hvis myndighederne ønsker at lytte med, uden at give sig til kende overfor
server-admin i den ene eller begge ender, så er anden fase af STARTTLS
løsningen på det problem.

Hvis myndighederne tropper op med en dommerkendelse ved server-admin i den
ene eller begge ender og beder ham om at videresende en kopi af den
ukrypterede meddelelse, så bør afsender/modtager benytte end-to-end
kryptering, som f.eks. digital signatur.

>Kryptering som løsning på at kryptering er ubrugeligt? Du burde nok
>i det mindste have skrevet "en anden form for kryptering end
>STARTTLS".

Korrekt.

>Nej. Som afsender *forventer* jeg at min udbyder sender en kopi af
>mail'en til utroværdige servere, med henvisning til diverse terror-
>love.

Så har du også indset at STARTTLS ikke er løsningen for dig. Brug digital
signatur i stedet som sikrer dig hele vejen til afsenderen (medmindre en
af parterne benytter TDCs escrow system).

>Jeg har ikke tillid til en maskine jeg ikke selv har installeret.
[snip]
>Der findes ikke andre ISP'er (se ovenfor: "hvis ISP'en ligger i et
>land").

Heller ikke hvis du selv har installeret den? Du skrev ellers lige at du
ikke stolede på den

Nåeh nej, du har ikke længere fysisk kontrol med den (og så er slaget tabt
på forhånd).

>> eller gå direkte til modtagerens MX-server.
>
>Det er jo det jeg ikke kan, da der er blokeret (i begge ender endda)
>for direkte SMTP-trafik.

Brug den rigtige løsning til det rigtige problem. Hvis du frygter en
verden hvor selv myndighederne er en stor fare, så er STARTTLS ikke
svaret. Hvis du frygter en verden hvor en cracker sniffer din
telefonledning, så er STARTTLS en fin løsning.

>Nye reklame-slogans til PostDanmark:
>
>"Vi gemmer ikke din post til PET og NSA".
>"Vi forhindrer ikke folk i at putte et brev direkte i din postkasse".

LOL


--
Claus Holm Christensen
<http://www.claushc.dk/>

---

Den Mon, 04 Dec 2006 23:47:29 +0100 skrev Claus Holm Christensen:
> On 03 Dec 2006 19:47:50 GMT, Kent Friis <nospam@nospam.invalid> wrote:
>
>>Hvilket er relevant når både afsenders og modtagers ISP ikke ligger
>>i et land. Hvis bare en af ISP'erne ligger i et land, kan man
>>efterhånden være ret sikker på at myndighederne har muligheden for
>>at lytte med.
>
> Hvis myndighederne ønsker at lytte med, uden at give sig til kende overfor
> server-admin i den ene eller begge ender, så er anden fase af STARTTLS
> løsningen på det problem.

Med andre ord, hvis myndighederne ønsker at besværliggøre deres eget
arbejde... Og selv da løser STARTTLS ikke noget, for så tager de
bare kontakt til ISP'en når de har konstateret at det bruges.

> Hvis myndighederne tropper op med en dommerkendelse ved server-admin i den
> ene eller begge ender og beder ham om at videresende en kopi af den
> ukrypterede meddelelse, så bør afsender/modtager benytte end-to-end
> kryptering,

Aka. kryptering der virker.

> som f.eks. digital signatur.

Hvis man stoler så meget på samme myndigheder, at man tror på at
de ikke har en kopi af den private nøgle, så kan det nok slet ikke
betale sig at kryptere.

>>> eller gå direkte til modtagerens MX-server.
>>
>>Det er jo det jeg ikke kan, da der er blokeret (i begge ender endda)
>>for direkte SMTP-trafik.
>
> Brug den rigtige løsning til det rigtige problem. Hvis du frygter en
> verden hvor selv myndighederne er en stor fare, så er STARTTLS ikke
> svaret. Hvis du frygter en verden hvor en cracker sniffer din
> telefonledning, så er STARTTLS en fin løsning.

En telefon-ledning er alt for besværlig, de er typisk gravet ned,
og det endda udendørs (gys). Mail-serveren er meget nemmere at
angribe.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

On 05 Dec 2006 16:22:18 GMT, Kent Friis <nospam@nospam.invalid> wrote:

>Med andre ord, hvis myndighederne ønsker at besværliggøre deres eget
>arbejde... Og selv da løser STARTTLS ikke noget, for så tager de
>bare kontakt til ISP'en når de har konstateret at det bruges.

Husk lige på det indledende betingelse for denne løsning var at
myndighederne ikke gav sine intentioner til kende for afsender og
modtager, sidstnævnte inkluderede ISPerne. Det fik jeg ikke skrevet klart
og tydeligt, men det var min mening.

>> Hvis myndighederne tropper op med en dommerkendelse ved server-admin i den
>> ene eller begge ender og beder ham om at videresende en kopi af den
>> ukrypterede meddelelse, så bør afsender/modtager benytte end-to-end
>> kryptering,
>
>Aka. kryptering der virker.

Krypteringen i STARTTLS virker fint nok (det er oftest de samme
algoritmer), spørgsmålet er bare hvor mange steder det er muligt at udlede
den ukrypterede meddelelse. Grundlæggende set er STARTTLS en ganske
udemærket lappeløsning på et system hvor brugerne har vist sig modvillige
mod at gøre det ordentligt fra starten.

STARTTLS giver en ganske god sikkerhed, men det lader ikke til at det er
godt nok til din risikovurdering. Husk i øvrigt at der er et element af
risiko i alt, og risikoen kan aldrig reduceres til absolut nul.

>Hvis man stoler så meget på samme myndigheder, at man tror på at
>de ikke har en kopi af den private nøgle, så kan det nok slet ikke
>betale sig at kryptere.

Forsøger du at fortælle os at der er sikkerhedshuller i TDCs Digitale
Signatur (ud over at TDC tilbyder key escrow/backup)?

Læs lidt på teknologien. Digital signatur kan sagtens udstedes uden at TDC
(eller andre) nogensinde kommer i besiddelse af den private nøgle, og du
kan sagtens kontrollere den offentlige nøgles fingeraftryk udenom TDC (ved
100% sikker kontakt med modtageren).


--
Claus Holm Christensen
<http://www.claushc.dk/>

---

Den Wed, 06 Dec 2006 01:19:36 +0100 skrev Claus Holm Christensen:
> On 05 Dec 2006 16:22:18 GMT, Kent Friis <nospam@nospam.invalid> wrote:
>
>>Med andre ord, hvis myndighederne ønsker at besværliggøre deres eget
>>arbejde... Og selv da løser STARTTLS ikke noget, for så tager de
>>bare kontakt til ISP'en når de har konstateret at det bruges.
>
> Husk lige på det indledende betingelse for denne løsning var at
> myndighederne ikke gav sine intentioner til kende for afsender og
> modtager, sidstnævnte inkluderede ISPerne. Det fik jeg ikke skrevet klart
> og tydeligt, men det var min mening.

Betingelsen er ikke opfyldt, de har allerede givet sig til kende ved
diverse anti-terror-love og love om logning af data.

>>> Hvis myndighederne tropper op med en dommerkendelse ved server-admin i den
>>> ene eller begge ender og beder ham om at videresende en kopi af den
>>> ukrypterede meddelelse, så bør afsender/modtager benytte end-to-end
>>> kryptering,
>>
>>Aka. kryptering der virker.
>
> Krypteringen i STARTTLS virker fint nok (det er oftest de samme
> algoritmer),

Kryptering der automatisk dekrypteres hos enhver "man in the
middle" (aka. samtlige mailservere mail'en passerer) kan ikke
høre i kategorien "virker".

>>Hvis man stoler så meget på samme myndigheder, at man tror på at
>>de ikke har en kopi af den private nøgle, så kan det nok slet ikke
>>betale sig at kryptere.
>
> Forsøger du at fortælle os at der er sikkerhedshuller i TDCs Digitale
> Signatur (ud over at TDC tilbyder key escrow/backup)?
>
> Læs lidt på teknologien. Digital signatur kan sagtens udstedes uden at TDC
> (eller andre) nogensinde kommer i besiddelse af den private nøgle,

Inkluderer "TDC (eller andre)" programmer og websider TDC har lavet? Har
de en officiel forklaring på hvordan man bruger OpenSSL til at generere
nøglen, og sender kun den offentlige nøgle til dem?

Det er iøvrigt ikke langt tid siden der var nogen der konstaterede
at et eller andet offentligt site (ATP?) ville have adgang til den
private nøgle.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

On 06 Dec 2006 16:36:04 GMT, Kent Friis <nospam@nospam.invalid> wrote:

>Kryptering der automatisk dekrypteres hos enhver "man in the
>middle" (aka. samtlige mailservere mail'en passerer) kan ikke
>høre i kategorien "virker".

Kommer an på definitionen af virker.

I din risikovurdering (myndighederne er farlige) har du ret.

I standardens trusselsvurdering (undgå hackere while in transit mellem
mailservere) er STARTTLS nok.

>Inkluderer "TDC (eller andre)" programmer og websider TDC har lavet? Har
>de en officiel forklaring på hvordan man bruger OpenSSL til at generere
>nøglen, og sender kun den offentlige nøgle til dem?

Er det et krav at det skal være OpenSSL? Er Java "sikkert nok"?

OpenCert er lavet for det tilfælde, at du har noget som ikke kan køre de
sædvanlige websider til at danne certifikatet. Du kan downloade kildekoden
her: <https://www.certifikat.dk/developer/kildekode/opencert/>, og med det
skulle du være i stand til at få et certifikat uden at udlevere den
private nøgle.

For at forøge dit paranoia-niveau, så kan du jo kigge lidt på Reflections
On Trusting Trust, <http://www.acm.org/classics/sep95/>, og overvej så om
du overhovedet tør stole på din Java-compiler

>Det er iøvrigt ikke langt tid siden der var nogen der konstaterede
>at et eller andet offentligt site (ATP?) ville have adgang til den
>private nøgle.

Så vidt jeg husker havde de lavet deres egen Java applet til at signere
data... Det vil selvfølgelig ikke virke uden adgang til den private nøgle,
og er en af den slags bommerter som opstår under og efter indførslen af
enhver ny teknologi. Ja, det var dumt. Nej, det var ikke endegyldigt bevis
for at Kabalen er ude efter os.


--
Claus Holm Christensen
<http://www.claushc.dk/>

---

Den Wed, 06 Dec 2006 23:06:27 +0100 skrev Claus Holm Christensen:
> On 06 Dec 2006 16:36:04 GMT, Kent Friis <nospam@nospam.invalid> wrote:
>
>>Kryptering der automatisk dekrypteres hos enhver "man in the
>>middle" (aka. samtlige mailservere mail'en passerer) kan ikke
>>høre i kategorien "virker".
>
> Kommer an på definitionen af virker.
>
> I din risikovurdering (myndighederne er farlige) har du ret.
>
> I standardens trusselsvurdering (undgå hackere while in transit mellem
> mailservere) er STARTTLS nok.

Der er to muligheder for at få fat i mail'en - angribe en router
den passerer, og installere en sniffer der. Eller angribe mail-
serveren.

Umiddelbart vil jeg mene at mailserveren er det nemmeste mål (hvordan
installerer man overhovedet Wireshark på IOS?

>>Inkluderer "TDC (eller andre)" programmer og websider TDC har lavet? Har
>>de en officiel forklaring på hvordan man bruger OpenSSL til at generere
>>nøglen, og sender kun den offentlige nøgle til dem?
>
> Er det et krav at det skal være OpenSSL? Er Java "sikkert nok"?

Det er ikke sproget der afgør hvad der er sikkert nok, men hvem der
står bag. Hvis fx. TDC har lavet programmet, og programmet har fat
i den private nøgle, ved vi med sikkerhed at en del af TDC (nemlig
programmet) allerede har fingre i den private nøgle.

> For at forøge dit paranoia-niveau, så kan du jo kigge lidt på Reflections
> On Trusting Trust, <http://www.acm.org/classics/sep95/>, og overvej så om
> du overhovedet tør stole på din Java-compiler

Jeg behøver ikke engang clicke på linket, jeg kender udemærket den
artikel ud fra titlen.

>>Det er iøvrigt ikke langt tid siden der var nogen der konstaterede
>>at et eller andet offentligt site (ATP?) ville have adgang til den
>>private nøgle.
>
> Så vidt jeg husker havde de lavet deres egen Java applet til at signere
> data... Det vil selvfølgelig ikke virke uden adgang til den private nøgle,
> og er en af den slags bommerter som opstår under og efter indførslen af
> enhver ny teknologi. Ja, det var dumt. Nej, det var ikke endegyldigt bevis
> for at Kabalen er ude efter os.

Det er ikke et bevis på at de er ude efter os, nej. Det kan deles
i to - muligheden og hensigten.

ATP-bommerten er muligheden, men beviser ikke nogen hensigt.

Hensigten finder vi terrorloven og den der påbyder ISP'erne at logge
data.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

On 06 Dec 2006 22:19:07 GMT, Kent Friis <nospam@nospam.invalid> wrote:

>Der er to muligheder for at få fat i mail'en - angribe en router
>den passerer, og installere en sniffer der. Eller angribe mail-
>serveren.

Det er ikke muligt at få fat i noget på routeren (ved STARTTLS), der er
mailen krypteret med de samme algoritmer som man benytter ved almindelig
digital signatur.

Kommer myndighederne med en dommerkendelse, så kan de få fat i den
ukrypterede mail på serveren. Det er bare ikke noget som STARTTLS er
skrevet til at beskytte imod.

>Det er ikke sproget der afgør hvad der er sikkert nok, men hvem der
>står bag. Hvis fx. TDC har lavet programmet, og programmet har fat
>i den private nøgle, ved vi med sikkerhed at en del af TDC (nemlig
>programmet) allerede har fingre i den private nøgle.

Hvis kildekoden er tilgængelig, som i dette tilfælde, så har jeg intet
imod at den har været gennem TDC... Så vidt jeg husker benytter de
standard Java metoder, og jeg fandt intet alarmerende da jeg kiggede koden
igennem (nogen tid siden, og mine Java-kundskaber kunne være bedre). Det
var dengang jeg overvejede at lave et hack så jeg kunne smide mit eget CSR
fra OpenSSL ind i deres signaturgenerator, men den benytter noget RMI
eller lignende til at kommunikere med TDC, så det gik lidt i glemmebogen
igen.


--
Claus Holm Christensen
<http://www.claushc.dk/>

---

Den Thu, 07 Dec 2006 00:24:25 +0100 skrev Claus Holm Christensen:
> On 06 Dec 2006 22:19:07 GMT, Kent Friis <nospam@nospam.invalid> wrote:
>
>>Der er to muligheder for at få fat i mail'en - angribe en router
>>den passerer, og installere en sniffer der. Eller angribe mail-
>>serveren.
>
> Det er ikke muligt at få fat i noget på routeren (ved STARTTLS), der er
> mailen krypteret med de samme algoritmer som man benytter ved almindelig
> digital signatur.

Korrekt.

Pointen er at der er to angrebs-punkter - router og mailserver - hvor
mailserveren er kædens svageste led. STARTTLS beskytter kun mod
angreb mod routeren, ikke mod mailserveren. Det er altså en
teknologi der forstærker det stærkeste led, uden at ændre på det
svageste led.

> Kommer myndighederne med en dommerkendelse, så kan de få fat i den
> ukrypterede mail på serveren. Det er bare ikke noget som STARTTLS er
> skrevet til at beskytte imod.

Og kommer Joe Scriptkiddie med sit nyeste mailserver-exploit, hjælper
det heller ikke en meter.

>>Det er ikke sproget der afgør hvad der er sikkert nok, men hvem der
>>står bag. Hvis fx. TDC har lavet programmet, og programmet har fat
>>i den private nøgle, ved vi med sikkerhed at en del af TDC (nemlig
>>programmet) allerede har fingre i den private nøgle.
>
> Hvis kildekoden er tilgængelig, som i dette tilfælde, så har jeg intet
> imod at den har været gennem TDC... Så vidt jeg husker benytter de
> standard Java metoder, og jeg fandt intet alarmerende da jeg kiggede koden
> igennem (nogen tid siden, og mine Java-kundskaber kunne være bedre).

Fandt du noget i "Trusting Trust"?

> Det
> var dengang jeg overvejede at lave et hack så jeg kunne smide mit eget CSR
> fra OpenSSL ind i deres signaturgenerator, men den benytter noget RMI
> eller lignende til at kommunikere med TDC, så det gik lidt i glemmebogen
> igen.

Skal det forstås sådan at det mest komplicerede kode var omkring
kommunikationen? Så hvis man ønskede at gemme noget (så som at sende
lidt ekstra data), ville det være her det foregår...

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

2006-12-02 Claus Holm Christensen wrote
> On Sat, 02 Dec 2006 19:54:40 GMT, Morten Guldager wrote
>
> De administratorer der driver ISP'ernes udgående relays forbander vidst
> greylistning langt væk... Det giver større ressourceforbrug i form af
> diskplads til e-mails der skal gemmes til lidt senere, så de vil helst
> undgå det.

Jo, men med min proxy imellem, så bliver det op til den enkelte hjemmefusker
om han vil lege med graylisting.

>>Den udfordring bekynrer mig så slet ikke. Proxy maskinen skal ikke gøre
>>noget der er resourcemæssigt dyrt. (bortset fra at lave mx-opslag)
>>Intet skal skrives/læses fra en langsom disk.
>
> Det skal afsenderens ende...

Og det skal min proxy så også.
Den tager jo imod alle forbindelser, slår så MX'en op på brevet for at se
om det mon skulle være til en af ISP'en egne kunder.

> Men før du begynder at implementere det helt store, så overvej lige om der
> er nogen ISP'er der gider at bruge det.

Hvis du lige ruller tilbage til mit oprindelige indlæg i tråden her, og
nærlæser min signatur kunne man måske foranledes til at tro at jeg netop
i det game kunne tænkes at have visse "forbindelser"...

> Det er jo meget lettere med det
> eksisterende system (men kan du gøre det meget mere effektivt end de
> eksisterende systemer, så har du fast arbejde

Indtil videre _tror_ tror jeg det kan gøres væsentligt fiksere, og dermed
også _lidt_ billigere.

>>HOV!!! jeg kender vist slet ikke nok til smtp... Jeg troede ikke det
>>kunne krypteres. Altså selve protokollen, data delen er jeg helt med på kan.
>
> Det er ret simpelt. Start som sædvanligt med en EHLO, og svarer serveren
> med 250-STARTTLS, så skriver du STARTTLS\n og begynder at forhandle
> SSL/TLS.

Godt! Min proxy lader da bare vær med at svare 250-STARTTLS til de indgående
forbindelser.



/Morten - nå ja, jeg er stadig Tele2'er og skriver her stadig helt og
aldeles på egne vejne, selv om den aktuelle ide er inspireret
af mit arbejdsområde, og måske endda vil bliver brugt i
arbejdsøjemed, hvis den da ikke bliver skudt i sænk inden.

---

On Sun, 03 Dec 2006 07:41:35 GMT, Morten Guldager
<Morten.Guldager@gmail.com> wrote:

>Jo, men med min proxy imellem, så bliver det op til den enkelte hjemmefusker
>om han vil lege med graylisting.

Korrekt, men det kommer til at se ud som om det er udbyderens server der
leger med greylistning.

[snip -- større ressourceforbrug for begge parter]
>Den tager jo imod alle forbindelser, slår så MX'en op på brevet for at se
>om det mon skulle være til en af ISP'en egne kunder.

Jeg tænkte mere på at afsenderen skal cache en given mail indtil serveren
vil prøve igen. Jeg har en eller anden mistanke om at der er nogle ret
store mailservere derude som bare ikke kan lide greylistning. Det er kun
et problem i og med at det bliver Tele2 der ser ud til at være startet på
greylistning. Vil ledelsen acceptere det?

>Hvis du lige ruller tilbage til mit oprindelige indlæg i tråden her, og
>nærlæser min signatur kunne man måske foranledes til at tro at jeg netop
>i det game kunne tænkes at have visse "forbindelser"...

Jeg glemte det. Men nu er Tele2 jo ikke "hele verden"

>> Det er jo meget lettere med det
>> eksisterende system (men kan du gøre det meget mere effektivt end de
>> eksisterende systemer, så har du fast arbejde
>
>Indtil videre _tror_ tror jeg det kan gøres væsentligt fiksere, og dermed
>også _lidt_ billigere.

Jeg er tilbøjelig til at give dig ret. Sikkerhedsmæssigt ser det
fornuftigt ud.

Du husker selvfølgelig at overveje andre tekniske detaljer som:
* Congestion (herunder Denial-of-Service angreb og store mails),
* mærkelige måder at skrive e-mail adresser på (vi skal jo stadig
forhindre relays),
* Hvordan du vil håndtere CarbonCopy, når der skrives flere
modtager-adresser på forskellige hosts internt i systemet (så kan du
pludselig ikke længere bare pipe mellem parterne, da du skal synkronisere
svaret fra de forskellige servere).

>Godt! Min proxy lader da bare vær med at svare 250-STARTTLS til de indgående
>forbindelser.

Korrekt.


--
Claus Holm Christensen
<http://www.claushc.dk/>

---

2006-12-03 Claus Holm Christensen wrote
> On Sun, 03 Dec 2006 07:41:35 GMT, Morten Guldager
><Morten.Guldager@gmail.com> wrote:
>
>>Jo, men med min proxy imellem, så bliver det op til den enkelte hjemmefusker
>>om han vil lege med graylisting.
>
> Korrekt, men det kommer til at se ud som om det er udbyderens server der
> leger med greylistning.

Enig. Det er muligvis et problem.

>>Den tager jo imod alle forbindelser, slår så MX'en op på brevet for at se
>>om det mon skulle være til en af ISP'en egne kunder.
>
> Jeg tænkte mere på at afsenderen skal cache en given mail indtil serveren
> vil prøve igen. Jeg har en eller anden mistanke om at der er nogle ret
> store mailservere derude som bare ikke kan lide greylistning.

Jeg har ingen ide om om det er tilføldet. Andre der har viden her?

> et problem i og med at det bliver Tele2 der ser ud til at være startet på
> greylistning. Vil ledelsen acceptere det?

Ingen anelse. Som sagt havde jeg ikke overvejet om der kunne være
noget skidt i greylistning.
Hvis nogen finder på at implementere min ide så skal det naturligvis
overvejes nærmere.

>>Hvis du lige ruller tilbage til mit oprindelige indlæg i tråden her, og
>>nærlæser min signatur kunne man måske foranledes til at tro at jeg netop
>>i det game kunne tænkes at have visse "forbindelser"...
>
> Jeg glemte det. Men nu er Tele2 jo ikke "hele verden"

Ah pokkers. Jeg læste ellers i sidste interne memo at nu skulle
verdensherredømmet være på plads, men det kan jo tænkes at være skrevet
af en chef der er lidt for virkelighedsfjern...

>>Indtil videre _tror_ tror jeg det kan gøres væsentligt fiksere, og dermed
>>også _lidt_ billigere.
>
> Jeg er tilbøjelig til at give dig ret. Sikkerhedsmæssigt ser det
> fornuftigt ud.

Glimrende, det er da et stykke af vejen.

> Du husker selvfølgelig at overveje andre tekniske detaljer som:
> * Congestion (herunder Denial-of-Service angreb og store mails),

Check!

> * mærkelige måder at skrive e-mail adresser på (vi skal jo stadig
> forhindre relays),

Av! -> træls håndværk

> * Hvordan du vil håndtere CarbonCopy, når der skrives flere
> modtager-adresser på forskellige hosts internt i systemet (så kan du
> pludselig ikke længere bare pipe mellem parterne, da du skal synkronisere
> svaret fra de forskellige servere).

Av! -> her er et reelt problem.
Et brev skal kunne blive til flere breve i min proxy.
Og det er svært da min proxy ikke kan generere en bounce besked.


/Morten - stadig skrivende for egen regning.

---

2006-12-04 Morten Guldager wrote
> 2006-12-03 Claus Holm Christensen wrote
>
>> * Hvordan du vil håndtere CarbonCopy, når der skrives flere
>> modtager-adresser på forskellige hosts internt i systemet (så kan du
>> pludselig ikke længere bare pipe mellem parterne, da du skal synkronisere
>> svaret fra de forskellige servere).
>
> Av! -> her er et reelt problem.
> Et brev skal kunne blive til flere breve i min proxy.
> Og det er svært da min proxy ikke kan generere en bounce besked.

Hmm, kunne prøoxyen gøre følgende:
- tage imod første RCPT TO
- slå MX op
- åbne SMTP til IP
- tage imod næste RCPT TO
- slå MX op
- svare "450 mailbox busy, try again later" hvis det er til en ny IP
o.s.v.

Det er godt nok lidt af et hack...


/Morten

---

On Mon, 04 Dec 2006 18:27:50 GMT, Morten Guldager
<Morten.Guldager@gmail.com> wrote:

>- tage imod næste RCPT TO
>- slå MX op
>- svare "450 mailbox busy, try again later" hvis det er til en ny IP

Hmm... Det er jo ikke helt RFC-korrekt, og bliver så til en ufrivillig
greylist for modtager nr.2. Og hvis også denne modtager selv benytter
greylistning, så begynder det at blive kreativt, for hvor tit vil
afsenderen acceptere at blive afvist? Afsender vurderer jo selv hvad deres
retry-tid og -forsøg skal være...

>Det er godt nok lidt af et hack...

I høj grad et hack Ikke dårligt tænkt, men stadig et hack.


--
Claus Holm Christensen
<http://www.claushc.dk/>

---

On Mon, 04 Dec 2006 15:33:34 GMT, Morten Guldager
<Morten.Guldager@gmail.com> wrote:

>> Jeg tænkte mere på at afsenderen skal cache en given mail indtil serveren
>> vil prøve igen. Jeg har en eller anden mistanke om at der er nogle ret
>> store mailservere derude som bare ikke kan lide greylistning.
>
>Jeg har ingen ide om om det er tilføldet. Andre der har viden her?

Det er muligvis min hukommelse der er lidt for livlig, en hurtig google
efter "greylist sucks" gav bl.a. denne side:
<http://taint.org/2003/10/14/212147a.html>, der skriver at bl.a. Yahoo og
fornuftige mailing-list providers vil have problemer (altså dem der
benytter VERP -- et system som jeg lige skal læse lidt op på).

I samme søgning fandt jeg Bob Becks interessante analyser her:
<http://www.onlamp.com/pub/a/bsd/2004/10/28/openbsd_3_6.html?page=last>.

>> * mærkelige måder at skrive e-mail adresser på (vi skal jo stadig
>> forhindre relays),
>
>Av! -> træls håndværk

Fandt et link til en relay-checker på <www.dnsstuff.com>, og der var
masser af sjove måder at skrive e-mail adresser i min log bagefter


--
Claus Holm Christensen
<http://www.claushc.dk/>

---

On Mon, 04 Dec 2006 23:17:49 +0100, Claus Holm Christensen
<spamtrap-dec2006@claushc.dk> wrote:

>I samme søgning fandt jeg Bob Becks interessante analyser her:
><http://www.onlamp.com/pub/a/bsd/2004/10/28/openbsd_3_6.html?page=last>.

DOH! Det gik lige lidt for hurtigt at inkludere det link. Den er slet ikke
mod greylists, men mod SPF og Caller ID. Jeg blev vidst lidt tryllebundet
af de ganske interessante resultater i øvrigt, eller også er jeg bare
træt. Jeg undskylder misforståelsen.


--
Claus Holm Christensen
<http://www.claushc.dk/>