Dmarc-frustratie met XS4ALL e-mail :-(

[Arnold]

Hoewel ik zoveel mogelijk e-mail op m'n eigen domein (en eigen server)
gebruik, heb ik, om m'n privacy wat te beschermen, voor accounts als
facebook nog wel een @xs4all.nl alias. (Verschillende @<<eigen domain>>
adressen zijn immers eenvoudiger aan elkaar te koppelen dan aliassen
@xs4all.nl.) Die aliassen op m'n hoofdaccount krijgen via procmail extra
headers met de originele envelope-to/from en worden dan geforward.

XS4ALL werkt dit stukje privacybescherming nu helaas actief tegen. Dmarc,
waar ik al meer last van had, is hier wederom de oorzaak :-(

Voor degenen die nu gaan reageren dat je met privacy niet op fb moet
zijn: met dit account ben ik gelinkt aan één ander fb-account. Ook kan fb
gelukkig nog niet waterdicht controleren op zaken als 'naam' ;-)

We weten inmiddels dat dmarc niets helpt tegen phishing, want dit wordt
er niet mee voorkomen:
From: "ING BANK N.V" <in...@ingsecure-nl.be>
Mensen die in phishing trappen, trappen hier ook gewoon in. Bovendien
tonen mail clients steeds vaker alleen de 'echte' naam.


Goed, XS4ALL zal nu waarschijnlijk wél de liefdadigheidsinstelling willen
zijn die de schijnveiligheid van dmarc ondersteunt (bij fb ook errug
belangrijk). Ik zal wel weer tot die 'handvol klanten' behoren die er
last van hebben, waarvoor hier natuurlijk niets aan gedaan kan worden...
Maar, misschien verrast iemand als Jan-Pieter mij nogmaals ;-)


Hieronder de details hoe mail van facebook, via procmail, wordt
doorgestuurd (althans, dat is de bedoeling en wordt geprobeerd, maar
intern XS4ALL alsnog geblokkeerd).

Eerst de headers van het geforwarde (poging) bericht (die ik kreeg als
'oorspronkelijk bericht' in de foutmelding):

Return-Path: <arnold>
Received: (from arnold@localhost)
by mxdrop204.xs4all.nl (8.13.8/8.13.8/Submit) id s7DE69gp069265
for arnold@<<eigen domein>>; Wed, 13 Aug 2014 16:06:09 +0200
(CEST)
(envelope-from arnold)
Authentication-Results: xs4all.nl; spf=pass
smtp.mailfrom=pages.facebookmail.com; dmarc=pass
header.from=pages.facebookmail.com
Received: from mx-out.facebook.com (outcampmail004.ash2.facebook.com
[66.220.155.163])
by mxdrop204.xs4all.nl (8.13.8/8.13.8) with ESMTP id
s7DE65U4069218
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO)
for <fb......@xs4all.nl>; Wed, 13 Aug 2014 16:06:07 +0200 (CEST)
(envelope-from notification...@pages.facebookmail.com)
Received: from facebook.com (A2vXRyIUYfVCCBtWKqHly8c0....../6zT2v2Sq..../
Pbhii78mwhnd...... 10.158.104.43)
by facebook.com with Thrift id f741431a22f211e49e4d0002c9......;
Wed, 13 Aug 2014 07:06:05 -0700
X-Facebook: from 2401:db00:2040:70bc:face:0:4f:0 ([MTI3LjAu....])
by www.facebook.com with HTTP (ZuckMail);
Date: Wed, 13 Aug 2014 07:06:05 -0700
To: Arnold ...... <fb.......@xs4all.nl>
From: "Facebook" <notification+......@pages.facebookmail.com>
Reply-to: noreply <nor...@facebookmail.com>
Subject: ....... op Facebook
Message-ID: <6d6cadf581c8cbfb4......@www.facebook.com>
X-Priority: 3
X-Mailer: ZuckMail [version 1.00]
Errors-To: notification+......@facebookmail.com
X-Facebook-Notify: fbpage_fan_invite; mailid=a556dfaG5af4909c74acG......
X-FACEBOOK-PRIORITY: 0
X-Auto-Response-Suppress: All
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="b1_6d6cadf581c8cbfb........."
X-XS4ALL-DNSBL-Checked: mxdrop204.xs4all.nl checked 66.220.155.163
against DNS blacklists
X-CNFS-Analysis: v=2.1 cv=dsfiVTQ4 c=1 sm=0 tr=0 b=1
a=Z6GKVf8hNzRVb4G7beHxjA==:117 a=Z6GKVf8hNzRVb4G7beHxjA==:17
a=3j4BkbkPAAAA:8 a=_lmKfE_oAAAA:8 a=b9ZSCmUMGGsA:10 a=fxiJiu_BCqoA:10
a=k0eX_NTfPs0A:10 a=gX41StXMAAAA:8 a=8W-BSMDcTzZ5gKhAzNoA:9
a=QEXdDO2ut3YA:10 a=ZMu417LsLRwA:10 a=iV28D8A-tj8A:10 a=eBBaYUbfAAAA:8
a=_s-f7btWr44y4_-GqE4A:9 a=QL3CXS4X1u96ZOQd:21 a=_W_S_7VecoQA:10
a=a11LUS3Y_NYA:10 a=Ze6sQigKyk0A:10
X-XS4ALL-Spam-Score: 0.0 () HTML_MESSAGE, SPF_PASS, UNPARSEABLE_RELAY
X-XS4ALL-Spam: NO
Old-Envelope-To: fb......@xs4all.nl
Old-Envelope-From: notification+.......@pages.facebookmail.com


Aan de bovenste 'Received' zie je dat de mailserver mxdrop204.xs4all.nl
het procmailscript heeft verwerkt en het (als localhost) weer naar
zichzelf stuurt, waarna het naar mijn mailserver toe moet. Verderop kun
je zien dat mxdrop204 rechstreeks met mijn mailserver *kan* praten, maar
eerst nog een aantal keer tegen zichzelf praat...

