ah, das hab ich wohl dann überlesen...
nevertheless, nachdem man schon LE hat, würde ich das Thema weeeeiit hinten priorisieren - aber die Priorisierung war ja schon immer ein Mysterium bei LC, zumal bei Sachen die schon seit längerem laut eigener Aussage fertig sein sollten. 
warum das für mich nicht in Frage käme: man muss ein Blob einer kleinen ausländischen Firma ausführen...
Wir hatten nur den Fehler, dass in der /etc/default/spamassassin bei -u "spamd" stand anstatt "debian-spamd". Alle Ordner hatten die Rechte debian-spamd:debian-spamd. Damit funktionierte dann auch der Cronjob ohne Probleme (Ubuntu 14.04 LTS).
das scheint mir bis jetzt die einfachste Lösung, soweit läuft es damit
ich ich pro 7 Tage Maximal 5 Zertifikate für die Gleiche Domain beantragen kann..
ach stimmt... ja, dann ist der feature request wirklich gut.
wieso darf es denn nur ein einzelnes Zertifikat sein?
vielleicht installiert er es inklusive graphischer Oberfläche? - am Desktop ist Ubuntu schon nutzerfreundlicher als ein "Original"-Debian
Wobei da vielleicht ein Linux Mint auch noch in Frage käme dann, aber gut, off topic 
Schließe mich Anton an.
Aber das ist wohl leider häufig keine sachlich fundierte Entscheidung, sonst würde man ja in Betracht ziehen, dass fast jeder Security-Fix in Debian früher drin ist - und einige in Ubuntu nie ankommen, von non-security Bugfixes ganz zu schweigen, worüber die einschlägige Presse ja auch schon berichtet hat.
Hat das schon jemand von euch lösen können?
update: gmx.de/web.de haben ihren SPF-Eintrag von -all zu ~all geändert. soft-fail nun also.
usability ist dabei halt deutlich einfacher, die Kunden machen es nunmal so.
Alles anzeigenGanz klares NEIN - nicht falsch verstehen, habe nichts gegen die Implementierung...
Die Vorgehensweise ist falsch bzw. nicht mehr praktikabel in der heutigen Zeit eben wegen SPF, Virenscans, RBL & Co
E-Mails sollten nicht mehr weitergeleitet werden sondern abgeholt werden. Somit landet man auch nicht "fälschlicherweise" auf der internen RBL wenn beim weiterleiten mal wieder SPAM dabei war.
ABHOLEN ABHOLEN ABHOLEN :cool:
der Ansatz funktioniert nicht, wenn die Weiterleitung ein Verteiler ist an viele Leute, die gar nicht Kunde sind.
Und das reicht wirklich aus um das Problem zu umgehen? Oder hat das noch einige Nebenwirkungen beim normalen Mailverkehr?
mal sehen, ich brauchte einfach eine Lösung für die Kunden, bisher klappt's
Die Frage die man sich hier stellen möchte wäre doch ob man wirklich die Emails umschreiben möchte nur weil GMX und Co. (die verständlicherweise möchten, dass man deren Dienste nutzt und sonst kein Geld damit verdient) nun Weiterleitungen blockieren.
naja, ich würde ihnen da nicht die volle Schuld zuschieben, wenn dann den Domainbetreibern, die SPF auf den "-all" Modus setzen. (zu denen web.de/gmx auch gehören, aber das ist ja nicht die aktuelle Änderung)
Und auch die machen das in der Regel absichtlich, die Absender mit solchen Domains dürfen sich also dort beschweren - aber man weiß ja wie gut es klappt, wenn man als kleiner Provider auf die großen als Verursacher verweist.
Wenn jemand SPF so einstellt auf seiner Domain, dann WILL er, dass gmx/web.de so handeln wie sie es jetzt tun.
habe es unter Debian Jessie so eingerichtet, mal sehen, welche Probleme auftauchen durch SRS...
wget https://github.com/roehling/postsrsd/archive/master.tar.gz -O postsrsd-master-20160529.tar.gz
tar xf postsrsd-master-20160529.tar.gz
cd postsrsd-master
apt install cmake
make
make install
systemctl daemon-reload
systemctl enable postsrsd
systemctl start postsrsd
postconf -e "sender_canonical_maps = tcp:127.0.0.1:10001"
postconf -e "sender_canonical_classes = envelope_sender"
postconf -e "recipient_canonical_maps = tcp:127.0.0.1:10002"
postconf -e "recipient_canonical_classes = envelope_recipient,header_recipient"
postfix reloadAchtung: wenn man es nur so macht, kann es von LiveConfig überschrieben werden in der /etc/postfix/main.cf
Nachtrag:
Wäre übrigens sehr toll, wenn das jemand als Debian-Paket verpacken würde, die Version in den offiziellen Debian-Repositories ist nämlich uralt...
Mir ist nicht ganz klar, was dort verhindert, dass via DNS Spoofing der entsprechende Eintrag entfernt wird.
Um das zu verhindern braucht man doch DNSSEC und kann dann gleich DANE hernehmen...
Die Kritik an DNSSEC ist auch etwas ... naja, wenn es ach so kompliziert wäre, hätte nicht z.B. cloudflare es weltweit im Einsatz...
Port 8443 kann ich auf Jessie bestätigen, Port 443 nicht.
Eigentlich müssen nur die Angebote abgeändert werden.
für Dinge die nicht im Angebot stehen klappt das aber nicht. (z.B. greylisting, spamfilter, ...)
für Verträge ohne Angebot ebenfalls nicht.
Das war schon immer so und liegt in der Natur von Autodiscover. Mag sein dass das mit AutoConfig (Thunderbird) geklappt hatte - unsere Anleitung berücksichtigt aber beide Systeme.
habe gerade in die History des Dokuwiki geguckt: in der alten Version stand das nicht.
Die "alte" Anleitung müsste in der DokuWiki-History noch zu finden sein (ungetestet).
leider nicht, was vor der Wiki-Umstellung (im Rahmen der neuen Website) dort stand - ich hatte da auch nicht mehr nachgesehen, seit das allererste Mal eine Anleitung veröffentlicht wurde, damals hatte ich sie kopiert und für unsere Erfordernisse aufbereitet.
Ich bin ziemlich sicher, dass z.B. die Anpassung der liveconfig.conf dort nicht erwähnt wurde - ist natürlich aber nicht mehr nachvollziehbar.
Anderswo im Forum hatte jemand ja eine Lösung gefunden, wie es auch für Outlook funktioniert, wenn man eine Subdomain auf 127.0.0.1 zeigen lässt.
Das ist für viele wohl die machbarere Variante, da eine zusätzliche IP häufig Geld kostet - oder bei manchem VM-Anbieter gar nicht buchbar ist.
und ein mini-bug:
im dialog "smtp server konfigurieren" kommt ein "undefined", wenn man auf das "i" neben "Servername" klickt
seit wann gilt denn, dass die IP für autoconfig nicht für HTTPS-Webspace genutzt werden darf?
Ich würde fast schwören, das war früher nicht in der Anleitung gestanden...
auch die http_rewrite Anweisung für liveconfig.conf ist mir neu...
Da wäre ein changelog und eine Migrationsanleitung für bestehende autoconfig-Setups schon angebracht...
wieso müssen sie da alles neuinstallieren und einstellen?
