Forwarding og grålisting

[Olaf Berli]

Kjører grålisting på mailserveren vår og den ser ut til å fungere bra.
Den fjerner hvertfall det meste av spamen...

Har også et domene med noen få mailkonti hos en ekstern leverandør, og
har satt opp disse kontiene med forwarding til respektive brukere i vårt
domene (på vår mailserver). Dette har fungert fint lenge, men nå ser det
ut til at mail på den eksterne serveren hoper seg opp og ikke blir
videresendt (eller blir videresendt kun en gang i døgnet eller deromkring).
Det ser ut til at når en mail kommer inn til ekstern server blir den
akseptert der, forwardet og lagt i utgående kø til vår server. Når vår
grålisting bryter forbindelsen forsøker den eksterne serveren re-send,
og skulle da slippe igjennom. Hvis det imidlertid har kommet flere
mailer inn i køen før det blir gjort en resend av den første (og disse
også har blitt "satt på vent" av grålistingen), så ser det ut til at den
eksterne serveren konkluderer med at det er et problem med vår server og
begynner å legge all mail i kø - uten å forsøke å sende noe som helst.
Etter noen timer (kanskje et døgn) gjør den et nytt forsøk og får sendt
alle meldingene i køen.

Vet ikke om jeg har misforstått SMTP protokollen, men har oppfattet det
slik at resend (med økende intervaller) skal skje pr. individuelle melding?

Er det noen annen god løsning på dette enn å flytte de nevnte
mailboksene over til vår server og dermed ungå forwardingen?

Olaf

[Peter N. M. Hansteen]

Post by Olaf Berli
Kjører grålisting på mailserveren vår og den ser ut til å fungere
bra. Den fjerner hvertfall det meste av spamen...

Godt å høre.

Post by Olaf Berli
Det ser ut til at når en mail kommer inn til ekstern server blir den
akseptert der, forwardet og lagt i utgående kø til vår server. Når vår
grålisting bryter forbindelsen forsøker den eksterne serveren re-send,
og skulle da slippe igjennom. Hvis det imidlertid har kommet flere
mailer inn i køen før det blir gjort en resend av den første (og disse
også har blitt "satt på vent" av grålistingen), så ser det ut til at
den eksterne serveren konkluderer med at det er et problem med vår
server og begynner å legge all mail i kø - uten å forsøke å sende noe
som helst. Etter noen timer (kanskje et døgn) gjør den et nytt forsøk
og får sendt alle meldingene i køen.

Det høres ut som en heller sløvt oppsatt server, det der, og muligens
et litt pussig grålistingsoppsett. Hvis jeg forstår deg riktig, så
blir det kun gjort forsøk en gang i døgnet, og meldingene blir ikke
lagt i en normal kø, men bare får vente til neste forsøk, om ca et
døgn. I de aller fleste grålistingsoppsett vil 'vente på neste
forsøk'-verdien kortere enn ett døgn (4 timer er en vanlig
standardverdi).

På den annen side, når en maskin (IP-adresse) først har kommet seg
gjennom grålistingen, vil den vel bli beholdt i hvitlisten en stund,
så nye forsøk fra en maskin som har kommet seg gjennom første hinder
vil bli godtatt. Men det forutsetter altså at den faktisk kommer
forbi grålisting i første omgang.

Post by Olaf Berli
Vet ikke om jeg har misforstått SMTP protokollen, men har oppfattet
det slik at resend (med økende intervaller) skal skje pr. individuelle
melding?

RFC2821 er ikke krystallklar, men den oppførselen du beskriver er i
alle fall etter mitt skjønn helt på grensen av hva som er akseptabelt.
Bla frem til "4.5.4.1 Sending Strategy" og bedøm selv - gjentatte
forsøk er MUST, legge i kø osv er SHOULD, men det er lov å tenke litt
selv.

Post by Olaf Berli
Er det noen annen god løsning på dette enn å flytte de nevnte
mailboksene over til vår server og dermed ungå forwardingen?

Jeg var nær ved å forslå å omgå problemet ved å hvitliste den
serveren, men hvis det er så som så med kompetansen der borte, er det
gjerne fare for at du da åpner for mer enn bare de videresendte
meldingene. Hvis du flytter brukerne over til en server du selv
styrer, så får du jo bedre kontroll i alle fall.

