Re: Filterregeln für de-mail.de am Border-MX

[Carsten]

Hey Andreas,

vielen Dank für die ausführliche Darstellung.


>
> Und genau da wird's häßlich: Übliche Mailsysteme transportieren keine Nachrichten,
> wenn zur Absender/Empfängerdomain kein A/MX Lookup existiert.
Das ist natürlich ein guter Grund. Das fällt bei uns nicht weiter ins 
Gewicht, da nur die Border-MX das prüfen.
Interne Server nutzen nur ihr Default-Relay. Aber das kann ich 
nachvollziehen.

> Allerdings hat die epost das ganze cleverer gelöst, als demail:
>
> 554 5.7.1 <foobar at deutschepost.epost.de>: Recipient address rejected: Bei der von Ihnen eingegebenen Adresse handelt es sich um keine E-Mail sondern um eine E-Postbrief Adresse, ein Service der Deutschen Post. Deshalb kann eine Uebermittlung der Nachricht als E-Mail nicht erfolgen. Sollten Sie noch keine E-Postbrief Adresse haben, registrieren Sie sich jetzt kostenlos unter http://epost.de, um auch im Internet verbindlich, vertraulich und verlaesslich kommunizieren zu koennen.
> quit
Das macht echt mehr Sinn. Sowas hätte ich mir für de-mail auch gewünscht.

> Bei De-mail ist sowas wohl nicht imlementierbar - gesetzliche Regelungen sprechen angeblich dagegen.
>
> So versumpft eine Nachricht an demail in der Queue und wird erst nach mehreren Tagen mit einer falschen Fehlermeldung
> zurückgeschickt. Bis dahin hat der Anwender/Versender keine Chance, seinen Fehler zu bemerken. Schlechtes Design ...
Daher meine Idee, das an meinen Border-MX gar nicht ins Internet zu 
relayen und direkt nach innen zu bouncen.

>
> Aus diesem Grund empfiehlt es sich, an 2 Seiten zu filtern.
> 1. am MX
>     hier dürfen keine Absenderadressen epost/demail auftauchen
> 2. am Submission Server
>     hier sollten weder Absender noch Empfänger epost/demail lauten, wenn man keine Gateway-Lösungen betreibt.
Eine Gateway-Lösung ist geplant, jedoch stimme ich ausdrücklich dafür 
diese zwei Welten zu trennen, sprich schon an der Quelle (Submission) 
nicht in die Standard-SMTP-Mailrouting-Umgebung zu routen (die per 
default ins Internet zeigt), sondern hier schon auf eine dedizierte, 
autake de-mail Infrastruktur zu setzen, d.h. das Geschäftskunden-Gateway 
direkt anspricht.


>
> also z.B.
>    smtpd_recipient_restriction =
>      ...
>      check_sender_access hash:/path/to/reject_epost+demail
>      check_recipient_access hash:/path/to/reject_epost+demail
>      ...
>
>    /path/to/reject_epost+demail:
>      epost.de        REJECT $sprechende Fehlermeldung
>      .epost.de       REJECT $sprechende Fehlermeldung
>      fp-demail.de    REJECT $sprechende Fehlermeldung
>      .fp-demail.de   REJECT $sprechende Fehlermeldung
>      de-mail.de      REJECT $sprechende Fehlermeldung
>      .de-mail.de     REJECT $sprechende Fehlermeldung
>      mc-demail.de    REJECT $sprechende Fehlermeldung
>      .mc-demail.de   REJECT $sprechende Fehlermeldung
Sehr gut. Das hatte ich mir auch so gedacht. Denn in der 
Standard-SMTP-Welt (die ja bei mir entkoppelt wird vom 
Geschätskunden-Gateway) dürfte ja niemals eine echte de-mail 
ankommen/geroutet werden.
> Bei Epost ist in der Tat nur eine Domain und Subdomain betroffen.
> demail ist konzeptionell nicht auf eine Domain beschränkt. Die Liste ist aber nicht sonderlich dynamisch...
>
>
Bei de-mail werden doch Subdomains der Art "foobar.de-mail.de" und 
"beispielkunde.de-mail.de" verwendet, oder nicht?
Woher stammen denn "fp-demail.de" und "mc-demail.de"?
Meist Du hier nicht eher Subdomains, anstatt echte second-level Domains ?


Beste Grüße
Carsten