Beiträge von Pixel

Gibt es auch ein "RS Ostern S OST22" ?

Unter Zahlen finde ich jetzt das .EU Domain Osterei, aber ich suche den/die Root Server Eier

Zitat von hase

Gerade wieder bei Über uns. Sehr versteckt, man sieht nur das obere Stück vom Ei

Da sehe ich ein anderes Angebot. Vielleicht wandern die Eier ständig?

Zitat von H6G

RS Ostern M 15,50€

6 Cores, 16 GiB RAM, 640 GB SSD

Über uns

Das suche ich auch, wo ist es?

Hallo Demlak

Da Microsoft keine vernüftige Antwort gibt, aufgrund der man weiss woran es genau liegt, habe ich angenommen, dass die Anforderungern verschärft wurden.

Ich hatte vorher nur postfix ohne DKIM/DMARC im Einsatz und entsprechend schlechte "Noten" bei MECSA. Bevor ich erneut bei Microsoft reklamiere, wollte ich deshalb möglichst gut MECSA Ergebnisse vorweisen können, wie hier im Forum empfohlen. Das hat dann auch funktioniert - ob es wegen DKIM/DMARC besser wurde kann ich natürlich nicht wissen.

Leider habe ich auf meine oben gepostete Email wegen dem IP Range Block keine vernünftige Antwort erhalten. Eine neue Person, oder ein Künstlicher Idiot (KI), antwortet ohne die Anfrage verstanden zu haben mit:

Zitat

As we see you have submitted more than 256 IPs: (193.31.24.0 - 193.31.27.255)Please note our issue submission form allows up to 256(/24) IPs per ticket.

Performing a preliminary investigation before submission will help us to address your issues more efficiently. Please only submit IP addresses that receive errors indicating a deliverability issue.

Ich sehe leider nicht was wir Kunden da machen können, ausser wie du sagst von hotmail/outlook abraten.

Nachdem erneuter durchsicht der anderen Foren Beiträge, habe ich mich entschlossen noch einmal Microsoft zu schreiben:

Zitat

Dear xxxx,
Many thanks for you help and implenting the mitigation!
My server is hosted by netcup.de and is inside an IP range, which has been blocked by microsoft multiple times in the past. The range is 193.31.24.0 - 193.31.27.255.
While I am responsible for this single server/IP, I am not responsible for the whole IP range. However, according to the customer forum of netup.de, many customers like me have this problem and trying to get the block removed for their IP’s only to find the block to be restored over the whole IP range after a few month.
Is there anything which can be done to prevent this address range block? I think it is in your interest as well, that only the bad mail servers are blocked.
Regards,

Es macht ja keinen Sinn wenn jeder betroffene netcup Kunde alle paar Monate erneut Emails schreibt. Die sollen doch bitte schön nur einzelne IPs blockieren die gegen ihre Bestimmungen verstossen und nicht gleich den ganzen Range. Wie die Schweizer sagen: Nützt's nichts, dann schadet's auch nichts....

Inzwischen wurde meine IP Adresse von Microsoft wieder von der Blacklist genommen. Hier ein kurzer Bericht:

Nachdem ich eine Email mit einem Hinweis erhalten habe, dass meine IP gesperrt ist, habe ich Microsoft geschrieben.

Daraufhin habe ich, wie andere hier im Forum bereits geschildert haben, eine ablehnende Email erhalten:

"Our investigation has determined that the above IP(s) do not qualify for mitigation."

Daraufhin habe ich den Mail Service neu auf Basis von mailu.io aufgesetzt (Linux Docker Container). Mit Mailu habe ich jetzt mehrere Email Domains mit
StartTLS, X509, SPF, DKIM, DMARC

laufen und erhalte bei MECSA folgendes Rating:

CONFIDENTIAL DELIVERY (4.0/5)

PHISHING AND IDENTITY THEFT (4.5/5)

INTEGRITY OF MESSAGES (5.0/5)

Die fehlende Punkte/Sterne benötigen DNSSEC und DANE, werden aber nur von einer verschwindend geringen Anzahl von Mail Servern erreicht.