[Bjørn Mork]

Post by Peter N. M. Hansteen

Post by Olaf Berli
Det ser ut til at når en mail kommer inn til ekstern server blir den
akseptert der, forwardet og lagt i utgående kø til vår server. Når vår
grålisting bryter forbindelsen forsøker den eksterne serveren re-send,
og skulle da slippe igjennom. Hvis det imidlertid har kommet flere
mailer inn i køen før det blir gjort en resend av den første (og disse
også har blitt "satt på vent" av grålistingen), så ser det ut til at
den eksterne serveren konkluderer med at det er et problem med vår
server og begynner å legge all mail i kø - uten å forsøke å sende noe
som helst. Etter noen timer (kanskje et døgn) gjør den et nytt forsøk
og får sendt alle meldingene i køen.

Det høres ut som en heller sløvt oppsatt server, det der, og muligens
et litt pussig grålistingsoppsett. Hvis jeg forstår deg riktig, så
blir det kun gjort forsøk en gang i døgnet, og meldingene blir ikke
lagt i en normal kø, men bare får vente til neste forsøk, om ca et
døgn. I de aller fleste grålistingsoppsett vil 'vente på neste
forsøk'-verdien kortere enn ett døgn (4 timer er en vanlig
standardverdi).

Slik jeg forstår problemet, gjøres forsøkene langt oftere men til
forskjellige mottakere. Mailene som ligger i kø blir ikke forsøkt fordi
de nye mailer til samme server feiler.

Problemet er
- grålisting gjøres per mottaker-adresse
- resending gjøres per server

Du har aldri noen garanti for at den sendende serveren vil forsøke den
samme mottaker-adressen som feilet sist, dersom den har flere mottaker-
adresser å velge blant. Grålisting virker bare pålitelig mot servere
der du alltid mottar under 1 mail per retry-intervall.

Alle andre servere bør whitelistes.


Bjørn

[Ingeborg Østrem Hellemo]

Er det noen annen god løsning på dette enn å flytte de nevnte mailboksene
over til vår server og dermed ungå forwardingen?

Hvitlist den eksterne serveren. Du vet jo at du ønsker å motta disse
meldingene. Dersom den eksterne serveren hadde oppført seg som forventet
med tanke på resending av meldinger ville alt den sendte uansett slippe
gjennom grålistinga til slutt. Ingen vits å bruke tid på å overbevise
eksterne administratorer om at de har gjort noe feil.

[Olaf Berli]

Post by Ingeborg Østrem Hellemo

Er det noen annen god løsning på dette enn å flytte de nevnte mailboksene
over til vår server og dermed ungå forwardingen?

Hvitlist den eksterne serveren. Du vet jo at du ønsker å motta disse
meldingene. Dersom den eksterne serveren hadde oppført seg som forventet
med tanke på resending av meldinger ville alt den sendte uansett slippe
gjennom grålistinga til slutt. Ingen vits å bruke tid på å overbevise
eksterne administratorer om at de har gjort noe feil.

Takk for info - også til Bjørn og Peter!

Tror kanskje at jeg forklarte litt uklart....

For å ikke bruke reelle adresser - jeg har en mailkonto og eget domene
(bbbb.no) hos ISP. Det er ingen grålisting eller annen spambeskyttelse
på denne kontoen.
Har også en konto på egen mailserver, under domene xxxx.no. Denne
serveren kjører grålisting som fungerer utmerket for domene xxxx.no.

Til konto bbbb.no hos ISP kommer det inn litt legitim mail og masse
spam. Når dette forwardes tar grålistingen på vår mailserver hånd om
spamen, fordi det ser ut som om den kommer fra opprinnelig avsender.

Hvis jeg hvitlister ISP's mailserver åpner jeg dermed for alt av både
spam og legitim mail som har blitt sendt til aaaa.no. Det er dette jeg
forsøker å unngå.....

Olaf

[Kjetil Torgrim Homme]

