Rimuovere apache @ localhost dalle intestazioni delle e-mail?


11

La mia configurazione: sto gestendo un sito Web Magento su un server Amazon Linux (che sembra fondamentalmente CentOS) con un server web Apache. Uso anche Google Apps per gestire la posta di mydomain.com.

Sono stato in grado di impostare correttamente i record MX, SPF e DKIM per il server e di averli fatti funzionare, in modo da ricevere un "Pass" sia per SPF che per DKIM quando invio e-mail. Tuttavia, ho riscontrato uno strano problema che non riesco a superare --- parte dell'intestazione per le e-mail che invio sembra sempre dire:

Received: (from apache@localhost) by mydomain.com 

Ho cercato in alto e in basso un modo per cambiarlo per usare invece "mail@mydomain.com", ma non riesco proprio a capirlo.

Tra le cose che ho provato:

  • Cambiando php.ini per dire: / usr / sbin / sendmail -t -i -f mail@mydomain.com
  • Aggiungendo al virtualhost di mydomain.conf la riga: ServerAdmin mail@mydomain.com
  • Impostando Return-Path su "Sì" nel backend Magento (Sistema -> Configurazione -> Avanzate -> Sistema -> Impostazioni invio posta.

Se aiuta, i contenuti del mio file / etc / hosts sono i seguenti:

127.0.0.1   www.mydomain.com
127.0.0.1   mydomain.com
127.0.0.1   localhost localhost.localdomain

Per l'ultima riga del file hosts, ho anche provato la variante ...

127.0.0.1   localhost.localdomain mydomain.com

... ma ancora non ha funzionato.

Ho pensato che potesse essere d'aiuto anche se avessi aggiunto le intestazioni dell'e-mail, nel caso in cui ciò potesse fornire alcuni indizi su ciò che potrebbe accadere (ho cambiato molti valori per mantenerlo generalizzato).

Delivered-To: zerowing@email.com
Received: by 123.123.123.123 with SMTP id abcdefg123456790;
        Fri, 3 Apr 2015 08:35:04 -0700 (PDT)
X-Received: by 456.456.456.456 with SMTP id asdfqwerhjkl234hjkl.789.78909876789;
        Fri, 03 Apr 2015 08:35:03 -0700 (PDT)
Return-Path: <mail@mydomain.com>
Received: from mydomain.com (ec2-11-11-111-11.amazonaws.com. [66.66.777.77])
        by mx.google.com with ESMTPS id asdkfjhkjdfha839383.105.2015.04.03.08.35.02
        for <zerowing@email.com>
        (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Fri, 03 Apr 2015 08:35:03 -0700 (PDT)
Received-SPF: pass (google.com: domain of mail@mydomain.com designates 66.66.777.77 as permitted sender) client-ip=66.66.777.77;
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of mail@mydomain.com designates 66.66.777.77 as permitted sender) smtp.mail=mail@mydomain.com;
       dkim=pass header.i=@mydomain.com
Received: from mydomain.com (www.mydomain.com [127.0.0.1])
    by mydomain.com (8.14.4/8.14.4) with ESMTP id t33FZ29p004251
    for <zerowing@email.com>; Fri, 3 Apr 2015 15:35:02 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mydomain.com;
    s=default; t=fjIFDJF9049;
    bh=fjO4J4f09j409JF04J909f4j904JF940F9/Y=;
    h=To:Subject:From:Date;
    b=F4J90FJ490j09j490FJ094J0j94f90j409j490Jf90j904JF09j490fj904jf094J
     f09J40F9J904fj049J099j49J049J0FJijffjdlfjldkDLFJKLdjflEJFOIJFOEIEO
     JF9JF049j409j0F094J09FJ049jf049j=
Received: (from apache@localhost) <----------- THIS IS WHAT I'M TRYING TO CHANGE
    by mydomain.com (8.14.4/8.14.4/Submit) id fkdjfljlfsra39393;
    Fri, 3 Apr 2015 15:35:01 GMT
Message-Id: <201504031535.fkdjfljlfsra39393@mydomain.com>
To: =?utf-8?B?Sm9lIEdhcmNpYQ==?= <zerowing@email.com>
Subject: =?utf-8?B?VGVzdCBOZXdzbGV0dGVyLCBwbGVhc2UgaWdub3Jl?=
X-PHP-Originating-Script: 48:Sendmail.php
From: "mydomain.com" <mail@mydomain.com>
Date: Fri, 03 Apr 2015 15:35:01 +0000
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
MIME-Version: 1.0

Una parte di me non è sicura se questo è normale, e immagino non sono sicuro di cosa potrebbe causare la comparsa di apache @ localhost, ma se qualcuno ha un'idea sarebbe molto apprezzato, grazie!

Modifica L'MTA che sto usando è Sendmail. Ecco le modifiche di configurazione che ho apportato al file sendmail.mc per adattarle al mio sito.

MASQUERADE_AS(`mydomain.com')dnl
FEATURE(masquerade_envelope)dnl
FEATURE(masquerade_entire_domain)dnl
INPUT_MAIL_FILTER(`opendkim', `S=inet:8891@127.0.0.1')
define(`confCW_FILE', `/etc/mail/local-host-names')dnl
dnl define(`confDOMAIN_NAME', `mydomain.com')dnl

Modifica Non sono sicuro che questa domanda sia stata contrassegnata nuovamente come duplicata, quindi ho pensato di enfatizzare il ragionamento sul perché non si basa sulla domanda sottoposta sul perché non lo sia. Passare a Postfix non è una soluzione, ma una soluzione alternativa. Odierei sradicare tutte le impostazioni che ho fatto con Sendmail finora solo per incontrare altri potenziali problemi cercando di far funzionare Postfix. Ho anche menzionato la modifica del comando sendmail in php.ini, se leggi i punti elenco sopra menzionati.

Modifica Ho pensato che potrei anche menzionare alcune delle altre cose che ho provato a fare che non ha funzionato. Ho aggiunto a sendmail.mc le seguenti righe:

FEATURE(`genericstable',`hash -o /etc/mail/genericstable.db')dnl
GENERICS_DOMAIN_FILE(`/etc/mail/generics-domains')dnl

Ho quindi creato un file generics-domains con la sola riga "mydomain.com" al suo interno. Quindi, ho creato un file genericstable con la sola riga "apache mail@homebrewsupply.com" al suo interno. Ho eseguito make nella directory di posta, ricreato il file cf e riavviato sendmail, ma nessun dado.

Ho provato a modificare il file / etc / aliases. Ho provato a cambiare la riga "apache: root" per dire "apache: root, mail @ mydomain.com", così come solo "apache: mail@mydomain.com", ma neanche quello ha fatto nulla.

Ho anche provato ad aggiungere al file / etc / mail / virtuserstable la riga singola "apache @ localhost mail@mydomain.com". Neanche quello ha fatto nulla.

Sono sorpreso da quanto sia frustrante farlo funzionare correttamente. Sono così vicino ad averlo dove ne ho bisogno, ma onestamente non so dove cercare di sostituire la linea "apache @ localhost".



Bene per uno, le soluzioni a quelle domande non funzionano per me. La prima soluzione si riduce a "Non sono riuscito a capire come far funzionare sendmail, quindi ho rinunciato e sono passato a Postfix". Questa non è una soluzione al problema, è una soluzione alternativa. Anche la seconda soluzione, per aggiungere il nomeserver al file hosts, non ha funzionato per me, quindi essenzialmente il problema che sto riscontrando deve essere diverso. E non è che posso aspettare che qualcuno aggiunga altre soluzioni praticabili a domande che hanno più di 2 anni.
Zero Wing

Risposte:


4

L'indirizzo di posta elettronica da è l'utente del demone che ha richiesto l'invio del messaggio (apache) @ il nome di dominio configurato nell'MTA (sendmail o postfix).

Se l'MTA locale è postfix, è necessario modificare l'impostazione myorigin (che per impostazione predefinita è il nome host configurato. Localhost in questo esempio). Questa impostazione è in main.cf (la posizione predefinita nella maggior parte delle distribuzioni è /etc/postfix/main.cf). Basta cambiarlo con il nome di dominio che si desidera inviare. Quindi riavviare postfix.

Naturalmente, potrebbe essere più semplice modificare il nome host del server in modo che corrisponda al dominio di invio desiderato.

Tieni presente che se hai intenzione di inviare e-mail da questo server per quel dominio, ti consigliamo di aggiungere un record DNS SPF che lo consenta, altrimenti i tuoi messaggi verranno probabilmente scaricati dai filtri antispam.


Ciao, il mio MTA è effettivamente sendmail, anche se penso di aver apportato tutte le possibili modifiche che è possibile apportare (proverò ad aggiungere alcune di queste modifiche alla mia domanda). Potresti anche chiarire "cambiare il nome host del server in modo che corrisponda al dominio di invio desiderato?" Se vuoi dire che dovrei farlo in modo che quando scrivo "hostname" sulla riga di comando in modo che venga visualizzato mydomain.com, ho già configurato. Inoltre, ho un record SPF impostato per il dominio, ho menzionato nella domanda che ho SPF e DKIM impostati e funzionanti correttamente (vedo un passaggio per entrambi nelle intestazioni delle e-mail).
Zero Wing

È stato trovato un post che potrebbe essere utile per suggerire quanto segue: Per modificare l'indirizzo "from" della busta su unix, è necessario specificare un'opzione "-r" sul file binario di sendmail. Puoi farlo globalmente in php.ini aggiungendo l'opzione "-r" alla riga di comando "sendmail_path". fonte: stackoverflow.com/questions/5666312/…
Joe

Ho provato ad aggiungere "-r" a "sendmail_path" nel mio php.ini, ma questo sembrava interrompere qualcosa, dal momento che la posta improvvisamente ha smesso di spedire dal server. Più specificamente, ho cambiato la riga in --- sendmail_path = / usr / sbin / sendmail -t -i -r mail@mydomain.com, ma non ha ancora funzionato (ho provato con e senza virgolette, e ho anche fatto sicuro di riavviare il server, ma nessun dado, e non sono sicuro di cosa gli stesse impedendo di poter inviare e-mail dopo quel punto).
Zero Wing

3

Guardando la tua configurazione sembra che manchino un paio di bit (e mi dispiace per la mia sintassi, non pubblico spesso):

Probabilmente vorrai aggiungere l'opzione di configurazione MASQUERADE_DOMAIN per andare con MASQUERADE_AS, facendo corrispondere MASQUERADE_DOMAIN a qualunque sia il nome FQDN dell'host (nome host -f sulla maggior parte delle piattaforme Linux). L'ho fatto fare cose strane se non fossero entrambe lì, quindi sarebbe:

MASQUERADE_AS(`mydomain.com')dnl
MASQUERADE_DOMAIN(`fqdnname.internal')dnl

e poi questa linea:

dnl define(`confDOMAIN_NAME', `mydomain.com')dnl

Dovrebbe essere davvero

define(`confDOMAIN_NAME', `mydomain.com')dnl

oppure verrà ignorato dai comandi make / hash quando si aggiorna il file sendmail.cf. Questo ragazzo dà una grande spiegazione del perché Qual è la differenza tra "dnl" e "dnl #" in un file sendmail.mc?

Sto ancora cercando di liberarmi della parte "apache" nel mio server, ma spero che questo ti avvicini un po '!


1

Sistema -> Configurazione -> Avanzate -> Sistema -> Imposta percorso di ritorno -> Sì

o impostalo sull'e-mail che desideri utilizzare. Ho appena trovato questo oggi - apparentemente alcune delle e-mail venivano rifiutate dai server di posta con regole rigide (.edu, .gov ... ecc.)


Ore sprecate nel tentativo di capire il motivo per cui i nostri record SPF venivano ignorati e le e-mail venivano ancora contrassegnate come contraffatte quando inviate dal nostro sito a noi. Ho avuto la sensazione che fosse l'intestazione Received-From che mi ha portato qui. La tua soluzione di 30 secondi ha funzionato all'istante e ha messo fine alle ore di frustrazione! La soluzione più semplice per questo problema e Magento in questa pagina. Consiglia di provare questo prima di modificare la configurazione del server.
Ashley Swatton,

Consiglio di disattivare completamente il servizio di posta elettronica basato su server e di utilizzare semplicemente il plug-in Sparkpost + smtpPro. Funziona come un fascino con 100.000 e-mail / mese gratis.
Kalvin Klien,

1

Aggiungi define(`confRECEIVED_HEADER', `internal info removed')dnlper submit.mcquindi generare il .cffile e riavviare sendmailcome al solito.

Importante: il file che dovrebbe essere modificato affinché questo funzioni è submit.mc, e NON sendmail.mc. Se sendmail.mcinvece modifichi il file, l' Receivedintestazione sopra quella che hai citato sarà quella modificata (cioè Received: from mydomain.com (www.mydomain.com [127.0.0.1])).

Nota: al posto della stringa letterale internal info removedè possibile riutilizzare alcune delle informazioni fornite nascondendo quella sensibile, ad esempio: by $j id $i; $bper ottenere by DOMAIN id ID; TIMESTAMP.

Quanto sopra rimuoverà / sostituirà le informazioni dopo l' Receivedintestazione che hai citato:

Received: (from apache@localhost) <----------- THIS IS WHAT I'M TRYING TO CHANGE
by mydomain.com (8.14.4/8.14.4/Submit) id fkdjfljlfsra39393;
Fri, 3 Apr 2015 15:35:01 GMT

Vedi anche una domanda simile: Come rimuovere Received: (da apache @ localhost) e la versione di sendmail dalle intestazioni

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.