Web Hosting + gestione DNS

[cancellato] oggi Wordpress si aggiorna da solo (se ha i permessi per farlo) ma occorre fare molta attenzione ai plug-in

Capisco, infatti molti hosting lo vendono come servizio "premium"

[cancellato] Io ho anche il mio mail server

Perchè mi chiedevo, esiste un mail hosting con dominio proprio che permetta MTA-STS?

[cancellato] Hai provato a fare un test del record DMARC con i vari tool online?

Ho provato ma fanno solo un'analisi formale sul record DMARC

Ho provato a informarmi su quel selector dove c'è il dominio aruba e ho trovato:

È una variabile stringa che aiuta a puntare verso la chiave pubblica DKIM nel DNS del tuo dominio mentre autentichi i tuoi messaggi usando il protocollo di autenticazione DKIM.

Perciò penso inizialmente fa un check dkim sul dominio MX (che non ha dkim perchè lo ha aruba) poi contatta mta-aruba e fa il check dkim che passa con selector per il mio dominio nel loro DNS (aruba.it)
Ora devo pensare se c'è modo di prendere il dkim e metterlo anche nel mio dns?
(l'ho trovata, ci provo)

[cancellato] Il problema IMHO è che se nell'header della mail Aruba ci mette tipo DKIM-Signature: v=1; a=rsa-sha256; d=aruba.it; la validazione di DKIM verrà fatta interrogando il DNS per il dominio aruba.it, non il tuo, a causa del tag d=. Poi fallisce perché il domino della policy

Il primo pezzo è corretto mette come dominio aruba, ma di per sè non fallisce DKIM, anche perchè il messaggio non va in quarantena e controllando tramite gmail, da pass sia SPF che DKIM, non capisco perchè nel riepilogo / report, ci sia il controllo dkim al mta di aruba

Boh arriveranno altri report DMARC e vedremo

Io ora ho messo DKIM uguale ad aruba nel mio DNS, ma come hai sottolineato tu non verrà mai contattato, perchè nel header come dominio c'è aruba.it
Nonostante ciò non ha problemi google, nel header vedo tutto pass

L'unico errore l'ho nel Message-ID, SMTPIN_ADDED_MISSING, perchè aruba non mette nel header un ID per il messaggio inviato

Aruba mette:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aruba.it;
con però anche parametro signature che reinvia al DKIM policy nel record DNS di aruba.it per il mio dominio

[cancellato] e inserire il dominio corretto nell'header a seconda di chi invia.
Se facesse DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=example.com; e nel DNS di example.com mettessi la chiave pubblica di DKIM che utilizzano per firmare gli header, probabilmente si risolverebbe anche quel disallineamento con il rua

[cancellato] Poi fallisce perché il domino della policy è diverso da quello di DKIM

Si il fulcro è questo, fallisce l'allineamento, che però non porta ad applicare la policy (quarantine), forse perchè SPF conferma che il server SMTP è autorizzato?

Stesso problema: https://www.reddit.com/r/Office365/comments/v2r8en/dkim_policy_evaluated_fails_dkim_passes/

Soluzione come la tua proposta: https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/use-dkim-to-validate-outbound-email?view=o365-worldwide

Microsoft 365 automatically sets up DKIM for its initial 'onmicrosoft.com' domains
come aruba

scorpion Rispondo domani, sono stanco, grazie

Quel servizio consigliato in reddit è fantastico

For DMARC to pass, DKIM and/or SPF checks need to pass and the domains must be in alignment.

https://www.dmarctester.com/

Scoperto l'arcano:

SPF auth result is pass and SPF domain is in alignment. DMARC SPF result is pass.
DKIM auth result is pass, but the DKIM domain is not in alignment. DMARC DKIM result is fail.

Because the SPF test passed and the domains are in alignment, the DMARC result is pass.

Chiunque abbia fatto quel sito è un santo ---> creatori https://www.uriports.com/tools

scorpion Se non sbaglio su proprio dominio non è strettamente necessario che il servizio e-mail utilizzato "supporti" MTA-STS per utilizzarlo.

Mi è arrivato anche quel report:

"policies": [{
            "policy": {
                "policy-type": "sts",
                "policy-string": ["version: STSv1", "mode: testing", "mx: mx.example.com", "max_age: 604800"],
                "policy-domain": "example.com",
                "mx-host": ["mx.example.com"]
            },
            "summary": {
                "total-successful-session-count": 0,
                "total-failure-session-count": 1
            },
            "failure-details": [{
                    "result-type": "certificate-host-mismatch",
                    "sending-mta-ip": "209.85.XXX.XXX",
                    "receiving-ip": "62.149.XXX.XXX",
                    "receiving-mx-hostname": "mx.example.com",
                    "failed-session-count": 1
                }
            ]
        }, {
            "policy": {
                "policy-type": "no-policy-found",
                "policy-domain": "example.com"
            },
            "summary": {
                "total-successful-session-count": 1,
                "total-failure-session-count": 0
            }
        }
    ]

"result-type": "certificate-host-mismatch"

MX record mx.example.com supports STARTTLS but the hostname does not match the certificate's CN or SANs

In pratica il servizio mail hosting dovrebbe supportare il certificato con dominio example.com, perchè se lo firmano con il loro dominio, MTA-STS non funziona

Perciò SPF+DKIM+DMARC, riesco ad averli, nonostante fallisca l'allineamento DKIM, mentre per MTA-STS non ho soluzioni se non cambiare mail hosting

Ho cercato e aruba dovrebbe offrire tutto ciò alle grandi aziende e PA, ma è tutto coperto da NDA

Aggiungo che anche con DANE protocollo simile a MTA-STS, comunque si dovrebbe avere il certificato TLSA nel dominio del mail server, perciò è tutto nelle mani di aruba nel mio caso

So, third party SMTP providers that implement TLSA will place and manage the TLSA record under their own domain. The customer (which is you) should not have to perform any changes to their infrastructure.
Fonte

@[cancellato] @scorpion

Ho i report TLS di ieri:

result-type "validation-failure"

quando ho messo MX aruba e policy con aruba

Però nella policy string google mi mostra una policy, quella vecchia, non vorrei che avesse mantenuto la policy per tutto il giorno, nonostante abbia cambiato l'id nel DNS

Perciò apetterò ancora 1-2 giorni con le attuali policy