SPF reject von Outlook und Hotmail

[Andreas Tauscher]

On 04.07.2016 16:14, Daniel wrote:
> Ich finde besonders bei Online Rechnungen (Telekom, 1&1, ...) oder
> Nachrichten von Bank und Bezahldiensten sollte SPF wirklich hart 
> sein, und ggf. über Subdomain wo nur hart SPF ist, und hauptdomain
> kann ja dann halt softfail oder wie auch immer sein.

SPF ist Broken by Design (TM). Unreparierbar kaputt. Setze einen ~all
oder ?all Record. Schadet nicht. Ansonsten: Ignoriere SPF und
verschwende keine Zeit damit. Es ist kaputt. Schau mal wie Spamassassin
das bewertet. Warum wohl?

Dafür gibt es DMARC. Wenn der Absender das nicht verstanden hat: Deren
Problem. Wenn dein Mailhoster damit nicht umgehen kann: Such dir einen
der das kann.

> So sollte es kein Problem sein wenn halt nen Dienstleister Newsletter
> oder so rausjagt und ggf. abgewertet wird, aber eben dennoch 
> zugestellt.

Ob einfache Email oder tausende Kopien davon: Richtig gemacht kommt das
an. Immer.
Wenn ich aber mit SPF und DKIM um mich werfe und keine Ahnung habe wie
das funktioniert und was ich da tue: Selber schuld.
Und wenn ich die bounces nicht bekomme und nicht mitbekomme das mein
supder duper lebenswichtiger Newsletter in der Tonne landet weil ich so
einen noreply@ Blödsinn gesetzt habe: Selber schuld.
Und wenn Du wegen nicht behandelter bounces auf eine Blackliste landest
weil Du penetrant Mails an nicht existierende Adressen einkippen willst:
Ganz richtig so!

Wenn ich mir permanent darüber Gedanken machen würde wie ich drumrum
bastle nur weil ein Ignorant minimalst Standards nicht beachtet hätte
ich den ganzen Tag nichts anderes zu tun.
Altbekannte Ignoranten wie EA kommen halt zähneknirschend auf eine
Whitelist. Wenn aber der Honkongramscher dx.com sein Mailsystem
repariert bekommen hat, dann besteht ja für EA noch eine Hauch von Hoffnung.

> Wenn Kunde meint Emails von Anbieter A zu Anbieter B weiterzuleiten,
> wäre es einigen Anbieter sogar bestimmt recht wenn es dann 
> fehlschlägt da man von ausgehen könnte dass das Postfach nicht mehr
> benutzt wird oder zu wem anders gehen könnte.

Wenn ich meiner Kundschaft jetzt erkläre das Weiterleitungen nicht mehr
funktionieren, dann habe ich bald jede Menge freier Ressourcen. Soviel
das sich ein Raspberry langweilen wird.
Für einen Freemailer: Je mehr Adressen mit deiner Domain im Umlauf sind
desto besser.
Für einen Hoster: Solange ich für die Mailbox bezahlt werde ist es mir
doch egal was der Kunde mit seinen Mails macht. Wenn der die gleich
weiterleitet ganz gut. Spart Storage und Backupkapazität. Bandbreite ist
billiger.

> Bei normalen Briefen von Banken oder so stehe ja teils auch drauf
> nicht Nachsenden, und gehen dann zurück, und Rest wird gem. 
> Nachsendeauftrag eben weitergeleitet.

Das ist einer der kleinen aber feinen Unterschiede zwischen Brief und
Email. Bei Email ist so ein Fall schlicht und ergreifend nicht
vorgesehen und kann auch mit Krankheiten wie SPF nicht nachgebastelt
werden. Wenn ich nicht will das meine Mail nicht weitergeleitet wird,
dann bleibt nur eine Möglichkeit: Nicht verschicken.
Funktioniert auch bei Briefen nur bedingt. Wer sagt denn das die Oma den
nicht weiterschickt?

> Zumindest halt für etwas sensibleren Sachen würde ich ganze halt
> etwas strenger sehen.

Und was ist sensibel? Du als Empfänger kannst das erst mal gar nicht
beurteilen. Wenn etwas sensibel ist, dann liegt die Verantwortung das
zuverlässig und sicher von A nach B zu bekommen beim Absender und nicht
beim Empfänger.
Wenn etwas wirklich sensitiv ist dann hilft nichts anderes als den
Inhalt zu verschlüsseln. Alles andere sichert nur den Transportweg mehr
oder weniger ab.
Ist wie beim Brief: Sobald ich den eingeworfen habe habe ich keinerlei
Kontrolle mehr was damit passiert.

> Manche Firmen fordern den Kunden ja sogar noch auf deren Absender in
> Whitelist zusetzen, da wundert mich manche phishing mails nicht.

Das sind dann die richtigen Experten. Anstatt ihre verkorksten Systeme
zu reparieren dem Empfänger sagen er soll sich doch bitte in den Fuß
schießen. Meist hat dann da ein bekiffter Webdesigner seine Finger dran
gehabt.

Andreas

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 836 bytes
Beschreibung: OpenPGP digital signature
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20160704/cad616a1/attachment.asc>