Userbase

Sinds kort (een week of twee) krijg ik bericht van collega's dat bepaalde mails niet meer afgeleverd worden op een @skynet.be-emailadres. Ze krijgen bericht van de corporate mailserver dat hun bericht niet afgeleverd kon worden: Het lijkt erop dat de Skynet-server berichten die door de corporate mailserver aangenomen worden, maar meteen en integraal doorgestuurd worden naar een @skynet.be-emailadres, weigert.
Hoe kan ik ervoor zorgen dat die emails wél doorkomen? Het lijkt momenteel vnl. te gebeuren met emails afkomstig van Yahoo en LinkedIn.

Even schematisch: waarbij Yahoo stuurt naar het corporate emailadres en de corporate mailserver doorstuurt naar Skynet.

Iemand al iets gelijkaardigs meegemaakt en een oplossing voor gevonden? Ik lijk in de richting van DKIM/DMARC te moeten gaan zoeken, maar veel gerichte info is er niet te vinden. De corporate mailserver draait momenteel Exchange 2007.

zou natuurlijk handiger zijn, moesten we bv de dns records van je corporate server al een keer erbij kunnen halen
(spf? dkim? hoe geconfigureerd?)

wat ik eveneens niet snap: wat is het nut van iemand naar een corporate server te laten mailen,
om dan gewoon rechtstreeks door te sturen naar een skynet adres?
dan is het imho toch logischer van die tussenstap eruit te laten....

SPF-info is momenteel als TXT-record gedefinieerd als Er wordt anders niets opgegeven van SPF of DKIM. Deze SPF-info is vooral bedoeld om fake-emailverkeer vanaf onze mailserver te kunnen afvangen.

Waarom iemand naar een corporate server laten mailen? Alle medewerkers hebben een corporate emailadres, maar een aantal onder hen vragen om dat meteen ook te forwarden naar hun privé-email. Die tussenstap zou er in principe vantussen kunnen, maar staat uniformiteit in de weg. Niet iedereen moet ook weten dat ze eigenlijk [email protected] of [email protected] gebruiken...

heb dmarc zelf nog niet (volledig) actief staan, maar ik vermoed dat de spf check faalt omdat je die tussenstap doet,
en daar gaat dmarc op falen.


- je hebt een mail, komende van een yahoo domein, gesignd door hen, DMARC reject policy
- die ga je eigenlijk "onderscheppen" bij jouw en dan terug doorsturen
- sender / signature komen niet meer overeen met die origineel van yahoo
- skynet checkt en weigert mail

oplossing... euh, geen yahoo gebruiken, en anders rechtstreeks mailen ipv via tussenstappen.

andere oplossing zou misschien ook nog zijn dat je de mail gaat manipuleren bij de tussenstap,
maar ik denk dat je (zonder het wijzigen van originele sender/domain) er niet veel aan kan doen.

edit:

met sieve kan je bv deze regel toepassen om het te omzeilen:

require ["editheader"];
if allof(header :contains "From" "@yahoo.com")
{
deleteheader "From";
addheader "From" "<[email protected]>";
deleteheader: "DKIM-Signature";
}

positief: mails zullen aanvaard worden door skynet
negatief: je hebt geen originele from meer, dus kan geen reply doen

je zegt overigens dat het nut net is dat de mensen dan het prive adres van de medewerkers niet zien, maar van de moment dat ze reply drukken,
dan zien ze dat weer wél... of is dat bij elke medewerker ingesteld dat ze mooi reply'en met het werk-adres vanaf hun prive?

Ben ik nu de enige die dit allemaal verschrikkelijk ingewikkeld vind?

Een forward is toch niet meer dan een "nieuwe" mail. Dus de mail die bij skynet afgeleverd wordt, is voor zover skynet kan zien gewoon afkomstig van de corporate mailserver. Bij de forward verdwijnen de originele e-mail headers.
Tenzij hier iets anders gebeurt dan een gewone forward, bijv. een of andere mail intercept/relay. Lijkt me echter geen standaard praktijk...

Je kan ook altijd bij skynet eens informeren over de precieze oorzaak.

Heb ook nog dit gevonden http://support.hostgator.com/articles/s ... ion-emails ook hier spreken ze expliciet over probleem met yahoo adressen...

selder schreef:Ben ik nu de enige die dit allemaal verschrikkelijk ingewikkeld vind?

ik heb al jaren het idee dat alles wat betreft mail zowat het moeilijkste is aan systeembeheer