Post by Olaf Berli
Har også en konto på egen mailserver, under domene xxxx.no. Denne
serveren kjører grålisting som fungerer utmerket for domene xxxx.no.
Til konto bbbb.no hos ISP kommer det inn litt legitim mail og
masse spam. Når dette forwardes tar grålistingen på vår mailserver
hånd om spamen, fordi det ser ut som om den kommer fra opprinnelig
avsender.

eg har aldri høyrt om andre som brukar adressa frå headerane i
grålistings-tuplet, men det har forsåvidt ikkje så frykteleg mykje å
seie. det viktige poenget er at grålisting sperrar ute *tenarar*,
ikkje enkeltavsendarar. sidan all e-posten hos bbbb.no vert handtert
av same tenar(ane) med eins policy, vil dei anten prøve på nytt
alltid, eller aldri. kven som står som avsendar av meldingane bryr
dei seg ikkje om når dei køyrer køa.

[Peter N. M. Hansteen]

Post by Kjetil Torgrim Homme
grålistings-tuplet, men det har forsåvidt ikkje så frykteleg mykje å
seie. det viktige poenget er at grålisting sperrar ute *tenarar*,
ikkje enkeltavsendarar.

Skal man være pedant, så er vel primærnøkkel avsenderens IP-adresse,
uten at det endrer på meningsinnholdet du fremfører.

[Kjetil Torgrim Homme]

Post by Peter N. M. Hansteen

Post by Kjetil Torgrim Homme
grålistings-tuplet, men det har forsåvidt ikkje så frykteleg
mykje å seie. det viktige poenget er at grålisting sperrar ute
*tenarar*, ikkje enkeltavsendarar.

Skal man være pedant, så er vel primærnøkkel avsenderens
IP-adresse, uten at det endrer på meningsinnholdet du fremfører.

"avsendar" er eit litt farleg ord, sidan det lett kan mistydast. det
er ikkje opprinneleg avsendar, sidan det er umogleg å vite sikkert,
men avsendar for siste hoppet til din tenar.

tuplet (primærnøkkelen) kan innehalde så mangt. den eksperimentelle
grålistingsdemonen på UiO brukar konvoluttmottakar og -sendar pluss
ein hash over Date og Subject, og i tillegg IP-adressa. for
IP-adressa sin del er det tilstrekkeleg at dei fyrste tre oktettane
stemmer. ein IP som har vist at han prøver på nytt på rett måte er
kvitelista i minst 5 veker for å takle utsendingar som skjer ein gong
i månaden. likevel har vi sett litt for mange tilfelle av legitim
avvist e-post til at vi vil slå det på for alle brukarane våre.
t.d. Facebook måtte vi kviteliste manuelt. det er dessverre ikkje
realistisk å kunne sjekke loggane grundig nok over tid til at slike
tilfelle vert oppdaga, vi snakkar om over ein gigabyte med logg kvar
einaste dag.

[Peter N. M. Hansteen]

Post by Kjetil Torgrim Homme
"avsendar" er eit litt farleg ord, sidan det lett kan mistydast. det
er ikkje opprinneleg avsendar, sidan det er umogleg å vite sikkert,
men avsendar for siste hoppet til din tenar.

ja, "avsender" er litt vel upresist, det har du helt rett i. det vil
alltid være snakk om siste hopp.

Post by Kjetil Torgrim Homme
den eksperimentelle grålistingsdemonen på UiO

en ny og uavhengig implementasjon, altså? Er dette noe som omverdenen
har en sjanse til å få innsyn i sånn etterhvert?

[Jan Ingvoldstad]

Post by Kjetil Torgrim Homme
tuplet (primærnøkkelen) kan innehalde så mangt. den eksperimentelle
grålistingsdemonen på UiO brukar konvoluttmottakar og -sendar pluss
ein hash over Date og Subject, og i tillegg IP-adressa. for
IP-adressa sin del er det tilstrekkeleg at dei fyrste tre oktettane
stemmer. ein IP som har vist at han prøver på nytt på rett måte er
kvitelista i minst 5 veker for å takle utsendingar som skjer ein gong
i månaden.

Men hva tolker dere som "rett måte"?

RFC-en tillater implisitt at en MTA kan prøve en annen MX
øyeblikkelig. Flere grålistingsimplementasjoner tolker dette som at
MTA-en er feilkonfigurert, mens den strengt tatt følger standarden;
den har jo ikke prøvd å sende til samme MX flere ganger innen 30
minutter.

