Beiträge von Febas

    Ich wäre daran interessiert zu erfahren, ob es bezüglich der Anwendungen irgendwelche Änderungen geben wird. Bisher konnte ich darüber nirgendwo etwas lesen, und auch in der Demo/API ist dieser Punkt noch nicht vorhanden. Leider erhalten wir immer wieder Anfragen von Kunden, die sich darüber beschweren, dass einige Anwendungen bereits sehr veraltet sind.

    Zwei Sachen auf die ich noch warte:


    1)


    Zitat

    über die SOAP-API angelegte Domains/Subdomains werden nun standardmäßig in der “einfachen” Ansicht (Stt) angezeigt


    Die Option "auch 'www'-Subdomain erstellen" und "SSL/TLS-Zertifikat automatisch erstellen" fehlt leider noch. Wenn man eine Domain per API anlegt, wird die www-Subdomain nicht angelegt. Wenn man per API (HostingSubdomainAdd) die www-Subdomain anlegt, dann wird die Domain und die Subdomain" www" separat dargestellt, so wie es sonst in der Experten-Ansicht üblich ist, obwohl die Standard-Ansicht aktiv ist. Das ist dann etwas unschön.


    2)


    Beim Anlegen eines Kunden per API kann die Sprache nicht übermittelt werden. Wenn man sich über Single Sign-On einloggt (SessionCreate) ist Englisch als Standard gesetzt, was einige Kunden dann verunsichert.



    Wäre schön, wenn das bald umgesetzt wird. Danke:)

    Eine andere Möglichkeit ist, die Weiterleitungen explizit von einer anderen IP-Adresse / anderem Mail-Server zu verschicken. Seit dem haben wir keine Probleme mehr mit MS / Web / GMX usw. Dann muss man auch keine Weiterleitungen für Kunden verbieten bzw. erklären warum man das nicht darf. Verstehen die meisten Kunden leider sowieso nicht.

    Zitat

    Die Option "auch 'www'-Subdomain erstellen" fehlt hier noch. Wenn man eine Domain per API anlegt, wird die www-Subdomain nicht angelegt. Wenn man per API (HostingSubdomainAdd) die www-Subdomain anlegt, dann wird die Domain und die Subdomain www separat dargestellt, so wie es sonst in der Experten-Ansicht üblich ist, obwohl Standard-Ansicht aktiv ist.


    Das wurde leider noch nicht umgesetzt. Hoffentlich aber bald ;)

    Zitat

    über die SOAP-API angelegte Domains/Subdomains werden nun standardmäßig in der “einfachen” Ansicht (Stt) angezeigt


    Die Option "auch 'www'-Subdomain erstellen" fehlt hier noch. Wenn man eine Domain per API anlegt, wird die www-Subdomain nicht angelegt. Wenn man per API (HostingSubdomainAdd) die www-Subdomain anlegt, dann wird die Domain und die Subdomain www separat dargestellt, so wie es sonst in der Experten-Ansicht üblich ist, obwohl Standard-Ansicht aktiv ist.

    Wenn man eine Domain per API anlegt, dann ist bei dieser immer noch die Experten-Ansicht aktiv, und nicht - wie beim normalen Anlegen - die Standard-Ansicht. Sollte eigentlich kurzfristig korrigiert werden. :rolleyes:


    Noch eine Kleinigkeit:


    Wenn man einen zusätzlichen FTP-Account anlegt (egal ob per API oder Panel) und einen Ordner angibt, der noch nicht existiert, wird der Ordner mit den Rechten 700 erstellt, statt wie davor mit 755. Das führt leider zu einem Fehler beim Aufruf:


    Code
    Forbidden
    
    
    You don't have permission to access this resource.Server unable to read htaccess file, denying access to be safe

    Die Sache ist halt nicht wirklich eindeutig. Fragt man mehrere Steuerberater wird man verschiedene Antworten hören. Am besten das eigene Finanzamt fragen?


    Zitat

    Beispiel: domain.de wird am 25.06.2020 für 1 Jahr berechnet.
    25.06. - 30.06.2020 mit 19%
    01.07. - 31.12.2020 mit 16%
    01.01. - 24.06.2021 mit 19%


    So macht es z.B. Hetzner auch. Smart-Nic wiederum sieht die Sache anders.


    Herr Keppler hat aber vor kurzem in einem anderen Thread geschrieben:


    Zitat

    Ein paar Kollegen erinnern sich ja vielleicht noch an den 01.01.2007, als die MwSt von damals 16% auf 19% erhöht wurde. Das Problem damals (wie heute) ist, dass Hosting-Verträge und Domaingebühren allgemein als "Dauerleistungen" und steuerlich somit als "sonstige Leistungen (Dienstleistungen)" klassifiziert werden. Das bedeutet, dass die Umsatzsteuer mit Ablauf des Leistungszeitraums entsteht.

    Wenn man SpamAssassin über LiveConfig bzw. lcsam läuft, so gibt es bei einer Prüfung kein „SPF_PASS“, auch wenn der SPF-Record der Domain korrekt ist.


    Dadurch kommt es manchmal zu einer Fehlbewertung aufgrund "FORGED_SPF_HELO":


    LiveConfig: 1.5
    bei mail-tester.com SA: -0.2


    Code
    FORGED_SPF_HELO = __HELO_NOT_RDNS && SPF_HELO_PASS && !SPF_PASS


    Beispiel-E-Mail:


    Ausgabe von lcsam:


    Code
    lcsam[820]: 40.107.7.84: ACCEPT (ham 1.5/5.0/2.5 DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FORGED_SPF_HELO,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS)


    Bei aktiviertem Debug (über /etc/default/spamassassin) erhält man den Fehler:


    Code
    spamd[14886]: received-header: parsed as [ ip=40.107.1.83 rdns=mail-eopbgr40079.outbound.protection.outlook.com helo=EUR02-HE1-obe.outbound.protection.outlook.com by=mail.xxx.net ident= envfrom= intl=0 id=02C0B55B355 auth= msa=0 ]
    ...
    spamd[14886]: spf: checking to see if the message has a Received-SPF header that we can use
    spamd[14886]: spf: cannot get Envelope-From, cannot use SPF


    envfrom hat keinen Wert. lcsam übergibt also wohl den Return-Path- / Envelope-Sender-Header nicht?


    Prüft man nun die gleiche E-Mail manuell mit spamassassin -Dspf



    erscheint wie erhofft „SPF_PASS“ und envfrom mit dem gleichen Ergebnis wie bei mail-tester.