Hoewel mxdrop204 *zelf* de volgende headerline toevoegt:
Authentication-Results: xs4all.nl; spf=pass
smtp.mailfrom=pages.facebookmail.com; dmarc=pass
header.from=pages.facebookmail.com
weigert die toch het bericht door te sturen!!! :-(

Ik krijg dus een foutmelding gegenereerd door mxdrop204.xs4all.nl die
tegen zichzelf (127.0.0.1) praat (met daarin gelukkig dus alsnog het hele
bericht). Dit is de foutmelding:
Content-Type: message/delivery-status

Reporting-MTA: dns; mxdrop204.xs4all.nl
Arrival-Date: Wed, 13 Aug 2014 16:06:09 +0200 (CEST)

Final-Recipient: RFC822; arnold@<<eigen domein>>
Action: failed
Status: 5.7.1
Remote-MTA: DNS; [127.0.0.1]
Diagnostic-Code: SMTP; 550 5.7.1 DMARC failure for domain
facebookmail.com, policy reject
Last-Attempt-Date: Wed, 13 Aug 2014 16:06:10 +0200 (CEST)

Die foutmelding gaat naar m'n hoofdaccount en wordt dan uiteraard weer
via dat procmailscript doorgestuurd (mxdrop204 is daar lekker mee bezig
gegeven de 4(!) received headers van de mxdrop...):

Delivery-date: Wed, 13 Aug 2014 16:06:11 +0200
Received: from mxdrop204.xs4all.nl ([194.109.24.202])
by mail.<<eigen domein>> with esmtp
id ....
for <arnold@<<eigen domein>> >; Wed, 13 Aug 2014 16:06:11 +0200
Received: from mxdrop204.xs4all.nl (localhost [127.0.0.1])
by mxdrop204.xs4all.nl (8.13.8/8.13.8) with ESMTP id
s7DE6Asd069284
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
for <arnold@<<eigen domein>> >; Wed, 13 Aug 2014 16:06:10 +0200
(CEST)
(envelope-from arn...@mxdrop204.xs4all.nl)
Received: (from arnold@localhost)
by mxdrop204.xs4all.nl (8.13.8/8.13.8/Submit) id s7DE6A1x069283
for arnold@<<eigen domein>>; Wed, 13 Aug 2014 16:06:10 +0200
(CEST)
(envelope-from arnold)
Received: from mxdrop204.xs4all.nl (localhost [127.0.0.1])
by mxdrop204.xs4all.nl (8.13.8/8.13.8) with ESMTP id
s7DE69YI069266
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
for <arn...@mxdrop204.xs4all.nl>; Wed, 13 Aug 2014 16:06:10 +0200
(CEST)
Received: from localhost (localhost)
by mxdrop204.xs4all.nl (8.13.8/8.13.8/Submit) id s7DE69gq069265;
Wed, 13 Aug 2014 16:06:10 +0200 (CEST)
(envelope-from MAILER-DAEMON)
Date: Wed, 13 Aug 2014 16:06:10 +0200 (CEST)
From: Mail Delivery Subsystem <MAILER...@xs4all.nl>
Message-Id: <201408131406....@mxdrop204.xs4all.nl>
To: arn...@xs4all.nl
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="s7DE69gq069265.1407938770/mxdrop204.xs4all.nl"
Subject: Returned mail: see transcript for details
Auto-Submitted: auto-generated (failure)
...
Old-Envelope-To: arn...@mxdrop204.xs4all.nl
Old-Envelope-From: MAILER-DAEMON


Als XS4ALL geen DMARC falende mails wil uitsturen, waarom die check dan
niet alléén op de smtp.xs4all.nl servers (en niet op de mxdrop's)? Van
die mxdrop's die wat willen versturen weet je immers dat het om forwards
gaat van je eigen klanten. Doe je dat toch op de mxdrop's, kijk dan even
naar die zelf toegevoegde "Authentication-Results" header. Waarom wordt
die anders toegevoegd?

NB forwarding gebruik ik al sinds 1994, eerst als gewone forward naar m'n
uucp-domein, daarna (sinds 2005) via procmail voor die extra headers, met
een laatste aanpassing in het script in 2010 (van uucp naar eigen domein).

Groeten,
Arnold

[Philip Homburg]

In article <lsg6rp$hor$2...@mallos.xs4all.nl>, Arnold <arn...@hacktic.nl> wrote:
>Die aliassen op m'n hoofdaccount krijgen via procmail extra
>headers met de originele envelope-to/from en worden dan geforward.

Misschien een oplossing om als je een mail doorstuurt, de originele From te
verplaatsen naar iets als X-Original-From.


--
We just programmed the computers to revive us when it was all over... they
were index linked to the [...] stock market prices you see, so that we'd
be revived when everybody else had rebuilt the economy enough to be able to
afford our rather expensive services again. -- Slartibartfast in THHGTTG

[Jan Ehrhardt]

Philip Homburg in xs4all.general (Thu, 14 Aug 2014 12:11:38 +0200):

>In article <lsg6rp$hor$2...@mallos.xs4all.nl>, Arnold <arn...@hacktic.nl> wrote:
>>Die aliassen op m'n hoofdaccount krijgen via procmail extra
>>headers met de originele envelope-to/from en worden dan geforward.
>
>Misschien een oplossing om als je een mail doorstuurt, de originele From te
>verplaatsen naar iets als X-Original-From.

Dat heb ik zelf moeten toepassen toen Yahoo ineens een Dmarc reject
beleid kreeg. Ik verving de From door de To. Maar Dmarc is inderdaad
frustrerend.

Zo maar een klacht over Yahoo:
http://www.ietf.org/mail-archive/web/ietf/current/msg87153.html

Jan

[Philip Homburg]

In article <1o3pu9po7264qqpl6...@4ax.com>,

Jan Ehrhardt <mon...@idem.invalid> wrote:
>Philip Homburg in xs4all.general (Thu, 14 Aug 2014 12:11:38 +0200):
>>In article <lsg6rp$hor$2...@mallos.xs4all.nl>, Arnold <arn...@hacktic.nl> wrote:
>>>Die aliassen op m'n hoofdaccount krijgen via procmail extra
>>>headers met de originele envelope-to/from en worden dan geforward.
>>
>>Misschien een oplossing om als je een mail doorstuurt, de originele From te
>>verplaatsen naar iets als X-Original-From.
>
>Dat heb ik zelf moeten toepassen toen Yahoo ineens een Dmarc reject
>beleid kreeg. Ik verving de From door de To. Maar Dmarc is inderdaad
>frustrerend.

Ja helaas. De groep die denkt dat het een goed idee is om daaraan mee te
doen is helaas te groot om te negeren.

[Arnold]

On Thu, 14 Aug 2014 13:03:09 +0200, Philip Homburg wrote:
> In article <1o3pu9po7264qqpl6...@4ax.com>,
> Jan Ehrhardt <mon...@idem.invalid> wrote:
>>Philip Homburg in xs4all.general (Thu, 14 Aug 2014 12:11:38 +0200):
>>>In article <lsg6rp$hor$2...@mallos.xs4all.nl>, Arnold <arn...@hacktic.nl>
>>>wrote:
>>>>Die aliassen op m'n hoofdaccount krijgen via procmail extra headers
>>>>met de originele envelope-to/from en worden dan geforward.
>>>
>>>Misschien een oplossing om als je een mail doorstuurt, de originele
>>>From te verplaatsen naar iets als X-Original-From.

Tja, de (m'n) halve wereld gebruikt nog m'n @xs4all-adres (in gebruik
sinds 1994). Dat betekent grote hinder bij het replyen. Dan zou ik het al
voor specifieke afzenders moeten gaan doen. Aan het bericht RFC-compliant
"Resent-" headers toevoegen zal bij dmarc ook wel niet werken neem ik
aan...

Heeft iemand toevallig een geschikt procmail script? Wat ik zo snel zelf
even zie zou ik moeten gaan knoeien met iets als
| formail -i "From: <<origineel>>.invalid"

>>Dat heb ik zelf moeten toepassen toen Yahoo ineens een Dmarc reject
>>beleid kreeg.

En dan nog alleen omdat XS4ALL ervoor *kiest* die reject-policy te
respecteren. Wat dat betreft is het net zoiets als DNS blacklists.

>>Ik verving de From door de To. Maar Dmarc is inderdaad
>>frustrerend.
>
> Ja helaas. De groep die denkt dat het een goed idee is om daaraan mee te
> doen is helaas te groot om te negeren.

En XS4ALL is blijkbaar koploper in die groep...

Waar XS4ALL in andere situaties roept dat je geen onzinnige maatregelen
(als blokkeren) moet nemen, blijken ze volgens wikipedia actief aan dmarc
te hebben bijgedragen.
https://en.wikipedia.org/wiki/DMARC#Contributors

Ik moet zeggen dat dit me teleurstelt!

Dat verklaart wel hun felheid om het zonder keuze van de gebruiker (wat
je zelfs bij Virussen wél hebt) en strikter dan noodzakelijk (ook
controle bij uitsturen ipv alléén bij ontvangst) door te voeren, terwijl
er geen RFC / internet standaard van is.


Wat wel werkt zijn digitale handtekeningen, maar doordat je daarmee ook
kunt encrypten zal de overheid dat nooit stimuleren :-/

Je zou verwachten dat XS4ALL op de een of andere manier zou meewerken aan
het uitbreiden van het gebruik van encryptietechnieken (PGP/MIME, SMIME).
Bijv. door het signen van keys of certificaten van eigen abonees (naam
contractant op (alias van) het hoofdaccount of zo). Maar nee hoor...

Arnold

[Rob]

Eveline <eve...@geenspam.xs4all.nl> wrote:
> Ik raad je aan om je nu niet meer teveel te verdiepen in procmail. Zodra we
> over zijn van SMTP op LMTP op onze mailservers, zal procmail niet meer
> werken.

Dat zal Jan niet leuk vinden!

[Arnold]

On Fri, 15 Aug 2014 18:17:32 +0000, Eveline wrote:

> Arnold schreef:

>> Heeft iemand toevallig een geschikt procmail script? Wat ik zo snel
>> zelf even zie zou ik moeten gaan knoeien met iets als
>> | formail -i "From: <<origineel>>.invalid"
>

> Ik raad je aan om je nu niet meer teveel te verdiepen in procmail. Zodra
> we over zijn van SMTP op LMTP op onze mailservers, zal procmail niet
> meer werken.

OK, bedankt voor de waarschuwing.

> Je kunt dan sieve-recepten schrijven

Dan, of werkt 't nu ook al? Wat zet je dan in je homedir, een .sieverc of
zo?

> in plaats van procmail-recepten.

Iemand dan toevallig een geschikt sieve-recept? ;-)

Hoewel ik het normaal wel leuk vind me in nieuwe dingen te verdiepen heb
ik er op t moment weinig tijd voor en ... tja... in dit geval is de
motivatie er ook net niet helemaal.

Ik heb er op m'n eigen systeem ook al eens kort naar gekeken toen ik een
nieuwe SMTP-server inrichtte. "apt-get install procmail" was toen toch de
snelste oplossing ;-)


> En dan kan het op al je mailboxen, in plaats van
> enkel op een mailbox die ook meteen een unix-account is.

Handig, al heb ik dat zelf nu niet meer nodig.

> Er bestaan wel tooltjes om procmail-recepten te converteren naar
> sieve-recepten, maar die zijn niet onfeilbaar.

Wat ik op m'n hoofdaccount had was niet zo ingewikkeld. Als ik sieve
eenmaal ken, zal dat geen probleem opleveren (mits het dezelfde
mogelijkheden heeft).

Iemand al eens wat met sieve gedaan en die hier iets kan posten om op weg
te helpen?

Arnold

[Rob van der Putten]

Hoi

Eveline wrote:

> Ik raad je aan om je nu niet meer teveel te verdiepen in procmail. Zodra we
> over zijn van SMTP op LMTP op onze mailservers, zal procmail niet meer
> werken.

Ik neem aan dat een .forward dan nog wel werkt?

> Je kunt dan sieve-recepten schrijven, in plaats van
> procmail-recepten. En dan kan het op al je mailboxen, in plaats van enkel

> op een mailbox die ook meteen een unix-account is.
>

> Er bestaan wel tooltjes om procmail-recepten te converteren naar
> sieve-recepten, maar die zijn niet onfeilbaar.

Vr.Gr,
Rob
--
Trans-Pacific Partnership is evil;
http://www.dewereldmorgen.be/artikels/2013/12/10/hoe-monsanto-profiteert-van-het-trans-pacific-partnership

[Miquel van Smoorenburg]

In article <lsli0c$hpr$1...@mallos.xs4all.nl>, Arnold <arn...@hacktic.nl> wrote:
>En dan nog alleen omdat XS4ALL ervoor *kiest* die reject-policy te
>respecteren. Wat dat betreft is het net zoiets als DNS blacklists.

Nah. De halve wereld gebruikt DMARC gewoon verkeerd. DMARC gebruiken
op domains waarop je email adressen uitdeelt aan de halve
wereld is gewoon van een IQ nivo onder de 70. Ja, ook van Yahoo,
bijvoorbeeld, die zijn ook door iedereen afgebrand (maar dat
helpt niet blijkbaar).

De reden dat XS4ALL DMARC doet is o.a. door een samenwerking met
ING, waardoor je weet dat mail die vanaf ing.nl komt ook daadwerkelijk
van ing.nl afkomt.

Verder moet ik daar maar niet teveel over zeggen, omdat ik geen
mail guru ben. Misschien kan Jan Pieter er nog wat over zeggen
(wel mail guru).

Mike.

[Miquel van Smoorenburg]

In article <slrnlusk61...@xs8.xs4all.nl>,

Daar horen we niets meer van, vanaf dat moment, want ik vermoed dat Jan
een AI is geschreven in procmail.

Mike.

[Jan-Pieter Cornet]

In article <lsg6rp$hor$2...@mallos.xs4all.nl>, Arnold <arn...@hacktic.nl> wrote:

>Hoewel ik zoveel mogelijk e-mail op m'n eigen domein (en eigen server)
>gebruik, heb ik, om m'n privacy wat te beschermen, voor accounts als
>facebook nog wel een @xs4all.nl alias. (Verschillende @<<eigen domain>>
>adressen zijn immers eenvoudiger aan elkaar te koppelen dan aliassen
>@xs4all.nl.) Die aliassen op m'n hoofdaccount krijgen via procmail extra
>headers met de originele envelope-to/from en worden dan geforward.
>
>XS4ALL werkt dit stukje privacybescherming nu helaas actief tegen. Dmarc,
>waar ik al meer last van had, is hier wederom de oorzaak :-(

*Your doing it wrongk*

[KNIP fb fabels]
[KNIP vroegah-was-alles-beitah dmarc bashing]

>Hoewel mxdrop204 *zelf* de volgende headerline toevoegt:
> Authentication-Results: xs4all.nl; spf=pass
> smtp.mailfrom=pages.facebookmail.com; dmarc=pass
> header.from=pages.facebookmail.com
>weigert die toch het bericht door te sturen!!! :-(

... omdat je procmail het bericht zodanig aanpast dat het niet meer door de
controle komt.

Als de DKIM signature intact blijft, kun je het bericht gewoon
forwarden, geen probleem. Daarvoor moet je de body niet aanpassen, en de
DKIM-signed headers niet aanpassen. De body laat je intact, maar je past
de headers wel aan.

Als je de DKIM-Signature header opzoekt in de facebookmail mails, dan
zie je daarin:
h=Date:To:From:Subject:MIME-Version:Content-Type;

... dat zijn de headers waar je vanaf moet blijven. Maar je past de To: header
aan, en dus klopt de DKIM signature niet meer, en dus wordt je mail geblokkeerd.

Met een "normale" .forward heb je dat niet, die laat alle headers intact
(voegt alleen Received headers toe), en daardoor kan de mail gewoon
doorgestuurd worden.

Je hebt dus twee opties:
1) niet de To: header aanpassen, of
2) OOK de from header aanpassen, zodanig dat daar geen DMARC-beschermd
domain in staat. ".invalid" achter het e-mail adres zetten is een optie,
of gewoon de hele From header vervangen door je eigen adres.

>NB forwarding gebruik ik al sinds 1994, eerst als gewone forward naar m'n
>uucp-domein, daarna (sinds 2005) via procmail voor die extra headers, met
>een laatste aanpassing in het script in 2010 (van uucp naar eigen domein).

"resultaten behaald in het verleden zijn geen garantie...". Je mag er
niet van uit gaan dat als iets ooit werkte, dat het altijd blijft
werken. Wat je in feite doet is op een vrij subtiele manier mail faken
van facebook. En dat mag niet, van facebook...
--
Jan-Pieter Cornet
Any sufficiently advanced incompetence is indistinguishable from malice
- Grey's Law

[Jan-Pieter Cornet]

In article <5oiphfo72cmqtm73pvtrsm35e1@inews_id.stereo.hq.phicoh.net>,

Philip Homburg <phi...@ue.aioy.eu> wrote:
>In article <1o3pu9po7264qqpl6...@4ax.com>,
>Jan Ehrhardt <mon...@idem.invalid> wrote:

[...]

>>Dat heb ik zelf moeten toepassen toen Yahoo ineens een Dmarc reject
>>beleid kreeg. Ik verving de From door de To. Maar Dmarc is inderdaad
>>frustrerend.
>
>Ja helaas. De groep die denkt dat het een goed idee is om daaraan mee te
>doen is helaas te groot om te negeren.

Het probleem is meer dat degenen die het gebrek aan security en het
ontbreken van authenticatie in het SMTP protocol waarderen, zoveel mail
sturen dat dat kwa volume te groot is om te negeren.

[Jan-Pieter Cornet]

In article <lsli0c$hpr$1...@mallos.xs4all.nl>, Arnold <arn...@hacktic.nl> wrote:

>Wat wel werkt zijn digitale handtekeningen, maar doordat je daarmee ook
>kunt encrypten zal de overheid dat nooit stimuleren :-/

Zet je alu hoedje even af, en bekijk dit es:

http://ecp.nl/events//4155/seminar-nieuwe-internetstandaarden.html

(PS: DNSSEC en DKIM maken gebruik van digitale handtekeningen)

[Jan-Pieter Cornet]

In article <53ee5a26$0$2842$e4fe...@news.xs4all.nl>,

Rob van der Putten <r...@sput.nl> wrote:
>Ik neem aan dat een .forward dan nog wel werkt?

Dat blijft wel werken, maar mogelijk niet met een file in je homedir.

[Jan Ehrhardt]

Miquel van Smoorenburg in xs4all.general (15 Aug 2014 21:08:50 GMT):

Turing testje doen?

Jan

[Rob]

Miquel van Smoorenburg <mik...@xs4all.nederland.invalid> wrote:
> De reden dat XS4ALL DMARC doet is o.a. door een samenwerking met
> ING, waardoor je weet dat mail die vanaf ing.nl komt ook daadwerkelijk
> van ing.nl afkomt.

Ja dat is inderdaad een groot voordeel.

Het is wel de vraag wat ING daar aan heeft, want ze sturen zelf nooit
mail (dat lees je altijd), en DMARC voorkomt niet dat er iemand anders een
mail stuurt die doet alsof die van ING af komt maar daarbij niet van
ing.nl komt. Daar is weer een volgende ontwikkeling voor nodig, waarbij
je een soort check kunt doen op de inhoud van mail, onafhankelijk van
de afzender. Zodat ING kan regelen dat er geen mail gestuurd kan
worden die over hen gaat, en die ze niet zelf gestuurd hebben.

Als dat mogelijk wordt dan gaat er vast een hoop weerstand tegen ontstaan.

[Rob van der Putten]

Hoi

Jan-Pieter Cornet wrote:

> Dat blijft wel werken, maar mogelijk niet met een file in je homedir.

Hoe dan? Iets in het service center?

[Rob van der Putten]

Hoi


Eveline wrote:

> Het doorsturen van e-mail zal gaan werken via sieve-regels. Die staan dan
> dus op de mailserver zelf, en zijn aan te passen via een sieve-capabele
> mailclient. Zoals Thunderbird of XS4ALL Roundcube.
>
> En dat is heel fijn, want niet elke mailbox heeft een homedir. Op deze
> manier zal doorsturen en filteren werken op elke mailbox, in plaats van
> enkel op je unix-account.

Ik heb alleen maar een unix account en gebruik het email adres alleen
maar voor mail van XS4ALL zelf.
Ik wil eigenlijk een oplossing waarbij alleen mail van XS4ALL word
doorgestuurd en de rest word geweigerd. Er zijn meer mensen die dit willen.
Misschien kan iemand hier een kant en klaar sieve filter voor publiceren.

[Rob van der Putten]

Hoi

Rob van der Putten wrote:

> Ik heb alleen maar een unix account en gebruik het email adres alleen
> maar voor mail van XS4ALL zelf.
> Ik wil eigenlijk een oplossing waarbij alleen mail van XS4ALL word
> doorgestuurd en de rest word geweigerd. Er zijn meer mensen die dit willen.
> Misschien kan iemand hier een kant en klaar sieve filter voor publiceren.

Begrijp ik het goed dat Thunderbird daar een plugin voor nodig heeft? Is
daar een Debian package voor?
Zijn er nog andere manieren om sieve filters te manipuleren (dus los van
een mailclient)? Zijn daar Debian packages voor?

[Rob van der Putten]

Hoi


Eveline wrote:

> Als je even zoekt via apt-cache, dan vind je van alles. Waaronder deze:
>
> ----
> [eveline@evelinux ~]$ apt-cache show sieve-connect
> Package: sieve-connect
> Version: 0.83-1
> Installed-Size: 106
> Maintainer: Andrew Pollock<apol...@debian.org>
> Architecture: all
> Depends: perl, libauthen-sasl-perl (>= 2.11-1), libio-socket-inet6-perl, libnet-dns-perl, libio-socket-ssl-perl, libmime-base64-perl, perl-modules, libterm-readkey-perl
> Recommends: libterm-readline-gnu-perl
> Description-en: MANAGESIEVE protocol client
> This is sieve-connect. A client for the MANAGESIEVE protocol, as
> implemented by timsieved in Cyrus IMAP.
> .
> sieve-connect is designed to be both a tool which can be invoked from
> scripts and also a decent interactive client. It should also be a
> drop-in replacement for "sieveshell", as supplied with Cyrus IMAP.
> ----

Dit is ook handig;
http://en.wikipedia.org/wiki/Sieve_(mail_filtering_language)

[Luuk]

On 16-8-2014 19:59, Rob van der Putten wrote:

>
> Eveline wrote:
>> [eveline@evelinux ~]$ apt-cache show sieve-connect
>> Package: sieve-connect
>> Version: 0.83-1
>

> Dit is ook handig;
> http://en.wikipedia.org/wiki/Sieve_(mail_filtering_language)
>
>

http://sieve.info/

[Rob van der Putten]

Hoi


Luuk wrote:

> http://sieve.info/

Is gelinkt van Wikipedia pagina.

Word zo'n sieve filter straks geprocessed at 'SMTP' time? Zodat als je
mail weigert je een reject krijgt en geen bounce?

[Arnold]

On Fri, 15 Aug 2014 22:48:54 +0000, Jan-Pieter Cornet wrote:

> In article <lsli0c$hpr$1...@mallos.xs4all.nl>, Arnold <arn...@hacktic.nl>
> wrote:
>>Wat wel werkt zijn digitale handtekeningen, maar doordat je daarmee ook
>>kunt encrypten zal de overheid dat nooit stimuleren :-/
>
> Zet je alu hoedje even af, en bekijk dit es:
> http://ecp.nl/events//4155/seminar-nieuwe-internetstandaarden.html

Alu hoedje kan op blijven, want wat je aanhaalt gaat om DNSSEC en DKIM,
beide technieken waarmee je niet kunt encrypten. Blijft mijn stelling dus
overeind dat de overheid geen technieken onder 'de gewone man' stimuleert
waarmee deze encrypted berichten kan versturen.

> (PS: DNSSEC en DKIM maken gebruik van digitale handtekeningen)

Met beide heb je géén end-to-end digitale handtekening over de inhoud van
een (e-mail)bericht, het is MTA-to-MTA. Het biedt dus géén zekerheid dat
de inhoud afkomstig is van een bepaalde afzender zoals bij S/MIME of PGP/
MIME).