Post by Kjetil Torgrim Homme
likevel har vi sett litt for mange tilfelle av legitim
avvist e-post til at vi vil slå det på for alle brukarane våre.
t.d. Facebook måtte vi kviteliste manuelt. det er dessverre ikkje
realistisk å kunne sjekke loggane grundig nok over tid til at slike
tilfelle vert oppdaga, vi snakkar om over ein gigabyte med logg kvar
einaste dag.

Nei, det er ikke en spesielt overkommelig oppgave, 1 GB er vel ca. 6
millioner linjer. Det går kanskje an å gjøre en rudimentær analyse
maskinelt, men det vil fortsatt være rom for mange feil.

[Peter N. M. Hansteen]

Post by Jan Ingvoldstad
RFC-en tillater implisitt at en MTA kan prøve en annen MX
øyeblikkelig. Flere grålistingsimplementasjoner tolker dette som at
MTA-en er feilkonfigurert, mens den strengt tatt følger standarden;
den har jo ikke prøvd å sende til samme MX flere ganger innen 30
minutter.

Det høres ut som en litt sær tolkning, ja. Det kan være et visst
poeng å registrere hvis en maskin kontakter MXene i feil rekkefølge
(valgfritt i spamd hvis man synkroniserer mellom flere), men direkte
feil er det vel ikke å prøve nestemann på listen umiddelbart.

Post by Jan Ingvoldstad

Post by Kjetil Torgrim Homme
likevel har vi sett litt for mange tilfelle av legitim
avvist e-post til at vi vil slå det på for alle brukarane våre.
t.d. Facebook måtte vi kviteliste manuelt.

for den delen av verden som bruker mange utgående SMTP-servere med nye
leveringsforsøk fra tilfeldig maskin, kan det være grunn til å
permanent hvitliste de maskinene som er oppgitt som gyldige sendere
via SPF, som i

***@thingy:~$ host -ttxt facebook.com
facebook.com descriptive text "v=spf1 mx ip4:204.15.23.128/27 ip4:204.15.20.0/24 ip4:204.15.22.80 ip4:204.15.23.140 ip4:204.15.23.168/30 ~all"

Slik kan SPF-infoen faktisk være nyttig selv om man ikke helt tilhører
heiagjengen.

[Kjetil Torgrim Homme]

Post by Jan Ingvoldstad
Men hva tolker dere som "rett måte"?
RFC-en tillater implisitt at en MTA kan prøve en annen MX
øyeblikkelig. Flere grålistingsimplementasjoner tolker dette som
at MTA-en er feilkonfigurert, mens den strengt tatt følger
standarden; den har jo ikke prøvd å sende til samme MX flere
ganger innen 30 minutter.

hos oss vert nye forsøk ignorert til det har gått 5 minutt eller
deromkring sidan fyrste forsøk. kva for ein av våre MX-ar som vert
brukt er irrelevant. det er heilt klart bra oppførsel å prøve
sekundær-MX umiddelbart, så det er litt dumt at vi sløsar bort
bandbreidda til folk i dette tilfellet. ein kan sjå dette som eit
argument mot å ha mange MX-adresser. UiO presenterer nøyaktig to
IP-adresser (med lastbalansering i bakkant), så det vil normalt
"berre" skje to bortkasta forsøk på sending før sendaren er
kvitelista.

[Bjørn Mork]

ein kan sjå dette som eit argument mot å ha mange MX-adresser. UiO
presenterer nøyaktig to IP-adresser (med lastbalansering i bakkant),

Hmm, hvorfor ikke bare én? Er det for å være oppe i de få tilfellene du
må ta ned lastbalanseringsboksen? Er det virkelig nødvendig?


Bjørn

[Kjetil Torgrim Homme]

Post by Bjørn Mork

ein kan sjå dette som eit argument mot å ha mange MX-adresser.
UiO presenterer nøyaktig to IP-adresser (med lastbalansering i
bakkant),

Hmm, hvorfor ikke bare én?

det har vel mest historiske årsaker.

Post by Bjørn Mork
Er det for å være oppe i de få tilfellene du må ta ned
lastbalanseringsboksen?

