[solved] MTA saját domain nem saját

Web, mail, IRC, IM, hálózatok

Olykor összefutok a köv. problémával:

egy levelezõ szerveren be van állítva olyan saját (lokális kezelésũ) email domain, amit valaha tényleg az az MTA kezelt, de mostmár máshová mutat az adott domain MX-e, tehát értelmezésem szerint az MTA nem jogosult fogadni az oda érkezõ emaileket. úgy legalábbis biztos, nem, hogy a helyi postaládába lementi, vagy 5xx hibával visszadobja amennyiben a nevezett email fiók nem létezik helyben.
ezek a hibák azoknál jönnek elõ, akik SMTP-ként is használják a levelezõ szervert.

különbözõ férc workaroundokkal próbálkoztam: idõnként végignézi egy script az összes konfigurált virtual domaint és törli/megflaggeli ha a DNS... stb.
nem igazán járható út.

az érdekel, exim4 és postfix-hez nincs-e valami beépített opció, ami helyi email doimaineknél is ellenõrzni az MX-et?

rendszerszerũ megoldásra van szükségem. tehát nem opció, hogy odabattyogok és kézzel kitörlöm a domaint amikor panasz van, mert lehet h addig rossz helyre mentek az emailek és a user nem kap semmilyen visszajelzést.

  • 4708 megtekintés

( andrej_ v | 2014. 05. 01., cs – 11:06 )

Ha már nem ő az MX, akkor töröld a domaint és rendben meg fogja találni a valódit.

valami rendszerszerũ megoldást keresek, mert még ha ritkán is fordul elõ, nem akarok mindig kézzel beavatkozni, amikor a gép is képes rá. most törlöm azt az 1 domaint, holnap lehet h 2 ilyen lesz vagy egy se, vagy ki tudja... csinálja csak a robot a robot melót.

~~~~~~~~
deb http://deb.metaltux.tk/ wheezy yazzy repack

Hat ha hajlando vagy limitalni az ugyfeled lehetosegeit, akkor egesz egyszeruen meg tudod scriptelni, pl igy: 

#!/bin/bash

dig mx +short $1 | awk ' { print $2 } ' | sort >/tmp/$$
diff -q /tmp/$$ /var/lib/mxreference
if [ $? -eq 1 ]; then
	echo "Kulonbozik"
fi

Ezek utan lemented az eredmenyt es ha mondjuk egy hetig nem all vissza, kuldesz egy mailt az ugyfelnek, ha ket hetig, torlod a domaint. Ennel korabban nem erdemes torolni, mert migracional kellhet az, hogy meg egy darabig fusson a cucc.

hasonló megoldással próbálkoztam és egy bug miatt egyszer minden virtual domaint inaktivált a csodaszkriptem. ezért is nem szeretnek 3rd party toollal szerencsétlenkedni.
figyelni kell arra hogy kapok-e vissza választ, elérhetõ-e a dns szolgáltatás, nincs-e több MX rekord megadva, stb. az MTA-be ezek az ellenõrzések mind be vannak építve, csak ki kéne tudni csalni a megfelelõ fázisban.

~~~~~~~~
deb http://deb.metaltux.tk/ wheezy yazzy repack

Akkor van megoldas, meghozza az, hogy szeparalod a kuldo es a fogado oldalt. Anno par eve epitettem egy levelezo rendszert, ami a maga idejeben eleg sikeresen mukodott is. A megoldas hatranya az, hogy ha nem mukodik a nevfeloldasod, szerveren belul sem tudsz levelet kuldeni. Az architektura igy nez ki: 


 +--------+  +----------------------+ +--------+
 | Ugyfel |  |      Internet        | | Ugyfel |
 +--------+  +----------------------+ +--------+
     |            ↑            |           ↑
 [ kuldes ]  [ kuldes ]   [ fogadas ] [ fogadas ]
     ↓            |            ↓           |
 +----------------------+ +--------------------+
 | smtp.szolgaltato.com | | mx.szolgaltato.com |
 +----------------------+ +--------------------+

Magyaran szolva az ugyfeltol jovo "submission" leveleket mindenkeppen DNS lookuppal routolod. Picit trukkos osszehozni, de Eximmel egyaltalan nem problema. Az anno epitett infrastruktura termeszetesen ennel komplexebb volt, tobb tucat mailszerver passzolgatta egymasnak a leveleket, de ha jol emlekszem egyaltalan nem volt vele komoly gond es eleg jol skalazodott is.

( Mico v | 2014. 05. 01., cs – 11:14 )