Arnold

[Jan-Pieter Cornet]

In article <53ef40f8$0$2836$e4fe...@news2.news.xs4all.nl>,
Eveline <eve...@geenspam.xs4all.nl> wrote:
>Rob van der Putten schreef:
>[over .forward]

>> Jan-Pieter Cornet wrote:
>>> Dat blijft wel werken, maar mogelijk niet met een file in je homedir.
>>
>> Hoe dan? Iets in het service center?
>

>Het doorsturen van e-mail zal gaan werken via sieve-regels. Die staan dan
>dus op de mailserver zelf, en zijn aan te passen via een sieve-capabele
>mailclient. Zoals Thunderbird of XS4ALL Roundcube.

... waarschijnlijk. Maar er komt ook een simpele interface in het
service center, zodat je niet zelf sieve rules hoeft te schrijven
uiteraard. Maar misschien dat we simpele forwards wel op een nog lager
nivo oplossen, in de smtp server config ergens.

[Arnold]

On Fri, 15 Aug 2014 22:19:59 +0000, Jan-Pieter Cornet wrote:
> In article <lsg6rp$hor$2...@mallos.xs4all.nl>, Arnold <arn...@hacktic.nl>
> wrote:
>>Hoewel ik zoveel mogelijk e-mail op m'n eigen domein (en eigen server)
>>gebruik, heb ik, om m'n privacy wat te beschermen, voor accounts als
>>facebook nog wel een @xs4all.nl alias. (Verschillende @<<eigen domain>>
>>adressen zijn immers eenvoudiger aan elkaar te koppelen dan aliassen
>>@xs4all.nl.) Die aliassen op m'n hoofdaccount krijgen via procmail extra
>>headers met de originele envelope-to/from en worden dan geforward.
>>
>>XS4ALL werkt dit stukje privacybescherming nu helaas actief tegen.
>>Dmarc, waar ik al meer last van had, is hier wederom de oorzaak :-(
>
> *Your doing it wrongk*

Sorry Jan-Pieter, maar hier sla je de plank een klein beetje volkomen mis.

(Al zie ik dat PAN een zooitje heeft gemaakt van de line ends van de
headers die ik in het oorspronkelijk bericht had gekopieerd.)

> [KNIP vroegah-was-alles-beitah dmarc bashing]

Zeg mij maar: welk probleem lost blokkeren op dmarc op of welk voordeel
biedt het mij of desnoods anderen? In ieder geval werkt het niet tegen
phishing met From: "ING BANK N.V" <in...@ingsecure-nl.be>

Volgens mij zou het beter zijn in het spamfilter iets op te nemen als:
FROM looks like NL-bank AND not (dkim pass)

>>Hoewel mxdrop204 *zelf* de volgende headerline toevoegt:
>> Authentication-Results: xs4all.nl; spf=pass
>> smtp.mailfrom=pages.facebookmail.com; dmarc=pass
>> header.from=pages.facebookmail.com
>>weigert die toch het bericht door te sturen!!! :-(
>
> ... omdat je procmail het bericht zodanig aanpast dat het niet meer door
> de controle komt.

Je hebt niet goed gelezen en teveel weggeknipt uit m'n bericht, mijn
procmail doet niets waardoor het niet meer door een DKIM-controle zou
komen. Hint 'spf'=pass (geen DKIM).

Dat die hele dkim hier ontbrak had ik bij het posten zelf trouwens ook
over het hoofd gezien.

Blijft het feit dat een XS4ALL-server eerst constateert dat een e-mail
oorspronkelijk afkomstig is van een bepaald domein (en dus op zich valide
is), maar dat vervolgens toch weigert door te sturen naar een ander adres.

XS4ALL ontneemt mij de mogelijkheid e-mail op een centrale mailbox te
ontvangen (al komt het daar via de geforwarde bounce wel aan).

> Als de DKIM signature intact blijft, kun je het bericht gewoon
> forwarden, geen probleem. Daarvoor moet je de body niet aanpassen, en de
> DKIM-signed headers niet aanpassen. De body laat je intact, maar je past
> de headers wel aan.

Fout, ik pas geen enkele bestaande headerline aan.

Het enige dat ik doe is 'ORG-ENVELOPE-TO/FROM' toevoegen. Je hebt bij
deze m'n toestemming m'n procmail scripts te lezen.

> Als je de DKIM-Signature header opzoekt in de facebookmail mails, dan

Dit heb je weggeknipt uit mijn bericht, maar die had facebook er ook niet
ingezet. Het door XS4ALL algemeen ingestelde gebruik van dmarc maakt dan
mijn (en iedere) forward stuk. Effectief heb je dan namelijk alleen nog
spf waarop je reject. Dat rejecten doe je als XS4ALL nota bene bij het
versturen!

> zie je daarin:
> h=Date:To:From:Subject:MIME-Version:Content-Type;

Ik nodig je uit die uit mijn orspronkelijke berichtje te kopiëren ;-)
(Ik had alleen enkele identificerende data en UUID's door '...'
vervangen, 't was verder compleet.)

> ... dat zijn de headers waar je vanaf moet blijven. Maar je past de To:
> header aan,

Dat doe ik niet (al zijn in mijn oorspronkelijke post wel wat lijnen
achter elkaar gekomen, zie ik: de To is achter de Date-regel gekomen).

> en dus klopt de DKIM signature niet meer,

Was er niet.

> en dus wordt je mail geblokkeerd.

En daar wordt ik dan dus ongelukkig van.

> Met een "normale" .forward heb je dat niet,

In dit geval dus toch.

> die laat alle headers intact
> (voegt alleen Received headers toe), en daardoor kan de mail gewoon
> doorgestuurd worden.

Mijn toegevoegde 'org-envelope' heeft geen ander effect.

> Je hebt dus twee opties:
> 1) niet de To: header aanpassen, of

Doe ik ook niet.

> 2) OOK de from header aanpassen,
> zodanig dat daar geen DMARC-beschermd domain in staat.