det er eit argument. no skal det seiast at lastbalanseringsboksen har
vore oppe i 497 + 477 dagar (snart tid for passering av den magiske
32-bit tick-grensa i Linux 2.4 for andre gong!)

Post by Bjørn Mork
Er det virkelig nødvendig?

eigentleg ikkje. det største argumentet for at smtp.uio.no skal vere
100% tilgjengeleg er for at brukarane våre skal kunne sende e-post,
for mottak har nokre minutt nedetid ingenting å seie (ellers hadde
grålisting vore ganske uaktuelt :-)

[Olaf Berli]

Post by Kjetil Torgrim Homme

Post by Olaf Berli
Har også en konto på egen mailserver, under domene xxxx.no. Denne
serveren kjører grålisting som fungerer utmerket for domene xxxx.no.
Til konto bbbb.no hos ISP kommer det inn litt legitim mail og
masse spam. Når dette forwardes tar grålistingen på vår mailserver
hånd om spamen, fordi det ser ut som om den kommer fra opprinnelig
avsender.

eg har aldri høyrt om andre som brukar adressa frå headerane i
grålistings-tuplet, men det har forsåvidt ikkje så frykteleg mykje å
seie. det viktige poenget er at grålisting sperrar ute *tenarar*,
ikkje enkeltavsendarar. sidan all e-posten hos bbbb.no vert handtert
av same tenar(ane) med eins policy, vil dei anten prøve på nytt
alltid, eller aldri. kven som står som avsendar av meldingane bryr
dei seg ikkje om når dei køyrer køa.

Stusser litt over at grålistingen stenger ute kun servere. Jeg kjenner
ikke detaljene om hvordan vår server håndterer grålistingen, men det ser
ut til at den stenger enkeltmeldinger basert på de tre første oktettene
i avsenders ip-adresse + avsenders mailadresse + noe til.... (produktet
heter Office Logic InterChange - www.lan-aces.com)

Jeg ser at dette tilfellet kan være litt "sært" ettersom den aktuelle
mailserveren (hos ISP) samler opp mail for så å videresende alt inn til
vår server med grålisting. Ved å hvitliste denne serveren vil jeg
effektivt sette grålistingen ut av spill, og det er egentlig ikke
ønskelig. Det kan se ut til at mail for det aktuelle domenet bør
betjenes direkte på vår server for å unngå dette mellomleddet.

Takker for interessant diskusjon. Har definitivt bidratt til å friske
opp litt rustne SMTP-kunnskaper....

Olaf

[Bjørn Mork]

Post by Olaf Berli
Stusser litt over at grålistingen stenger ute kun servere. Jeg kjenner
ikke detaljene om hvordan vår server håndterer grålistingen, men det
ser ut til at den stenger enkeltmeldinger basert på de tre første
oktettene i avsenders ip-adresse + avsenders mailadresse + noe
til.... (produktet heter Office Logic InterChange - www.lan-aces.com)

På din side kan du selvsagt se på så mange paramtre du bare vil,
inkludert vær, stjernekonstellasjoner osv. Men serveren som forsøker å
sende deg mail vil allikevel kun registrere at sendingen til _din ip-adresse_
feilet, og det cacher den.



Bjørn

[Odd Skjaeveland]

Olaf Berli:
[...]

Post by Olaf Berli
Stusser litt over at grålistingen stenger ute kun servere. Jeg
kjenner ikke detaljene om hvordan vår server håndterer grålistingen,
men det ser ut til at den stenger enkeltmeldinger basert på de tre
første oktettene i avsenders ip-adresse + avsenders mailadresse +
noe til...

Terminologien er kanskje ikke helt god. I stedet for at grålisting
stenger ute servere, ville jeg foretrukket å si at grålisting får en
SMTP-server til å skremme bort SMTP-klienter for en periode, dvs
midlertidig skremme bort.

Lett popularisert i håp om å belyse faktorer det synes som om du
overser eller misforstår:

SMTP-serveren i din ende forteller ikke SMTP-klienten "du er
grålistet", "meldingen din er grålistet", "kombinasjonen av
e-postadresse og ip-adresse er grålistet" eller noe i den
dur. SMTP-serveren forteller SMTP-klienten at "det har oppstått en
midlertidig feil i min ende, prøv igjen senere".

