Onderwerp: Direct Admin exim mail en Mac users gaat vaak fout

Hi there,

bij ons komt het te vaak voor dat mac users in CSF blokkades komen door foutieve logins.
We hebben al een exim patch/config toegepast daar het een bekend probleem lijkt te zijn.

We zien veel (even uit mijn hoofd) AB/023 logins in de logs.

Heeft iemand ook deze ervaringen en wat is bij jullie de oplossing?

Klanten leren om password goed in te vullen? Wij hebben een hoop Mac users (ben er zelf ook eentje sinds kort), maar heb nergens problemen mee.

Ook wij hebben een klant die met hetzelfde probleem zit. Helaas niet consequent en heeft niets te maken met foutief wachtwoord.

Lastig om te debuggen, en volgens mij heeft de klant de hoop al opgegeven.

Komen ze in de fw vanwege smtp of imap/pop3 logins?

SMTP , en we hebben deze fix al een tijd staan:
http://forum.directadmin.com/showthread.php?t=48234

FW inderdaad vanuit CSF,

we hebben nu laatste week ineens een flinke groei aan problemen hiermee.

Wat voor exim.pl versie heb je?

En heb je in je exim.conf de authenticators zo staan:

begin authenticators

login:
driver = plaintext
public_name = LOGIN
server_prompts = "Username:: : Password::"
server_condition = "${perl{smtpauth}}"
server_set_id = $1

plain:
driver = plaintext
public_name = PLAIN
server_prompts = :
server_condition = "${perl{smtpauth}}"
server_set_id = $2

(let op de volgorde, login eerst, dan plain).

Oorspronkelijk geplaatst door Mikey

Ook wij hebben een klant die met hetzelfde probleem zit. Helaas niet consequent en heeft niets te maken met foutief wachtwoord.

Lastig om te debuggen, en volgens mij heeft de klant de hoop al opgegeven.

Er zijn wel wat opties .
Belangrijk is natuurlijk om te kijken of het IP wat de foutieve logins doet hetzelfde is als waar normaal goede logins vandaan komen.

Wat natuurlijk zou kunnen is als de klant de server gegevens (ook) eens op iPad/smartphone (fout/incompleet) heeft ingesteld, en zo af en toe min of meer tegelijkertijd met een fout inloggend en goed inloggend device werkt en dan het probleem merkt.
Als dat op hetzelfde netwerk is (wifi thuis) zul je dat alleen niet zien aan verschillende source IPs.

Het zou nog kunnen dat je de ban-trigger wat vaker van een ander IP ziet . (bv 3g reeks, dan ligt een telefoon wel erg voor de hand).

Verder zou de klant nog bij (andere) mailaccounts in de Apple Mail client de DA mail server met andere/missende login gegevens ingesteld kunnen hebben . Dan zal de foutieve login ook alleen gebeuren wanneer de klant vanaf die identiteit mail stuurt .
Dan heb je zelfs geen tweede device nodig.

Apple is vrij consequent om login gegevens in de keyring op te slaan, oftewel, na aanmaken krijg je weinig popups voor password meer.
In principe test hij bij het nieuw aanmaken wel of een account/identeit werkt, maar dat kun je negeren.

Paar opties binnen CSF:
- ip whitelisten
- bepaalde landen uitsluiten van automatische blokkade. Bijvoorbeeld ip-adressen vanuit Nederland of België.

Oorspronkelijk geplaatst door visser

Er zijn wel wat opties .
Belangrijk is natuurlijk om te kijken of het IP wat de foutieve logins doet hetzelfde is als waar normaal goede logins vandaan komen.

Wat natuurlijk zou kunnen is als de klant de server gegevens (ook) eens op iPad/smartphone (fout/incompleet) heeft ingesteld, en zo af en toe min of meer tegelijkertijd met een fout inloggend en goed inloggend device werkt en dan het probleem merkt.
Als dat op hetzelfde netwerk is (wifi thuis) zul je dat alleen niet zien aan verschillende source IPs.

Het zou nog kunnen dat je de ban-trigger wat vaker van een ander IP ziet . (bv 3g reeks, dan ligt een telefoon wel erg voor de hand).

Verder zou de klant nog bij (andere) mailaccounts in de Apple Mail client de DA mail server met andere/missende login gegevens ingesteld kunnen hebben . Dan zal de foutieve login ook alleen gebeuren wanneer de klant vanaf die identiteit mail stuurt .
Dan heb je zelfs geen tweede device nodig.

Apple is vrij consequent om login gegevens in de keyring op te slaan, oftewel, na aanmaken krijg je weinig popups voor password meer.
In principe test hij bij het nieuw aanmaken wel of een account/identeit werkt, maar dat kun je negeren.

Het technische vlak meer dan goed naar gekeken. En betwijfel ook da het daar aan zal liggen server side.

Mocht de klant nog een keer erover beginnen, dan zal ik hem attenderen op de keyring !

Komt ie

Bleek aan onze kant fout omdat we een verkeerde SSL cert hadden toegekend aan exim op een server en op een andere dit nog niet hadden gedaan.
Nu blijkt dat onze vrienden van appelmoes vaak eerst SSL proberen en dan normaal, waardoor aan onze kant de logins "scrambled" binnenkomen.

wbt CSF whitelisting: kan, maar dat is niet onze policy, ook bij klanten gaat het wel eens goed fout.