Jump to content
Froxlor Forum


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Exploit

  • Rank
    Advanced Froxie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Exploit


    Just to share... I've found a very good article about SPF, SRS and DKIM here: https://www.heinlein-support.de/blog/news/gmx-de-und-web-de-haben-mail-rejects-durch-spf/ Not Germans may prefer this: https://translate.google.com/translate?sl=auto&tl=en&u=https%3A%2F%2Fwww.heinlein-support.de%2Fblog%2Fnews%2Fgmx-de-und-web-de-haben-mail-rejects-durch-spf%2F
  2. Exploit


    This would help to make email delivery working better, but note that SPF and DMARC are not only DNS-entries, but also doing some filtering and reporting work on incoming email. Which are only to include in the Postfix Configuration. On this moment I'm just checking out how Froxlor handles this (storing the keys, etc..), seeing that the source code (version 1.0) still contais commands like "/etc/init.d/dkim-filter restart" which needs to be updated, since dkim-milter is replaced by OpenDKIM. The configuration files for postfix are looking quite hacky for me, but so far I understand them, I can't find that SPF and DKIM are included in the configuration templates, coming from /lib/configfiles. So far I can try to fix those and commit updates with git. SRS I consider as a part of SPF, since it has no other function as patching delivery-problems that SPF causes on email forwarding. I've also opened a discussion on Gmail, about SRS which can't be implemented without undesired side effects, like breaking the DKIM signature of the original message, which can't be the intention of DMARC. I relly don't like SRS, but for now I see no another working solution, to get rid of forwarding messages being refused.
  3. Exploit


    Exactly, that's where it's made for. Thinking about this further, I consider SRS is only necessary due to lack of DKIM support or bad practices of DMARC implementation. It makes no sense to refuse any e-mail having a valid DKIM signature. Having DKIM-signed e-mail manipulated or spoofed, would mean a leaked out private key. So companies having a DMARC record that requires a valid SPF and also a valid DKIM-signature, are assuming having very serious security issues. So far i noticed only refused mails which are forwarded for Facebook and for Twitter, which are both using DKIM. So far I'm hoping and assuming that already DKIM signed e-mail not will be signed again by the forwarding sever. (anyone who can confirm this?).
  4. Exploit


    Yes, it looks like sending email has become in the last years such a complicated thing, that almost nobody is able to set up a flawless mailserver. SPF, DKIM, DMARC, SRS, each of them needs several components to be installed, if you want to let your customers setup their own email addresses. However Froxlor seems to miss only: DMARC which is technically similar to creating and checking SPF (but does also reports) SRS which implementation is quite similar as adding a DKIM signature for outgoing mail and a spam-filter for incoming messages (proper handling of bounces is a bit challenging, but this should be solved by the SRS software) With all these working, Spoofing eMail is definitely not possible anymore, so I think that we will not see more coming up for the next years. SPF may disappear after a while, because it overlaps with DKIM, which would make SRS obsolete too. For the next years I don't see it happen that everyone uses DKIM, so we will have to deal with SPF and SRS.
  5. Exploit


    No, I can't fix the SPF records for Twitter, Facebook and all others who don't allow everyone to send mail from their address. Being able to do that, I would be the God of all spammers ­čÖé SPF and Forwarding is a well known problem and SRS is good documented, standardized an quite simple. The implementations are more complicated, and for most mail-servers still in an experimental state. I think this is because of security, you don't want to create a open-relay. SPF is good explained here: http://www.openspf.org/SRS
  6. Exploit


    The setup is like this... A customer who owns "example.com" has created in froxlor "info@example.com", which he forwards to customer@gmail.com Now he use info@example.com to receive news from (e.g.) twitter. Now twitter sends a newsletter to info@example.com which will hang for a while in the mail-queue and fail, because gMail refuse my server to send e-mail originating from twitter.
  7. Exploit


    The problem starts when a customer forwards his mail from Facebook, Twitter, etc.. to his (e.g.) Gmail. That mail will be rejected, because the IP-Address of the forwarding server isn't allowed to send it by the SPF-records of the origin senders. I'm not sure what the $secrets of following row is used for from the example of the last link in my post above: start-stop-daemon -S -q -b -p $PID_FILE -x $DAEMON -- -p $PID_FILE $OPTIONS $DOMAIN $SECRETS I guess that it needs some setting on domain-level, which I will try to check further out...
  8. Exploit


    It's an old thread, but still in the same state so far I can see. Since the last months I see that the number of rejected emails from customers who are using the forwarding functionality in Froxlor increases dramatically. The solution for this is implementing is 'Sender Rewriting Scheme' (SRS), which I need to implement, I've been reading quite a lot and enough stuff about this to make SRS with Postfix working, but before I start to do so, I would like to know if there is already work going on to implement SRS in Froxlor and what would be the best Froxlor-way to do it. ??? Some articles that I found to be useful, but need to be adjusted to work with Froxlor together: https://thomas-leister.de/mailserver-debian-stretch/ https://jichu4n.com/posts/setting-up-dkim-and-srs-in-postfix/ https://christophfischer.com/linux/15-mailserver/56-sender-rewriting-scheme-srs-fuer-postfix-unter-debian Is there already anything in development for the Froxlor project?
  9. Exploit

    Automatisches Anlegen von Sub-Domains

    Auf den ersten Blick, kein Problem. Einen Virtualhost anlegen mit "autoconfig.*"- und "autodiscover.*"-Aliasse, Fertig! Nur funzt das nicht mit SSL, das muss dann wieder per Chronjob mit Froxlor's Domaintabelle gemacht werden, also kann mann es quasi gleich in Froxlor einbauen... .. Vielleicht komme ich die Woche mal dazu...
  10. Exploit

    Automatisches Anlegen von Sub-Domains

    Hmm, das stimmt, die XML's sind bei allen domains gleich. Habe ich etwas in Froxlor ├╝bersehen, oder muss ich das manuell konfigurieren? Habe mir dazu diese Anleitung durchgelesen: Im Idealfall sind demnach ja unter jeder Domain diese beiden Pfade erreichbar: autoconfig.example.com/mail/config-v1.1.xml autodiscover.example.com/autodiscover/autodiscover.xml
  11. Exploit

    Automatisches Anlegen von Sub-Domains

    Also Autokonfiguration ist eine sch├Âne Sache! auch das erfordert allerdings das Subdomains angelegt werden, dazu dann noch die XML-Dateien. In Prinzip kann Froxlor ├Ąhnliche Sachen ja schon, mit dem www-Alias und der Default index.html beim Anlegen einer Domain und der Standard-Subdomain beim Anlegen von einem neuen Kunden. Werde mich mal an den Entsprechenden Stellen im Quellcode umschauen, ob die autoconfig dort mit herein passt.
  12. Exploit

    Non www to www mit https

    Then you need to disable the https redirect in froxlor and use the one that you already was using.
  13. Exploit

    Automatisches Anlegen von Sub-Domains

    Achso, verstehe, geht bei Mail also immernoch nur mit IP-Basiertem Zertifikat. Danke f├╝r den Tipp!
  14. Exploit


    Genau, da finde ich das Korrektur- und Diskussions- Modell von Wikipedia super. Eine entsprechend gro├če Gruppe von aktiven Usern vorausgesetzt, funktioniert das mit der Qualit├Ąt ja ganz gut. Die Wiki auf Github habe ich gesehen. Github halte ich aber nur f├╝r Programmierer geeignet, andere d├╝rften sich wohl kaum damit besch├Ąftigen Wiki's zu Committen und Programmierer haben dazu ja bekanntlich meistens keine Zeit.
  15. Mir ist aufgefallen das viele eMail-Clients bei der Einrichtung eines Konto's automatisch Adressen wie "imap.example.com", "smtp.example.com", etc.. vorschlagen. Beim Zuweisen einer neuen Domain, w├╝rde ich derartige sub-Domains gerne samt Let's Encrypt mit-einrichten, damit Kunden die Standard-Einstellungen einfach ├╝bernehmen k├Ânnen. Am liebsten ohne das sie zwangsl├Ąufig im Panel unter den Domains erscheinen. Ist das machbar oder kann ich das ohne allzu gro├čen Aufwand machbar machen? Da ja gerade sowieso einiges auf API umgestellt wird, vielleicht ein guter zeitpunkt