SMTP-klienten - som etter det jeg forstår, bor på en boks hos din ISP
- mottar feilmeldingen og registrerer dette som at SMTP-server a.b.c.d
har problemer og kan foreløpig ikke motta e-post.

SMTP-klienten har ingen anelse om hvorfor SMTP-serveren meldte
midlertidig feil. SMTP-serveren vet selvsagt at den meldte midlertidig
feil på grunn av en kombinasjon av mottakerens e-postadresse,
senderens e-postadresse og SMTP-klientens IP-adresse.

Hvis SMTP-klienten registrerer at senere forsøk på å levere e-post til
SMTP-server a.b.c.d, enten det nå er første forsøk på å levere en helt
fersk melding eller n'te forsøk på å levere en eldre melding, fortsatt
fører til melding om midlertidig feil hos serveren, registrerer
SMTP-klienten at SMTP-server a.b.c.d fortsatt har problemer ikke kan
motta e-post.

Hvis SMTP-klienten lar være å prøve på nytt, hjelper det ikke om
SMTP-serveren har bestemt seg for å ikke skremme den mer for en
bestemt kombinasjon av e-postadresser og IP-adresse.

[Olaf Berli]

Post by Odd Skjaeveland
[...]

Post by Olaf Berli
Stusser litt over at grålistingen stenger ute kun servere. Jeg
kjenner ikke detaljene om hvordan vår server håndterer grålistingen,
men det ser ut til at den stenger enkeltmeldinger basert på de tre
første oktettene i avsenders ip-adresse + avsenders mailadresse +
noe til...

Terminologien er kanskje ikke helt god. I stedet for at grålisting
stenger ute servere, ville jeg foretrukket å si at grålisting får en
SMTP-server til å skremme bort SMTP-klienter for en periode, dvs
midlertidig skremme bort.
Lett popularisert i håp om å belyse faktorer det synes som om du
SMTP-serveren i din ende forteller ikke SMTP-klienten "du er
grålistet", "meldingen din er grålistet", "kombinasjonen av
e-postadresse og ip-adresse er grålistet" eller noe i den
dur. SMTP-serveren forteller SMTP-klienten at "det har oppstått en
midlertidig feil i min ende, prøv igjen senere".
SMTP-klienten - som etter det jeg forstår, bor på en boks hos din ISP
- mottar feilmeldingen og registrerer dette som at SMTP-server a.b.c.d
har problemer og kan foreløpig ikke motta e-post.
SMTP-klienten har ingen anelse om hvorfor SMTP-serveren meldte
midlertidig feil. SMTP-serveren vet selvsagt at den meldte midlertidig
feil på grunn av en kombinasjon av mottakerens e-postadresse,
senderens e-postadresse og SMTP-klientens IP-adresse.
Hvis SMTP-klienten registrerer at senere forsøk på å levere e-post til
SMTP-server a.b.c.d, enten det nå er første forsøk på å levere en helt
fersk melding eller n'te forsøk på å levere en eldre melding, fortsatt
fører til melding om midlertidig feil hos serveren, registrerer
SMTP-klienten at SMTP-server a.b.c.d fortsatt har problemer ikke kan
motta e-post.
Hvis SMTP-klienten lar være å prøve på nytt, hjelper det ikke om
SMTP-serveren har bestemt seg for å ikke skremme den mer for en
bestemt kombinasjon av e-postadresser og IP-adresse.

Fin forklaring. Takk!

Må (motvillig) innrømme at det gikk opp et lite lys nå (det burde ikke
ha sluknet, men det er lenge siden sist jeg jobbet med SMTP).
Har nok fokusert litt ensidig på hva som skjer hos oss og ikke på ISP's
mailserver som jo i dette tilfellet blir klienten. Slik oppsettet er nå,
vil ISP's server (vår klient) samle mail fra en rekke andre servere (som
kanskje sender bare en eller noen få mailer pr. dag). Den vil dermed
nesten hele tiden bli brutt på grunn av vår grålisting.

Ser nok ut til at dette mellomleddet med fordel kan droppes...

Olaf

[Bjørn Mork]