En hoe weet ik dat in een procmail of een sieve filter? Bovendien als
XS4ALL die controle niet doet bij het versturen is er niets aan de hand
(volgens mij is DKIM, SPF en DMARC allemaal bedoelt als controle voor
*ontvangers*). Als ontvanger weet ik er wel raad mee...

> ".invalid" achter
> het e-mail adres zetten is een optie,
> of gewoon de hele From header vervangen door je eigen adres.

Ja, dat replyt allemaal zo lekker gemakkelijk... niet dus :-(

> "resultaten behaald in het verleden zijn geen garantie...". Je mag er
> niet van uit gaan dat als iets ooit werkte, dat het altijd blijft
> werken.

Graag behoud ik mogelijkheden, anders is er sprake van achteruitgang.

In dit geval: e-mail gericht aan hoofdaccount en aliasses daarvan
doorsturen naar een centraal punt waar ik normaal gebruik wil kunnen
maken van eigen filters op 'from' en van 'reply' zonder e-mailadressen
aan te moeten passen (zoals bij het aanpassen van de 'From:', zoals je
voorstelt).
Zeg maar hoe ik dat werkend krijg. Dat mag op een andere manier dan ik nu
doe.

> Wat je in feite doet is op een vrij subtiele manier mail faken
> van facebook. En dat mag niet, van facebook...

Fout, dat mag niet van XS4ALL.

XS4ALL luistert blijkbaar liever naar de wens van facebook dan naar die
van een eigen klant. Wat heb ik als ontvanger van een willekeurige aan
mij gerichte e-mail te maken met de wens van facebook???

Nu kijkt XS4ALL in SMTP-data, gaat organisaties vragen wat *zij* ervan
vinden dat *ik* een dergelijk bericht zou gaan ontvangen (op het moment
dat het al bij XS4ALL is aangekomen) en blokkeert het alsnog als dat
*hun* wens is. XS4ALL gaat eraan voorbij wat *mijn* wens is. Daar heb ik
nooit om gevraagd en, belangrijker, kan ik ook niet anders instellen.

Voor mij zijn DKIM en SPF bij een 'pass' indicatoren die bijdragen aan
het vertrouwen in een bericht. Het zijn voor mij geen block-criteria. Als
XS4ALL alleen headers met pass/fail toevoegt ben ik gelukkig.

Als je in m'n settings kijkt zie je dat ik op m'n hoofdaccount ook spam
en zelfs virussen wil ontvangen. Ik wil gewoon alles ontvangen wat aan
mij wordt gericht (om *zelf* te bepalen hoe ik het beoordeel en wat ik
ermee doe). Dat ontvangen wil ik dus op een centraal adres.

Arnold

[Luuk]

On 16-8-2014 22:01, Rob van der Putten wrote:
> Hoi
>
>
> Luuk wrote:
>
>> http://sieve.info/
>
> Is gelinkt van Wikipedia pagina.
>
> Word zo'n sieve filter straks geprocessed at 'SMTP' time? Zodat als je
> mail weigert je een reject krijgt en geen bounce?
>

van die wikipedia pagina:
"RFC 5429 – Reject; allows messages to be rejected at either the
LMTP/SMTP level or with an MDN or DSN."

en
"The scripts are transferred to the mail server in a server-dependent way."

Die regels worden dus (volgens deze quotes, en wat vrije interpretatie
;) ) op de server uitgevoerd.
Alleen daarom is het logisch dat een reject ook ondersteund word, wat
voor zin heeft het anders om dit op de server uit te laten voeren.