Diese "Verbesserung" war sowieso fällig um zu verhindern, dass andere Mail Server Mails mit meiner Absenderadresse verschicken. Die Konfiguraiton von DKIM/DMARC war mir jedoch bisher einfach zu aufwändig. Die Migration zu mailu lohnt sich aber, da mailu gleich mehrere "Features" mitbringt (optional):

- virus check

- spam filter

- webmailer

- pop/imap

- admin tool (web)

- beliebig viele mail domains

Mailu gibt über die Admin Oberfläche auch Informationen wie der DNS konfiguriert sein muss, damit SPF/DKIM/DMARC funktionieren. Somit spart man sich hier viel Hirnschmalz. Da ich den eingebauten letsencrypt nicht verwenden wollte sondern mein eingenes letsencrypt setup und gleichzeitig noch Webserver im gleichen System habe, war etwas Anpassung/Tüfteln notwendig.

Daraufhin habe ich erneut an Microsoft geschrieben (Antwort auf erste Mail) und nun schreibt Microsoft:

Hello,

My name is xxx and I work with the Outlook.com Deliverability Support Team.

We have implemented mitigation for your IP: xxx.xxx.xxx.xxx and this process may take 24 - 48 hours to replicate completely throughout our system.

Sincerely,

xxx,

Outlook.com Deliverability Support.

Es ist also möglich eine IP wieder freizuschalten, auch wenn der Addressrange geblocked ist.

Zitat von m_ueberall

Gegebenenfalls ist es hilfreich, wenn die IP-Adressen/Domänen auf ein Unternehmen verweisen.

Meine Vorgehensweise hier (bislang erfolgreich) war zuletzt, einen MECSA-Report anzufordern, welcher von Zeit zu Zeit überarbeitet wird und IMHO eigentlich fast alles abdeckt (sicherzustellen, dass dort die volle Punktzahl erreicht wurde!), und dessen Original-URL mit Bitte um Neubewertung/Rückmeldung im Falle von "etwaigen verbleibenden Problemen" an die Kontaktadresse desjenigen Providers weiterzuleiten, der eigene Mails zurückgewiesen hat.

(FYI: My Email Communications Security Assessment (MECSA): 2018 Results)

Danke m_ueberall, sehr interessante Seite. Ich habe leider noch keine 100%!

Anscheinend benötige ich noch DMARC/DKIM/DNSEC um 100% zu bekommen -

auf diese Extras meinte ich bisher verzichten zu können

Zitat von dimendia

ganz Lustig... hab es über Microsoft versucht und bekam folgende E-Mail als Antwort:

Und jetzt ?

Hätte ich gewusst dass das solche Probleme macht, dann hätte ich mich NIEMALS für Netcup entschieden

Ich hatte das Problem schon mehrfach (bei anderen Providern). Im laufe der Jahre wurde es immer schwieriger einen eigenen Mailserver zu betreiben. Insbesondere Microsoft, selbst eine der schlimmsten SPAM Schleudern, meint jetzt alle abstrafen zu müssen die nicht von einem der grossen Mail Provider bedient werden. Auch grosse Firmen und Universitäten, die schon seit Jahrzehnten Mailsysteme betreiben (von Microsoft), kommen auf solche Blacklisten. Es genügt da schon irgendeine Unregelmässigkeit.

Ich habe jetzt auch dieses Problem:

host
    hotmail-com.olc.protection.outlook.com[104.47.13.33] said: 550 5.7.1
    Unfortunately, messages from [193.31.xxx.xxx] weren't sent. Please contact
    your Internet service provider since part of their network is on our block
    list (S3150). You can also refer your provider to
    http://mail.live.com/mail/troubleshooting.aspx#errors.
    [HE1EUR04FT040.eop-eur04.prod.protection.outlook.com] (in reply to MAIL
    FROM command)

Auch bei mir findet die mxtoolbox die Konfiguration und Reputation durchweg in Ordnung.

Vielleicht würde es etwas bringen, wenn alle betroffenen Kunden sich zusammentun und einen gemeinsamen Aufruf an Microsoft schicken.