je merkt echt dat het kat en hond is tegen de spammers, en dat je wel een aantal goede concepten hebt,
die eigenlijk niet werken of niet geimplementeerd worden...
die dan vervolgens opgevolgd worden en hetzelfde voorhebben.

en dan moet je maar proberen mee te blijven gaan... maar DMARC heeft het voordeel dat je deze eerst kan controleren,
doordat je een reporting optie hebt zonder dat je een policy moet enforcen.
dus dat is wel weer handig.

@didi : een gewone forward gaat je from header niet aanpassen (dus originator blijft [email protected]) maar wel het ip,
waardoor de mail die bij skynet aankomt voor skynet dus afkomstig is van een domein dat niet toegelaten is om een from: van yahoo te hebben.

Het probleem wordt niet enkel gemeld met Yahoo-adressen, maar ook met notificaties van LinkedIn.
De oplossing die Splitter aanreikt kan volgens mij wel werken, op voorwaarde dat de oorspronkelijke From als Reply-To ingesteld wordt. Het werkt echter wel vervelend omdat het voor de uiteindelijke ontvanger lijkt alsof hij zichzelf een email gestuurd heeft. Om dan verdere acties op zo'n aangepast bericht in te stellen (Rules and Alerts), wordt wat lastig(er).
Een andere oplossing schijnt erin te bestaan om de DKIM-header uit het bericht te slopen, maar in hoeverre je dan geen andere ongewenste neveneffecten creëert... Ik zie het nl. nog gebeuren dat Skynet ervan uitgaat dat alles vanaf Yahoo een DKIM-header heeft en als dat niet het geval is, ermee gefoefeld is en dus geweigerd mag worden.

Sinds mensenheugenis hebben wij grey-listing aanstaan op onze mailserver, en de hoeveelheid spam is met euh-ik-gok-maar 80% gedaald...

@Selder: greylisting heb ik ook geïmplementeerd, maar dat staat m.i. los van mijn initiële bericht.

Het is gewoonte om ambetante vragen te stellen in de IT wereld dus... Waarom moeten mails naar een persoonlijk adres worden gestuurd?

Omdat ze dat vragen (lees: eisen). Zie het als luiheid om een extra mailbox in de gaten te houden.

Ondertussen zijn we een week verder...
Nog iemand tips or tricks?

afaik zijn er geen andere manieren dan degene reeds aangehaald.
simpelweg omdat dit het hele punt van DMARC zou teniet doen.

dmarc is eigenlijk : ontvangende mailserver controleert versturend domain mailserver voor authenticiteit
gezien in dit geval de mailserver dus die van jou is, terwijl de domain mailserver die van yahoo is, krijg je een ongeldige authenticatie.
en dus is de volgende stap de policy verplicht te volgen...
in het geval van yahoo is de policy al reject en dus zal de ontvangende mailserver -terecht- de mail NIET afleveren.

als al de mailservers meespeelden met dmarc zou er bijna geen spam meer zijn, althans niet van gespoofde mail adressen,
maar inderdaad "breek" je daar een aantal dingen mee, zoals relaying, wat imho eigenlijk toch al een bad practice was.

wat je kan proberen is ditadres@jouwdomein als alias in te stellen van diegebruiker@skynet - maar ik heb geen idee of je mailserver dit zo toelaat (gezien je het skynet domein niet beheert) en ook geen idee of dmarc dit toelaat (of ook gewoon zou beschouwen als unauthenticated)


om "goed" te zijn moet je dus braafjes aan jouw zijde de headers veranderen, de to kopieren naar de from, en de from verplaatsen naar de reply to.
op die manier is het aan jouw mailserver om de authenticatie te doen en dmarc te publiceren (ie: mail komt dan van jouw domein ipv yahoo)
hoe je dit moet doen heb ik al eerder in deze thread gepost.

Ik wil toch nog een poging wagen, ondanks de aangedragen oplossingen die er voor mij eigenlijk geen zijn.
Zou 'Sending on Behalf Of' een mogelijkheid zijn om dit probleem te tackelen? In die zin dat de mailserver berichten in naam van de afzender stuurt?
Het zou dan iets worden als 'ICT On behalf of [email protected]'.
Ik baseer mij hiervoor op http://serverfault.com/questions/40215/ ... 0268#40268.
Indien haalbaar, dan zou ik berichten die vanaf het corporate email-adres verstuurd worden naar het privé-adres onderscheppen en daar de Sender-header toevoegen.