[Philip Homburg]

In article <lsoebf$5p6$1...@mallos.xs4all.nl>, Arnold <arn...@hacktic.nl> wrote:
>Alu hoedje kan op blijven, want wat je aanhaalt gaat om DNSSEC en DKIM,
>beide technieken waarmee je niet kunt encrypten.

Meer DNSSEC kan je prima encrypten. Nou ja, met DNSSEC zelf niet, Maar je kan DNSSEC
gebruiken als een gedistribueerde PKI.

Dus wat je bijvoorbeeld zou kunnen doen is om als je een mail stuur naar us...@xs4all.nl
je een lookup doet op user.at.xs4all.nl waar dan een (RSA, of el-gamal) public key
staat die voor encryptie gebruikt kan worden. Op dezelfde manier kan je de public key
van je signature zetten in afzender.at.domein.

Probleem is alleen dat iedere security systeem 600 opties moet hebben waar je
in de praktijk niets aan hebt maar die het wel mogelijk maken om het systeem te
hacken. Met liefst insecure defaults, een rampzalige user interface, en X509
certificaten.


--
We just programmed the computers to revive us when it was all over... they
were index linked to the [...] stock market prices you see, so that we'd
be revived when everybody else had rebuilt the economy enough to be able to
afford our rather expensive services again. -- Slartibartfast in THHGTTG