Da wir alle irgendwelche Blogs betreiben, können wir auch gemeinsam einen offenen Brief posten.

Hallo Skulduggery

Danke für deinen Hinweis! In meinem Fall ist die IPV6_DEFAULTGW eine nicht geroutete Adresse: fe80::1

Die HWADDR ist gesetzt und passt zum Interface. Dieser Parameter war bereits gesetzt, hat aber offenbar nicht ausgereicht für IPv6 über nicht routebare Adressen. Ich will ja nicht nur von aussen erreichbar sein, sondern auch antworten können! Dazu muss der Server die Antwort an das GW schicken. Wenn IPV6_DEFAULTDEV gesetzt ist, und nur dann, habe ich den dafür notwendigen folgenden Eintrag in der Routing Tabelle:

# route -n -6|grep UG
::/0                           fe80::1                    UG   1   4314105 eth0

Mein Centos7 ist noch ein Stock Image, ich habe keine udev Rules definiert. Inzwischen ist auch alles migriert und es funktioniert alles. Auch docker (ich habe einen einzelnen Container), Verbindungen über Firewall Exception auf andere Server mit IPv6 und der Fallback auf IP4 wenn IPv6 routing nicht möglich ist (sofern ein DNS Eintrag für IP4 vorhanden ist, versteht sich).

Gibt es bei mir einen 6to4 Tunnel? Ich kenne das nur von Routern. Der Server ist aber nicht als Routern konfiguriert sondern hat ledigilch dual stack, d.h. IP4 und IPv6 sind konfiguriert. Das ist die default Konfiguration für Linux. Mit einen 6to4 Tunnel kann man meines Wissens IPv6/IP4 Adressen NATen. Das mache ich hier nicht und ich glaube da ist auch nichts konfiguriert worden (weder von mir noch vorkonfiguriert).

Stimmt, da steht im Prinzip alles und diese Seite habe ich auch gesehen. Sie beschreibt wie man weitere IP4 und IPv6 Adressen hinzufügen kann. Aber bei mir fehlte die Zeile IPV6_DEFAULTDEV=eth0 bereits nach der Installation und deshalb gab es auch keine Default Route und die voreingestellte IPv6 war nicht erreichbar.

Um IPv6 unter CENTOS 7 zum laufen zu bringen war bei mir ein zusätzlicher Eintrag in der Datei /etc/sysconfig/network-scripts/ifcfg-eth0 notwendig.

Nach der Installation standen dort folgende Einträge (IPv6 Adresse geändert):

IPV6ADDR=2a03:4000:2b:dead:beaf:1234:5678:1234/64
IPV6INIT=yes
IPV6_DEFAULTGW=fe80::1

Besonders verwirrend: das Default Gateway ist eine nicht routebare IPv6 Adresse (fe80::1). Bei einem anderen Hoster (von dem ich gerade weg migriere), steht hier eine normale IPv6 Adresse.

Zudem konnte ich den Verbindungsaufbau von einem andern Server ausserhalb von netcup Netz auf meinen Server mit IPv6 beobachten (tcpdump). Es schein so, als ob das SYN Packet verworfen wird, weil der Server nicht wusste wohin die Antwort geschickt werden muss. Nach erfolgloser Sucher im Forum, bin ich zunächst davon ausgegangen, dass das Gateway falsch ist.

Die Lösung ist aber ganz einfach! Es fehlt nur eine Zeile im /etc/sysconfig/network-scripts/ifcfg-eth0:

IPV6ADDR=2a03:4000:2b:dead:beaf:1234:5678:1234/64
IPV6INIT=yes
IPV6_DEFAULTGW=fe80::1
IPV6_DEFAULTDEV=eth0

Nach dem Neustart (systemctl restart network) funktioniert der Zugriff auch über IPv6.

Die hier im Forum noch vorgeschlagene Lösung mit ndppd war bei mir nicht nötig.

Interessant in diesem Zusammenhang ist auch folgender Link:

https://www.geeklab.info/2013/05/ipv6-neighbour-proxy/

Bei mehreren IPv6 Adressen im gleichen Server ist ev. die dort beschriebene proxy_ndp erforderlich.