Ik zal dit even overleggen wat handig is.
>Daarnaast: ik had een domein in de blacklist gezet en zie nu dat
>deze zonder medeweten is verhuist naar de greenlist, hoe kan dat?
Kan je dit reproduceren? Weet je zeker dat je hem niet per ongeluk
in je greenlist tab hebt ingevoerd?
Cor
Ik had er twee in de blacklist gezet, deze lijst was initeel leeg en
er waren daarna twee domains zichtbaar. In de greenlist stonden er
meerdere. Het zou me dus opgevallen moeten zijn als ik de verkeerde
lijst gebruikt zo hebben.Een uur daarna waren ze uit de blacklist
naar de greenlist 'verhuisd'.
Ik heb ze er opnieuw ingezet en zal laten weten of er iets veranderdt.
--
Wil
Spammers gebruiken telkens weer andere afzender adressen. Dus als een
unsubscribe onveilig is omdat het spam is, dan heeft zo'n blacklist niet
veel zin.
--
That was it. Done. The faulty Monk was turned out into the desert where it
could believe what it liked, including the idea that it had been hard done
by. It was allowed to keep its horse, since horses were so cheap to make.
-- Douglas Adams in Dirk Gently's Holistic Detective Agency
Een vraag over domeinnamen:
Er mogen geen kale TLDs opgegeven worden, 'cn' mag dus niet.
Als ik edu.cn intik mag het wel.
Ben ik dan ook van spa...@bladibla.edu.cn af?
> De blacklist is niet bedoelt om complete continenten uit te sluiten, maar
> om specifieke vervelende afzenders of domeinen uit te sluiten.
Waarom deze willekeurige beperking?
Je hebt een hele grote database nodig als iedereen
alle chinezen wil gaan blokken.
Ik zou het blokken op TLD nivo toestaan.
Het bespaart mailsysteem belasting.
Zie ook andere reactie.
Dat had je willen lezen. Maar dat werkt dus niet.
Ik was dan ook een beetje verbaasd toen ik zag dat je dit geimplementeerd
hebt.
Filteren op afzender adres dat kunnen de meeste mailprogramma's zelf ook
al jaren, en gebruikers weten allang dat je daar niks aan hebt.
Als ik kijk naar mijn spam dan komt het overgrote deel van random afzender
adressen. Die kan ik wel gaan blacklisten maar daarmee bouw ik alleen
een lijst van onschuldige mailadressen op waar daarna nooit meer mail
vandaan zal gaan komen.
Daarnaast heb je dan de "ongewenste mail van bedrijven waar je wel eens
wat gekocht hebt" wat toch min of meer een mailinglist is waar je eigenlijk
gewoon van zou moeten (kunnen) unsubscriben. Ik heb bijvoorbeeld last
van mail van de Volkskrant waar een vorige eigenaar van een alias die
ik heb bij XS4ALL zich ooit voor heeft opgegeven. Daar kom ik niet meer
vanaf want om te unsubscriben moet ik een usernaam en password hebben en
die weet ik uiteraard niet, en mailen naar de krant resulteert alleen maar
in dom "u staat niet op onze lijst hoor" geouwehoer.
Die lui blacklist ik locaal, maar om de zoveel maanden veranderen ze
weer hun afzender adres waardoor de shit toch weer binnenkomt.
Ik denk dat je met het blacklisten van afzender adressen al heel snel
de kant uit gaat die je niet uit wilt gaan (unsubscriben door te blacklisten)
en dat de klanten lijsten van nutteloze geblokkeerde adressen opbouwen
die je tot in het einde der tijden in je database moet houden, en dat
er niet of nauwelijks iets nuttigs uit gaat komen.
(dwz de klant krijgt nog net zo veel spam in de categorie die het
hinderlijkst en/of het gevaarlijkst is)
Dit was een verzoek vanuit de produkt management kant. Blijkbaar is er wel
vraag naar bij klanten. Het schijnt uit yellowspaces te komen.
Er zijn natuurlijk wel legitieme redenen te bedenken (stalkers e.d.), maar
ik deel je angst dat 95% van de lijst nutteloos is.
Cor
Mijn ervaring is dat er wel vraag naar is. Vooral omdat ze lastig worden
gevallen door een persoon. Of een nieuwsbrief waar je niet vanaf komt.
Eenmalige simpele actie voor bij al die kennissen enzo:
wis ff hun adresboek op hun PC!
8-)
Hoezo, je homedir is toch bereikbaar met ftp/ssh/scp/etc ?
Mike.
Ik heb er ook zo eentje, die een adres heeft wat bijna gelijk aan de
mijne is. Stevast geeft hij echter mijn adres op aan zijn kennissen,
waardoor ik al hun mail toegestuurd krijg. Diverse malen verzocht mijn
adres niet meer te gebruiken, maar die kennissenkring (hogere leeftijd)
schijnt al blij te zijn dat ze op de verzend knop kunnen drukken en
snappen geheel niet hoe ze mij uit hun adresboek moeten verwijderen.
Uiteindelijk maar hele aparte reacties op hun mail naar al hun
kennissen gestuurd, waaronder diverse verenigingen en uiteindelijk is
het eindelijk (tot nu tenminste) gestopt.
--
MdW.
En eindelijk een berijkbare Home natuurlijk!
--
MdW.
Niet op de popboxen.
Alleen op je hoofdaccount, of is er wat gewijzigd?
--
MdW.
Oh zo. De popboxen hebben helemaal geen homedir. Het zijn geen
volledige unix accounts. Ze gaan ook geen homedir krijgen. Sterker
nog, we denken er ook aan om het popaccount van je beheeraccount
los te koppelen van het Unix account. Inderdaad, dan kan je er
via de shell niet meer direct bij, dan moet je IMAP gebruiken.
(niet schrikken, dat idee is er al jaren, zo hard gaat het niet).
De enige reden waarom een popbox een homedir nodig zou hebben is
de .forward, .vacation en de .procmailrc files.
.forward in een homedir moeten we vanaf, da's onzinnig, dat kan net
zo goed ergens anders centraal in de mailconfiguratie, en dan werkt
het opeens voor alle popboxen ipv alleen het beheer account.
Idem .vacation.
procmail zou dan vervangen worden door Sieve, en het updaten van
de sieve rules kan via ManageSieve ( http://tools.ietf.org/html/rfc5804 ).
Dan kan dat ook grafisch vanuit service center, webmail of
zelf via een mailclient als Thunderbird.
Disclaimer: This message contains forward-looking statements that
may not be based on current or historical fact.
Mike.
*ademt in en uit in plastic zakje*
>
> De enige reden waarom een popbox een homedir nodig zou hebben is
> de .forward, .vacation en de .procmailrc files.
>
> .forward in een homedir moeten we vanaf, da's onzinnig, dat kan net
> zo goed ergens anders centraal in de mailconfiguratie, en dan werkt
> het opeens voor alle popboxen ipv alleen het beheer account.
> Idem .vacation.
>
> procmail zou dan vervangen worden door Sieve, en het updaten van
> de sieve rules kan via ManageSieve ( http://tools.ietf.org/html/rfc5804 ).
> Dan kan dat ook grafisch vanuit service center, webmail of
> zelf via een mailclient als Thunderbird.
>
Dat klinkt dan weer heel goed. En zou Sieve dan op alle popboxen
(afzonderlijk) te gebruiken zijn?
Ja,
Cor
Ha! "De" oplossing: neem een domein met een catch-all.
Ik heb een aantal van die gebruikers.
Ze hebben ook blocklists (op alle protocolmomenten en op headers)
en ze blokken gewoon op Recipient!
Je kan er ook een sub-domein voor gebruiken.
Hoofd domein heeft alleen postmaster@ en hostmaster@
en de sub-domeinen leveren af in het juiste inboxje.
Filteren op afzender in de MTA heeft wel degelijk zin.
Cor heeft nu een database om dat te bewijzen.
Ja, misschien moet ik daar eens mee experimenteren. Tot nu toe gebruik ik
een configuratie waar alles dicht staat behalve wat ik expliciet toelaat,
maar ik zou dat ook om kunnen draaien.
Die heb ik ook, MX geeft 450 totdat gebruiker aangeeft te willen ontvangen.
Zoals ik dat nu raporteer is dat 1 keer per dag.
Probleem daarmee is:
- soms stoppen ze de retry
- soms heeft de postmaster op de client een retry van *elke minuut* ingesteld