[Philip Homburg]

In article <53ee8b92$0$2892$e4fe...@news2.news.xs4all.nl>,

Jan-Pieter Cornet <joh...@xs4all.net> wrote:
>In article <5oiphfo72cmqtm73pvtrsm35e1@inews_id.stereo.hq.phicoh.net>,
>Philip Homburg <phi...@ue.aioy.eu> wrote:
>>In article <1o3pu9po7264qqpl6...@4ax.com>,
>>Jan Ehrhardt <mon...@idem.invalid> wrote:
>[...]
>>>Dat heb ik zelf moeten toepassen toen Yahoo ineens een Dmarc reject
>>>beleid kreeg. Ik verving de From door de To. Maar Dmarc is inderdaad
>>>frustrerend.
>>
>>Ja helaas. De groep die denkt dat het een goed idee is om daaraan mee te
>>doen is helaas te groot om te negeren.
>
>Het probleem is meer dat degenen die het gebrek aan security en het
>ontbreken van authenticatie in het SMTP protocol waarderen, zoveel mail
>sturen dat dat kwa volume te groot is om te negeren.

Het lijkt dat het misbruik niet echt een reden is om rare dingen als dmarc te
implementeren.

[Jan-Pieter Cornet]

In article <lsojpq$5p6$2...@mallos.xs4all.nl>, Arnold <arn...@hacktic.nl> wrote:
>On Fri, 15 Aug 2014 22:19:59 +0000, Jan-Pieter Cornet wrote:
>> In article <lsg6rp$hor$2...@mallos.xs4all.nl>, Arnold <arn...@hacktic.nl>
>> wrote:

[...]