válaszd szét a kétféle smtp szolgáltatást

( Chas | 2014. 05. 01., cs – 13:04 )

Itt szerintem csak a domain törlése fog segíteni, mivel az smtp szerver először ellenőrzi a saját virtuális domain tábláját, és ha talál olyan domaint helyben, akkor oda fogja dobni. Őszintén szólva nem is értem, hogy ha már nem te kezeled a domaint, akkor miért van még mindig virtual domain hozzá a szerveren.

tisztába vagyok ezzel a default mechanizmussal, de talán annyira nincs kõbe vésve, hogy opciókkal, konfigurálással ne lehetne raja változtatni.

miért van még mindig virtual domain hozzá a szerveren

egyszerũ: ottmaradt.
valaha fel lett véve, mert en kezeltem, aztán a tulaj elvitte.

~~~~~~~~
deb http://deb.metaltux.tk/ wheezy yazzy repack

( pepelopez | 2014. 05. 02., p – 09:47 )

én perl scripetel oldottam meg

accept
local_parts = *
hosts = !127.0.0.1:*
condition = ${if eq{${perl{checkMx}{$domain}}}{$domain}}
endpass

ha van a szerverre mutató domain akkor elfogadja ha nincs akkor nem

perl script zanzásítva:

use Socket;
use Net::DNS;

my $dns = Net::DNS::Resolver->new(nameservers => [qw(127.0.0.1)]);

sub checkMx
{
my @params = @_;
for my $domain( $params[0] ) {
my $mx = $dns->query( $domain, 'MX' );
if (defined $mx)
{
foreach my $rr ($mx->answer)
{
if ($rr->exchange eq 'az.en.hostom.neve')
{
return $domain;
}
}
}
}
return "no";
}

Te jó atya gatya. Esetleg nyílt lángot nem akarsz használni a nyitott benzines hordó mellett?
Amit a fenti script, és az egész bohóckodás megvalósít az nem az amit a kérdező szeretne. Ő nem a relay-t kívánja kívánja megszüntetni, hanem ő a hibásan felkonfigurált levelező kiszolgáló architekturájában akadt bele egy olyan problémába, hogy ha a domain-t elviszik tőle, de ő erről nem tud, akkor erre a domainre induló e-mailokat a mail szervere továbbra is elfogadja azoktól az ügyfelektől akik számára még ő az SMTP szolgáltató.
Erre nincs jó scriptelhető megoldás mivel a hiba abban van, hogy lokális felhasználói vannak és local domain az adott cél.
Amit te fent megvalósítasz az katasztrofális végeredménnyel zárulhat. Egyrészt a legtöbb (postfix, sendmail) MTA a fent megjelölt relay_check szolgáltatást integrálja. (relay_backup_mx,permit_backup_mx/bocs fejből nem emléxem pontosan lehet hogy rosszak a kulcsszavak/)
De mi történik akkor ha a csúnya spammer fogja magát és az mx-ét rád állítja?
Nem ide tartozik, de talán a fenti scriptet fel tudja okosítani: postfix rendelkezik szűrővel is a fenti konfig opcióra amivel megadható hogy a másik mx-nek milyen networkben kell lenni ahhoz hogy relay-ezen mx rekord esetén.
A kezdeti kérdezőnek: áttervezni a levelező kiszolgáló architektúrát, előtte sokat olvasni, tanulni, majd azután belefogni szolgáltatásba. Addig pedig az ügyfeleknek kiírni weblapra: (T) azaz tanulóvezető. Lehet offenznek veszed, és bunkóságnak, de a jelenlegi tudással csak azok számát növeled akiknek ilyen szolgáltatásba bele se kellett volna fogniuk. Hiba mindenhol van, de itt az alapokkal van gond.

sokat olvasni, tanulni

köszönöm, ez lett a megoldás :)

tanulmányoztam az exim-et és mostmár nem probléma ez a probléma.
ACL-ben egy 


domain = @mx_any/ignore=127.0.0.0/8

condition-nel tudom ellenőrizni, hogy dns szerint én vagyok-e az címzett MX szervere.
Néhány mas ellenőrzés mellett ez a legényegesebb sor, amivel a témaindító probláma megoldható.

Más kérdés, hogy ha NAT-olva kapcsolódik az internetre a szerver jószág, akkor az @mx_any nem fog tejlesülni a gép külső IP címére. Erre én is egy szkriptet pakoltam össze, hogy a külső címet is keresse a domain MX és SRV rekordjaiban.

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack