Backscatter problem

[perlitz]

Hallo,

mein Server ist auf eimal scheints unter die "Backscatterer" gegangen. Leider will es mir nicht gelingen dieses zu unterbinden.

So langsam bin ich echt ratlos und kann mir das auch nicht erklären. Es ist ein Debian Lenny in grossen Teilen ähnlich aufgebaut wie unter The Perfect Server - Debian Lenny (Debian 5.0) [ISPConfig 2] beschrieben.

Abweichend ist hier die nutzung von Confixx und der Postfix ist von der Config auch leicht angepasst.

Ansich sollte hier meiner Meinung nach die Config ein Backscatter ausschliessen, dem ist leider nicht so.

Was habe ich übersehen?

postconf -n

Code: Select all

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
inet_interfaces = all
inet_protocols = all
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
message_size_limit = 50000000
mydestination = meinmailserver.de, localhost.meinmailserver.de, localhost.localdomain, localhost
myhostname = meinmailserver.de
mynetworks = 127.0.0.0/8
myorigin = /etc/mailname
recipient_delimiter = +
relayhost =
smtp_tls_note_starttls_offer = yes
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache
smtp_use_tls = yes
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unknown_reverse_client_hostname, permit
smtpd_data_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_pipelining, permit
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, permit
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, reject_unknown_recipient_domain, reject_unknown_sender_domain, reject_unverified_recipient, reject_non_fqdn_recipient, reject_non_fqdn_sender, reject_invalid_hostname, reject_unlisted_recipient, check_recipient_access pcre:/etc/postfix/recipient_checks.pcre
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain =
smtpd_sasl_security_options = noanonymous
smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_sender, reject_unknown_sender_domain,  permit
smtpd_tls_CAfile = /etc/postfix/ssl/cacert.pem
smtpd_tls_auth_only = no
smtpd_tls_cert_file = /etc/postfix/ssl/smtpd.crt
smtpd_tls_key_file = /etc/postfix/ssl/smtpd.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
tls_random_source = dev:/dev/urandom
unknown_local_recipient_reject_code = 550
unverified_recipient_reject_code = 550
unverified_sender_reject_code = 550

[Roger Wilco]

Wie sieht eine solche Backscatter-Mail bei dir aus? Wie sieht der korrespondierende Logeintrag zu einer solchen E-Mail aus?

[perlitz]

Hallo,

nun ist zumindest klar was passiert 8O , es sind weitergeleitete E-Mail Konten von Kunden.

Sprich ein Kunde hat die Domain xyz.de und richtet über confixx ein catchall mit weiterleitung an seine t-online E-Mail adr. ein. Nun akzeptiert mein Server eine E-Mail und leitet diese an den T-Online Mailserver weiter. Dieser stuft die E-Mail als Spam / Virus ein und macht ein reject.

Richtig blöd ist, das ich daraus jetzt natürlich ein bounce mache :roll:

Wie kann ich das verhindern?

Code: Select all

8807:Mar 20 08:22:12 mainmailserver postfix/smtpd[1434]: 57FD9354011: client=unknown[187.5.231.134]

8811:Mar 20 08:22:14 mainmailserver postfix/cleanup[1391]: 57FD9354011: message-id=<20100320072212.57FD9354011@mainmailserver.de>

8812:Mar 20 08:22:14 mainmailserver postfix/qmgr[13184]: 57FD9354011: from=<upihy8110@brasiltelecom.net.br>, size=8957, nrcpt=1 (queue active)

8813:Mar 20 08:22:14 mainmailserver postfix/smtp[1594]: 57FD9354011: to=<xyz@t-online.de>, orig_to=<marypatcddevw@xyz.de>, relay=mx00.t-online.de[194.25.134.8]:25, delay=2.8, delays=2.6/0/0.06/0.13, dsn=5.7.0, status=bounced (host mx00.t-online.de[194.25.134.8] said: 550-5.7.0 Message considered as spam or virus, rejected 550-5.7.0 Message rejected because it was considered as spam. If you feel this 550-5.7.0 to be an error, please forward the wrong classified e-mail to our 550-5.7.0 abuse department at FPR@RX.T-ONLINE.DE with all the header lines! 550-5.7.0 We will analyse the problem and solve it. We are sorry for any 550-5.7.0 inconvenience and thank you very much in advance for your support! 550-5.7.0   550-5.7.0 Die Annahme Ihrer Nachricht wurde abgelehnt, da sie als Spam 550-5.7.0 eingestuft wurde. Sollten Sie dies als Fehler ansehen, bitten wir 550-5.7.0 Sie darum, die E-Mail mit allen Kopfzeilen an FPR@RX.T-ONLINE.DE 550-5.7.0 weiterzuleiten. Das Problem wird dann untersucht und geloest. 550-5.7.0 Wir bedauern, Ihnen Unbequemlichkeiten bereitet zu haben, und 550 5.7.0 bedanken uns vorab fuer Ihre freundliche Unterstuetzung! (in reply to end of DATA command))