>>>Dmarc, waar ik al meer last van had, is hier wederom de oorzaak :-(
>>
>> *Your doing it wrongk*
>
>Sorry Jan-Pieter, maar hier sla je de plank een klein beetje volkomen mis.

Oei. Je hebt gelijk, zie ik, over deze reject.

>>>Hoewel mxdrop204 *zelf* de volgende headerline toevoegt:
>>> Authentication-Results: xs4all.nl; spf=pass
>>> smtp.mailfrom=pages.facebookmail.com; dmarc=pass
>>> header.from=pages.facebookmail.com
>>>weigert die toch het bericht door te sturen!!! :-(
>>
>> ... omdat je procmail het bericht zodanig aanpast dat het niet meer door
>> de controle komt.
>
>Je hebt niet goed gelezen en teveel weggeknipt uit m'n bericht, mijn
>procmail doet niets waardoor het niet meer door een DKIM-controle zou
>komen. Hint 'spf'=pass (geen DKIM).

Inderdaad. Daar had ik helemaal overheen gekeken. Wat lame, ik ging er
van uit dat facebook altijd spf+dkim doet. Het aanpassen van headers is
een veelgemaakte fout bij forwarding, waardoor DMARC stuk ging, en ik
dacht dat in jouw posting ook te zien:

Ik zie eerst deze header in de "originele mail":
> To: Arnold ...... <fb.......@xs4all.nl>

... en later zie ik deze header:
> To: arn...@xs4all.nl

... maar ik besef me nu dat de eerste header afkomstig is uit de inhoud
van de bounce (headers van de "originele mail"), en de tweede de header
van de bounce zelf is, dus die hebben niets met elkaar te maken.

>Dat die hele dkim hier ontbrak had ik bij het posten zelf trouwens ook
>over het hoofd gezien.

Yep, had ik ook niet verwacht. Als dkim ontbreekt valt DMARC in feite
terug naar SPF, en dat SPF dubieus is weten we al langer. Sommige
domeinen lijken daar bewust voor te kiezen, maar dat komt niet echt op
grote schaal voor. Degene in de logs die er nu uit springt is
"facebookappmail.com", die lijkt nooit DKIM te gebruiken, wel SPF, en
een reject DMARC policy te gebruiken (maar die stuurt niet zoveel mail).

Ik zal binnenkort es een update maken dat we de policy=reject van dat
soort domeinen met een grote korrel zout nemen, en botweg negeren.

Overigens lijkt er ook iets mis bij facebook zelf. Even door de logs van
"gisteren" gespit, en ik zie dat van de mails vanaf facebookmail.com
ongeveer 1% zonder DKIM aankomt (maar met SPF pass)... eergisteren
ongeveer hetzelfde aantal... vorige week ook... en op 20 juli ook al
zoiets (0.5%), verder kan ik niet op dat nivo terugkijken.

>Blijft het feit dat een XS4ALL-server eerst constateert dat een e-mail
>oorspronkelijk afkomstig is van een bepaald domein (en dus op zich valide
>is), maar dat vervolgens toch weigert door te sturen naar een ander adres.

Hmm, mja, dat komt omdat daar gewoon geen rekening mee gehouden is. De
mxdrops zijn de inkomende mail servers. Mail die daarop aangeboden
wordt, wordt verondersteld "binnenkomende mail" te zijn, en dus op DMARC
gecontroleerd. Er zit op dit moment gewoon geen uitzondering voor mail
vanaf localhost, die geforward wordt. Die local-override voor DMARC is
inderdaad wel nuttig voor deze server. Nog een patch...

>Fout, ik pas geen enkele bestaande headerline aan.
>Het enige dat ik doe is 'ORG-ENVELOPE-TO/FROM' toevoegen. Je hebt bij
>deze m'n toestemming m'n procmail scripts te lezen.

Ik geloof je. Dit lijkt veroorzaakt door het gebrek aan DKIM in de
inkomende mail (en strenge DMARC controle bij doorsturen)

[Jan-Pieter Cornet]

In article <53efb883$0$2895$e4fe...@news.xs4all.nl>,

Rob van der Putten <r...@sput.nl> wrote:

>> http://sieve.info/

... en ook http://wiki1.dovecot.org/ManageSieve (of RFC5804)

>Word zo'n sieve filter straks geprocessed at 'SMTP' time? Zodat als je
>mail weigert je een reject krijgt en geen bounce?

Nee, je krijgt een bounce (wel meteen, niet pas als je inlogt of zo).
Dat is tenminste hoe het nu werkt in de experimentele setup. De
LMTP/Sieve aflevering is op dit moment niet in-line, dus onze mail
servers genereren een bounce als je sieve script de mail reject, ipv dat
je in de SMTP connectie een reject krijgt.

Aangezien LMTP anders is dan SMTP in het geval van multiple recipients,
is dat in elk geval niet generiek op te lossen, dus het zal technisch
lastig zijn om een reject te geven.

[Miquel van Smoorenburg]

In article <53f21abc$0$2854$e4fe...@news2.news.xs4all.nl>,

Jan-Pieter Cornet <joh...@xs4all.net> wrote:
>In article <53efb883$0$2895$e4fe...@news.xs4all.nl>,
>Rob van der Putten <r...@sput.nl> wrote:
>>> http://sieve.info/
>
>... en ook http://wiki1.dovecot.org/ManageSieve (of RFC5804)
>
>>Word zo'n sieve filter straks geprocessed at 'SMTP' time? Zodat als je
>>mail weigert je een reject krijgt en geen bounce?
>
>Nee, je krijgt een bounce (wel meteen, niet pas als je inlogt of zo).
>Dat is tenminste hoe het nu werkt in de experimentele setup. De
>LMTP/Sieve aflevering is op dit moment niet in-line, dus onze mail
>servers genereren een bounce als je sieve script de mail reject, ipv dat
>je in de SMTP connectie een reject krijgt.
>
>Aangezien LMTP anders is dan SMTP in het geval van multiple recipients,
>is dat in elk geval niet generiek op te lossen, dus het zal technisch
>lastig zijn om een reject te geven.

Da's bij elke oplossing zo, waar er meerdere ontvangers zijn binnen 1
smtp sessie, die elk een eigen policy kunnen hebben. Als ze allemaal
dezelfde 2xx/4xx/5xx code teruggeven dan kan je die terugsturen,
maar als 1 van de ontvangers een andere code teruggeeft moet je
in de smtp sessie met de verzender de mail accepteren en lokaal
de reject gaan sturen. Dat zou je natuurlijk ook zo kunnen
implementeren.

Ik zie dat er al jaaaaaren wordt gepraat over een SMTP extensie
om per-recipient-smtp-reply-codes te kunnen sturen maar dat men
het nooit eens geworden is. Als die RFC er nou gewoon geweest
was in 2007 dan was er wellicht inmiddels wat ondersteuning voor.

Mike.

[Rob van der Putten]

Hoi

Miquel van Smoorenburg wrote:

> Da's bij elke oplossing zo, waar er meerdere ontvangers zijn binnen 1
> smtp sessie, die elk een eigen policy kunnen hebben. Als ze allemaal
> dezelfde 2xx/4xx/5xx code teruggeven dan kan je die terugsturen,
> maar als 1 van de ontvangers een andere code teruggeeft moet je
> in de smtp sessie met de verzender de mail accepteren en lokaal
> de reject gaan sturen. Dat zou je natuurlijk ook zo kunnen
> implementeren.

Dat is voor zover mij bekend alleen een probleem in de data fase.
Tijdens de recipient fase kan je gewoon per rcpt een ander code teruggeven.
Als het sieve filter niet alleen tijdens de data fase maar ook tijdens
de rcpt fase word geraadpleegd, gaat dat dus gewoon werken.

> Ik zie dat er al jaaaaaren wordt gepraat over een SMTP extensie
> om per-recipient-smtp-reply-codes te kunnen sturen maar dat men
> het nooit eens geworden is. Als die RFC er nou gewoon geweest
> was in 2007 dan was er wellicht inmiddels wat ondersteuning voor.

[Rob]

Miquel van Smoorenburg <mik...@xs4all.nederland.invalid> wrote:

> Ik zie dat er al jaaaaaren wordt gepraat over een SMTP extensie
> om per-recipient-smtp-reply-codes te kunnen sturen maar dat men
> het nooit eens geworden is. Als die RFC er nou gewoon geweest
> was in 2007 dan was er wellicht inmiddels wat ondersteuning voor.

Kan nu al, maar dan moet je >1 rcpt weigeren in je SMTP server en
dan gaat de andere kant de mail sturen en daarna retryen met de volgende
rcpt. Tenzij het een totaal broken systeem is natuurlijk.

Overigens is er ook steeds meer software die geen rcpt bundeling meer
doet, dus zowizo iedere mail splitst in aparte mailtjes per rcpt.
(zonde van de bandbreedte en jammer van single-instance-storage natuurlijk,
maar dat hebben onze vrienden van MS inmiddels toch al verlaten)

[Arnold]

On Mon, 18 Aug 2014 15:21:59 +0000, Jan-Pieter Cornet wrote:
> In article <lsojpq$5p6$2...@mallos.xs4all.nl>, Arnold <arn...@hacktic.nl>
> wrote:
>>On Fri, 15 Aug 2014 22:19:59 +0000, Jan-Pieter Cornet wrote:
>>> In article <lsg6rp$hor$2...@mallos.xs4all.nl>, Arnold
>>> <arn...@hacktic.nl> wrote:
>>>>Dmarc, waar ik al meer last van had, is hier wederom de oorzaak :-(
>>> *Your doing it wrongk*
>>Sorry Jan-Pieter, maar hier sla je de plank een klein beetje volkomen
>>mis.
> Oei. Je hebt gelijk, zie ik, over deze reject.

Ja, maar wat de dmarc bashing betrof, had je natuurlijk wel een beetje
gelijk (zie ook subject).

>>mijn
>>procmail doet niets waardoor het niet meer door een DKIM-controle zou
>>komen. Hint 'spf'=pass (geen DKIM).
>
> Inderdaad. Daar had ik helemaal overheen gekeken. Wat lame, ik ging er
> van uit dat facebook altijd spf+dkim doet.

Je zou er bij dergelijke partijen vanuit moeten kunnen gaan, maar helaas
kan je dat niet.

> ... maar ik besef me nu dat de eerste header afkomstig is uit de inhoud
> van de bounce (headers van de "originele mail"), en de tweede de header
> van de bounce zelf is, dus die hebben niets met elkaar te maken.

Yup, het is voor mij ook altijd weer ff puzzelen als ik een bounce krijg
op een (van mij uit gezien) binnenkomend bericht ipv uitgaand.

Ik bekijk dan de headers van het bouncebericht om te zien of het geen
fake bouncebericht is voordat ik de headers van het gebouncede bericht
bekijk. Gelukkig gebeurt dat allemaal niet zo vaak. Als dan blijkt dat
dat extra werk komt door dmarc, nou ja, je weet inmiddels hoe ik dan
reageer ;-)

>>Dat die hele dkim hier ontbrak had ik bij het posten zelf trouwens ook
>>over het hoofd gezien.
>
> Yep, had ik ook niet verwacht.

Ja, dat dacht ik al ;-)

> Als dkim ontbreekt valt DMARC in feite
> terug naar SPF, en dat SPF dubieus is weten we al langer.

> [[...]]

> Ik zal binnenkort es een update maken dat we de policy=reject van dat
> soort domeinen met een grote korrel zout nemen, en botweg negeren.

Dat zou mooi zijn.

Volgens mij zou je alleen een dmarc-policy moeten accepteren als je een
goede relatie met de beheerder van dat domein hebt (zoals bijv. ING).
Ontvang je dan valid SPF zonder DKIM, dan kun je gelijk alarmbellen laten
rinkelen in de wetenschap dat er wat mee wordt gedaan.

In andere gevallen loop je als provider risico als je blind dmarc-
policies honoreert. Ik zou bij partijen zonder goede
samenwerkingsovereenkomst alleen spf en dkim gebruiken als input voor een
spamfilter. Maar goed, ik run geen ISP.

>>Blijft het feit dat een XS4ALL-server eerst constateert dat een e-mail
>>oorspronkelijk afkomstig is van een bepaald domein (en dus op zich
>>valide is), maar dat vervolgens toch weigert door te sturen naar een
>>ander adres.
>
> Hmm, mja, dat komt omdat daar gewoon geen rekening mee gehouden is. De
> mxdrops zijn de inkomende mail servers. Mail die daarop aangeboden
> wordt, wordt verondersteld "binnenkomende mail" te zijn, en dus op DMARC
> gecontroleerd. Er zit op dit moment gewoon geen uitzondering voor mail
> vanaf localhost, die geforward wordt. Die local-override voor DMARC is
> inderdaad wel nuttig voor deze server. Nog een patch...

Dit zou heel erg mooi zijn :-)