Post by Olaf Berli
Kjører grålisting på mailserveren vår og den ser ut til å fungere
bra. Den fjerner hvertfall det meste av spamen...
Har også et domene med noen få mailkonti hos en ekstern leverandør, og
har satt opp disse kontiene med forwarding til respektive brukere i
vårt domene (på vår mailserver). Dette har fungert fint lenge, men nå
ser det ut til at mail på den eksterne serveren hoper seg opp og ikke
blir videresendt (eller blir videresendt kun en gang i døgnet eller
deromkring).
Det ser ut til at når en mail kommer inn til ekstern server blir den
akseptert der, forwardet og lagt i utgående kø til vår server. Når vår
grålisting bryter forbindelsen forsøker den eksterne serveren re-send,
og skulle da slippe igjennom. Hvis det imidlertid har kommet flere
mailer inn i køen før det blir gjort en resend av den første (og disse
også har blitt "satt på vent" av grålistingen), så ser det ut til at
den eksterne serveren konkluderer med at det er et problem med vår
server og begynner å legge all mail i kø - uten å forsøke å sende noe
som helst. Etter noen timer (kanskje et døgn) gjør den et nytt forsøk
og får sendt alle meldingene i køen.
Vet ikke om jeg har misforstått SMTP protokollen, men har oppfattet
det slik at resend (med økende intervaller) skal skje pr. individuelle
melding?

Du har misforstått. Strategien din upstream-server bruker er tvert imot
anbefalt. Utvalgte sitater fra RFC2821:

The sender MUST delay retrying a particular destination after one
attempt has failed. In general, the retry interval SHOULD be at
least 30 minutes; however, more sophisticated and variable strategies
will be beneficial when the SMTP client can determine the reason for
non-delivery.
[..]
A client SHOULD keep a list of hosts it cannot reach and
corresponding connection timeouts, rather than just retrying queued
mail items.
[..]
An SMTP client may have a large queue of messages for each
unavailable destination host. If all of these messages were retried
in every retry cycle, there would be excessive Internet overhead and
the sending system would be blocked for a long period. Note that an
SMTP client can generally determine that a delivery attempt has
failed only after a timeout of several minutes and even a one-minute
timeout per connection will result in a very large delay if retries
are repeated for dozens, or even hundreds, of queued messages to the
same host.

Post by Olaf Berli
Er det noen annen god løsning på dette enn å flytte de nevnte
mailboksene over til vår server og dermed ungå forwardingen?

Du må permanent whiteliste alle mailservere som mottar mail på dine
vegne.

Grålisting kan fremdeles feile dersom du mottar mye mail til
forskjellige brukere fra en og samme server. Det kan derfor være lurt å
føre statistikk over slikt, og manuelt whiteliste servere som sender deg
mye (legitim) mail.


Bjørn

[Tor Willy Austerslått]

Post by Bjørn Mork
Du må permanent whiteliste alle mailservere som mottar mail på dine
vegne.

Tiltredes. Poenget med å drifte en mailserver er jo ikke å få mindre spam,
men å motta mail. Det høres kanskje dumt ut nå for tiden, når
signal/støyforholdet på SMTP når 10% på en god dag, men utgangspunktet bør
være at det faktisk kommer en og annen legitim e-post.

Forøvrig er jeg litt skeptisk til grålisting som anti-spamtiltak, i og med
at man med grålisting har begynt å bevege seg over i de delene av
SMTP-protokollen som er nokså romslig spesifisert. I det minste er delen som
omhandler forsinket levering og prøv-på-nytt-funksjonalitet gjenstand for
flere tolkninger enn resten.

Resultatet (worst case, altså) ser vi jo her: tolkning av en ikke helt
klokkeklar protokoll fører til misfornøyde brukere. Personlig spanderer jeg
heller litt CPU og disk (les: DNSBL og filtrering i etterkant) enn å sitte i
telefonen og forklare (igjen) at det å få en mail baserer seg på svært mye
flaks. Hjelper ikke om det er viktige forretningsdokumenter inni mailen.

Og, som det ble nevnt, å "oppdra" andre mailadmins er helt nytteløst. Der
den ene sier "jammen vi har jo en svindyr Barracuda!" sier den andre "jammen
vi har jo grålisting!".