supergeheime domain ich denk mal die soll nicht erreichbar sein 
Beiträge von kehrer47
-
-
ich vermute alles ist ok, und deine mails kommen an, und die reports kommen, hast ja in dmarc deine email-adresse angeben.
ansonsten mail an testmail@lxsbbs.eu, dann geb ich dir meine gmail-testadr.
bei meinem neuen mail-server will ich demnaechst auch dmarc mit report-adr einrichten,:-)
hab im moment kein dmarc, und weil alles anzukommen scheint hat ich das damit nicht eilig.
-
erstmal selber schaun ob die mail ok sind.
gibt ja auch einge webseiten dafuer.
mein erster test ist immer eine mail an check-auth@verifier.port25.com zu senden, body und subject leer lassen.
man bekommt sofort antwort, einen report.
.
-
-
was auch geht eine mail an check-auth@verifier.port25.com senden
body und suject leer lasen.
-
leg dir einfach eine gmail-adr zu zum testen.
vlt. mal aspf=r versuchen
-
Wo sehe ich die restliche Laufzeit des Let's Encrypt Zertifikats?
-
1. Spf muss valide sein sowie ipv4 und ipv6 darin definiert sein.
2. Dkim valide
3. Irgendeine Subdomain der Maildomain muss auf die IP verweisen, also a und aaaa record vorhanden sein. Bzw. Reverse IP muss auf die tld auflösen.
4. Dmarc eintrag
sogar mail von gmail erfüllt die Kriterien.
prüft jmd das eigentlich selber oder ist das fuer euch ein notwendiges uebel um mail loszuwerden?
wie oben geschrieben erfuellt mail von telekom diese kriterien nicht unbedingt.
haben wahrscheinlich alle telekom in der whitelist, in meinen test ist die ueberall angekommen.
bei mir in der blacklist.
-
ist auch nicht alles schlecht bei der telekom, ich war frueher zufriedener Kunde.
mein erster mail-server lief ueber eine telekom ISDN Leitung.
RedHat Linux 4, das alte bevor es Fedora und RHEL gab.
ist ziemlich genau 25 Jahre her.
aber damals hatte die telekom noch keinen mailserver.
-
in dem log steht ja http validation failed,
gibt es ein webserver log? port 80 und 443 sind offen?
-
Code
echo "" | mail -s "" check-auth@verifier.port25.combei mir stimmt alles, im gegensatz zur telekom, da scheint ja sowas wie dkim luxus zu sein,
oder nur fuer kommerz kunden wie in einem thread aus 2021 zu lesen war.
bei den mails die hier testweise kam muesste telekom auf die whitelist um durchzukommen.
-
bin grad am raetseln was mit forward record gemeint ist?
ptr record zeigt auf den domain namen, der gleiche wie der helo hostname.
wenn dem nicht so waere wuerden z.b. aol, gmail nix annehmen.
sollte eigentlich selbstverstaendlich, ohne das extra zu erwaehnen.
-
mir erscheint alles normal die letzten 2 tage
-
aRaphael scheint da recht zuhaben.
hatte nochmal mit mehreren servern getestet, und bislang ist telekom der einzige der mail von mir ablehnt.
deren domain/ips stehen bei mir jetzt auf reject, macht ja keinen sinn email zu bekommen auf die man nicht antwort will oder kann.
-
oft ist ssh ja so konfiguriert das root-login bzw passwort login verboten sind, dann muss die config angepasst werden.
erstmal ssh login probieren, wenn das geht rsync.
hidrive kenn ich nicht, k.a.
-
aufgrund der rubrik und der posts kann man nur raten welches produkt du bei netcup hast.
wenn dir plesk zur verfuegung steht kannst du darüber certs beziehen.
plesk hab ich nie benutzt, deswg. ka.
kann bei certbot helfen.
-
rsync -uvu -e "ssh -i /root/.ssh/id_rsa" /verz...
am besten gleich mit key, eraspart passwort angabe.
rsync ueber verschluesselten ssh zugang.
-
gibt einige tips im netz fuer mailings, damit nicht als spam erkannt wird, aber von stand da nix.
glaub nicht das es das enscheidene kriterium ist.
-
# mx-backup
#maximal_queue_lifetime = 5w
# mx
#maximal_queue_lifetime = 5d
# host
maximal_queue_lifetime = 10m
einstellungssache.
die 5 wochen beim mx-backup fuer den fall das ich auf Reisen bin und mein homerechner ausgeschaltet.
-
firewalls werden eh ueberschaetzt.
und andere sachen wichtiger wie z.b. lehrgang fuer mitarbeiter, "wie erkenne ich an der email das es nicht mein chef ist der mich auffordert ein paar millionen irgendwohin zu ueberweisen", alles schon vorgekommen.
angriffe kommen nur ueber ipv4.
dachte heut ist der erste auf ipv6, war aber doch kein hack, war google.com, und schuld meine neue domain, google-mailer sind ja vorbildlich auch ueber ipv6 erreichbar.
andere aol, twitter, ein trauerspiel, wenn da in der geschwindigkeit so weitergeht dauert es noch jahrzehnte.
ich find ipv6 eigentlich wartungsfreundlicher.
ich hab mein eigen dns-update-bash script, geht aber sich auch jeder standard ddns-updater
und eine https seite fuer parameter und perl-script fuer nsupdate aufruft.
damit man nicht mit langen ips hantieren muss.
[...]
my $nsupdate = "/usr/bin/nsupdate";
open(NSUPDATE,"|$nsupdate")
print STDERR "911\n";if ($zonename eq "example.com") {
print NSUPDATE "server ns1.example.com\n";
print NSUPDATE "key hmac-sha512:ddns_example.com xxxx==\n";
print NSUPDATE "zone example.com\n";
} else {
print NSUPDATE "server nslocal.example.com\n";
print NSUPDATE "zone $zonename\n";
}
print NSUPDATE "update delete $hostname.$zonename. $rrtype\n";
print NSUPDATE "update add $hostname.$zonename. 360 $rrtype $newip\n";
print NSUPDATE "send\n";
close(NSUPDATE);
[...]