Zoals gezegd, ik krijg nu alles uiteindelijk dus wel, maar dan in een
bounce die wel geforward wordt en waarbij wat puzzelwerk van mij nodig is
om vast te stellen dat het om een valide bericht gaat.

Mocht je ernaar kijken, wees er dan alert op dat hetzelfde gebeurt met
virussen op het hoofdaccount (mits het virusfilter uit staat): ze komen
binnen, er wordt gepoogd ze door te sturen, mag niet, bounce, bounce (met
virus) wordt wel doorgestuurd.
Dit stoort me niet, maar ik kan me voorstellen dat gedetecteerde virussen
bij jullie anders worden behandeld dan spam of een verkeerde From. Ik
meld het maar even dat je er alert op bent. Mocht je overigens het idee
hebben dat je die nu wel tegenhoudt, dat is door die bounce dus niet zo.

Arnold

[Arnold]

On Mon, 18 Aug 2014 13:55:19 +0200, Philip Homburg wrote:

> In article <lsoebf$5p6$1...@mallos.xs4all.nl>, Arnold <arn...@hacktic.nl>
> wrote:
>>Alu hoedje kan op blijven, want wat je aanhaalt gaat om DNSSEC en DKIM,
>>beide technieken waarmee je niet kunt encrypten.
>
> Meer DNSSEC kan je prima encrypten. Nou ja, met DNSSEC zelf niet, Maar
> je kan DNSSEC gebruiken als een gedistribueerde PKI.

DNSSEC gebruik je dan als een soort hiërarchische TTP waarmee het de
infrastuctuur biedt om met andere technieken encryptie te verzorgen.

> Probleem is alleen dat iedere security systeem 600 opties moet hebben
> waar je in de praktijk niets aan hebt maar die het wel mogelijk maken om
> het systeem te hacken. Met liefst insecure defaults, een rampzalige user
> interface, en X509 certificaten.

En om dit te verbeteren zie ik de verschillende overheden dan weer niet
zo snel het voortouw nemen ;-)

Arnold

[Miquel van Smoorenburg]

In article <53f23ac2$0$2968$e4fe...@news.xs4all.nl>,

Rob van der Putten <r...@sput.nl> wrote:

>Miquel van Smoorenburg wrote:
>
>> Da's bij elke oplossing zo, waar er meerdere ontvangers zijn binnen 1
>> smtp sessie, die elk een eigen policy kunnen hebben. Als ze allemaal
>> dezelfde 2xx/4xx/5xx code teruggeven dan kan je die terugsturen,
>> maar als 1 van de ontvangers een andere code teruggeeft moet je
>> in de smtp sessie met de verzender de mail accepteren en lokaal
>> de reject gaan sturen. Dat zou je natuurlijk ook zo kunnen
>> implementeren.
>
>Dat is voor zover mij bekend alleen een probleem in de data fase.
>Tijdens de recipient fase kan je gewoon per rcpt een ander code teruggeven.
>Als het sieve filter niet alleen tijdens de data fase maar ook tijdens
>de rcpt fase word geraadpleegd, gaat dat dus gewoon werken.

Dat klopt uiteraard, maar bij SMTP komt de RCPT TO fase natuurlijk
voor de DATA fase. Dus als je in sieve op body content scant dan is er
alleen een reply mogelijk tijdens de DATA fase en dan heb je
het omschreven probleem.

Maar ja, inderdaad, als je tijdens de RCPT fase al een reject of retry
geeft dan kan dat transparant worden doorgegeven.

Mike.