8815:Mar 20 08:22:14 mainmailserver postfix/bounce[1595]: 57FD9354011: sender non-delivery notification: D7C75354013

8817:Mar 20 08:22:14 mainmailserver postfix/qmgr[13184]: 57FD9354011: removed

[Roger Wilco]

Richtig blöd ist, das ich daraus jetzt natürlich ein bounce mache :roll:

Wie kann ich das verhindern?

Schoen oder gar RFC-konform kannst du das nicht verhindern. Du nimmst die E-Mail an und wenn du sie nicht zustellen kannst, musst du eben eine DSN generieren und an den (vermeintlichen) Absender schicken.

Die schoenste Loesung waere es, dem Benutzer den Catchall auszureden und ausserdem moeglichst viele Spam-Mails schon vor der Annahme durch deinen MTA abweisen zu lassen (policyd-weight, postgrey, spamass-milter...).

Die Brachialmethode waere, den Service 'bounce' aus deiner master.cf zu loeschen bzw. auszukommentieren. Damit generiert dein Postfix aber gar keine Bounces mehr. Das will man also auch nicht.

[lobordan]

Hallo,

mit genau dem gleichen Problem schlage ich mich auch gerade herum. Ich will demnächst einen neuen (Mail)Server mit Postfix aufsetzen und frage mich, wie man diesen Backscatter von weitergeleiteten Mails verhindern kann. Eine Lösung ist natürlich, auf Weiterleitungen zu verzichten und statt dessen richtige Boxen einzurichten und diese u.u. sogar mit einem Pop-Sammeldienst des ursprünglichen Zielkontos einzusammeln. Das ist aber leider ein Workaround, bei dem der "Kunde" mitspielen muss. Ein generelles Verbot von Weiterleitungen ist sicherlich nicht unproblematisch zu kommunizieren.

Eine serverseitige Lösung wäre meines Erachtens, wenn Postfix die Mail erst quittieren würde, wenn sie erfolgreich an den "wahren" Empfänger zugestellt werden konnte. Das würde natürlich bedeuten, dass die Verbindung potentiell etwas länger offen bleiben müsste, aber das wäre evtl. noch verkraftbar? Hat jemand eine Idee ob sich mit Postfix soetwas umsetzen lassen würde? Ich fange leider gerade erst an, mich mit Postfix zu beschäftigen und weiß daher nicht so recht, wie man das angehen könnte. Im Netz habe ich auch noch nichts dazu gefunden :(

[Roger Wilco]

http://www.postfix.org/ADDRESS_VERIFICA ... #recipient

[EdRoxter]

Was mir noch unklar ist: Wie genau probiert Postfix' verify die Mailadresse?

Wenn ich das richtig sehe, wird bei T-Offline nach der DATA-Übermittlung, aber noch während die SMTP-Session offen ist, unmittelbar ein Body- oder zumindest Header-Check durchgeführt und im Falle einer Spammail mit 450 oder 550 quittiert.

Ich gehe aber nicht davon aus, dass Postfix mehr als ein RCPT TO probiert, was ja bei einer gültigen Empfängeradresse (und davon gehe ich hier aus) nicht den gewünschten Erfolg bringt - oder sehe ich das falsch?

[Roger Wilco]

Ich gehe aber nicht davon aus, dass Postfix mehr als ein RCPT TO probiert, was ja bei einer gültigen Empfängeradresse (und davon gehe ich hier aus) nicht den gewünschten Erfolg bringt - oder sehe ich das falsch?

Du hast Recht. In diesem Fall bringt die Empfängerverifizierung nichts. Postfix spielt den SMTP-Dialog mit dem Zielserver nur bis zur Recipient Stage (also dem RCPT TO) durch.