Am 27.06.2010 22:12, schrieb Christopher Stolzenberg:

Am 27. Juni 2010 20:30 schrieb Ralf Hildebrandt Ralf.Hildebrandt@charite.de:

...

...

smtpd_recipient_restrictions = reject_unverified_recipient

Da wird es IMMER gemacht

Also soll man das so nicht machen? Wenn ein Spammer die Empfängeradresse fälscht

machen die immer bzw das ist keine Faelschung sondern die wollen dir dann halt spam zustellen

würde mein Postfix ungewollt an anderen

Servern Anfragen machen ob es den Empfänger gibt?

ja aber das kann ja gewollt so sein, typischer fall du betreibst ein antispamrelay mit postfix ( spamasassin etc ) dabei ist es sinnvollerweise zwingend notwendig die existierenden mail adressen der domains zu kennen ( um zb mit unknown recipient antworten zu koennen) , wenn du aber keine statischen listen dieser mailadressen pflegen willst/kannst fragst du halt am mailserver der die mailboxen haelt nach, per smtp, ob die adressen existieren ist dies nicht der Fall kann dein antispamrelay den spammer abweisen ( noch bevor die mail angenommen wird ) wenn der eigentliche mailserver dann auch noch nur ueber das antispamrelay versendet wird der eigentliche mailserver weitgehenst "versteckt" und muss keine filter Last tragen, das Ergebnis solcher abfragen kann man cachen, bleibt das grundsaetzliche Problem dass man immer schneller Fragen als antworten kann, das heisst es kann das Problem entstehen das auch in diesem gewollten scenario das antispamgate den eigentlichen mailserver mit nachfragen ueberflutet ( weil es eben selbst so haeufig gefragt wird, oder es kommen falsche Ergebnise etc ), durch caching wird das gemildert, diese verfahren ist aber relativ sicher wenn eine gut und stabile schnelle Netzwerkverbindung ( selbes Netz/Rechenzentrum etc ) zwischen relay und eigentlichem mailserver existiert, haeufige Methode auch bei backup mx servern , oder postfixantisapmrelays fuer exchange etc, man kann das Problem aber acuh mit Anfragen ueber ander serives loesen zb ldap Anfragen an die active dir etc

was man def nur in absoluten Ausnahmefaellen machen sollte ist ein sender verify weil dies taetsaechlich bei spam durch fake fast immer zur belaestigung dritter geht was dann haeufig zum blacklisting fuehrt

thx

Chris _______________________________________________ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users

reject_unverified_recipient Reject the request when mail to the RCPT TO address is known to bounce, or when the recipient address destination is not reachable. Address verification information is managed by the verify(8) server; see the ADDRESS_VERIFICATION_README file for details. The unverified_recipient_reject_code parameter specifies the numerical response code when an address is known to bounce (default: 450, change into 550 when you are confident that it is safe to do so). The unverified_recipient_defer_code parameter specifies the numerical response code when an address probe failed due to a temporary problem (default: 450). The unverified_recipient_tempfail_action parameter specifies the action after addres probe failure due to a temporary problem (default: defer_if_permit). This feature is available in Postfix 2.1 and later.

http://www.postfix.org/ADDRESS_VERIFICATION_README.html

--- WARNING

Recipient address verification may cause an increased load on down-stream servers in the case of a dictionary attack or a flood of backscatter bounces. Sender address verification may cause your site to be blacklisted by some providers. See also the "Limitations" section below for more.

On Behalf Of Christopher Stolzenberg

Hi,

danke. Das leuchtet mir ein.

Also darf ich reject_unverified_recipient nur auf die Domains anwenden für die mein Postfix zuständig ist? Meine relay_domains?

RTFM

Lt DNS kommen eh nur diese Adressen zu dir. Steht ein anderer Domainanteil im to wie die für du zuständig bist und du würdest die annehmen und transportieren dann wärst du ein offenes Relay.

Wenn ein Spammer das machen würde:

MAIL FROM: xyz@spammer.com und RCPT TO: test@example.net

würde mein Postfix Server bei dem Mailserver von example.net überprüfen ob es die Adresse test@example.net gibt?

Wenn du für example.net zuständig bist, im DNS als MX eingetragen dann ja andernfalls würdest du diese Mail nie sehen.

Obwohl ich mit der Domain example.net gar nichts zu tun habe?

NEIN dann nicht (Ausnahme wäre relayversuche die aber anders abgefangen werden)

Ich habe gedacht das reject_unverified_recipient wendet Postfix nur auf die relay_domains an? Also muss ich es mit smtpd_recipient_restrictions = check_recipient_access machen weil ich ja nur die relay_domains die

Nö check_recipient_access type:table Search the specified access(5) database for the resolved RCPT TO address, domain, parent domains, or localpart@, and execute the corresponding action

der Firma gehören überprüfen will.

reject_unverified_recipient Reject the request when mail to the RCPT TO address is known to bounce, or when the recipient address destination is not reachable. Address verification information is managed by the verify(8) server; see the ADDRESS_VERIFICATION_README file for details.

The unverified_recipient_reject_code parameter specifies the numerical response code when an address is known to bounce (default: 450, change into 550 when you are confident that it is safe to do so). The unverified_recipient_defer_code parameter specifies the numerical response code when an address probe failed due to a temporary problem (default: 450). The unverified_recipient_tempfail_action parameter specifies the action after addres probe failure due to a temporary problem (default: defer_if_permit). This feature is available in Postfix 2.1 and later. Other restrictions that are valid in this context:

Generic restrictions that can be used in any SMTP command context, described under smtpd_client_restrictions. SMTP command specific restrictions described under smtpd_client_restrictions, smtpd_helo_restrictions and smtpd_sender_restrictions. Example:

smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination smtpd_reject_unlisted_recipient (default: yes) Request that the Postfix SMTP server rejects mail for unknown recipient addresses, even when no explicit reject_unlisted_recipient access restriction is specified. This prevents the Postfix queue from filling up with undeliverable MAILER-DAEMON messages.

An address is always considered "known" when it matches a virtual(5) alias or a canonical(5) mapping.

The recipient domain matches $mydestination, $inet_interfaces or $proxy_interfaces, but the recipient is not listed in $local_recipient_maps, and $local_recipient_maps is not null. The recipient domain matches $virtual_alias_domains but the recipient is not listed in $virtual_alias_maps. The recipient domain matches $virtual_mailbox_domains but the recipient is not listed in $virtual_mailbox_maps, and $virtual_mailbox_maps is not null. The recipient domain matches $relay_domains but the recipient is not listed in $relay_recipient_maps, and $relay_recipient_maps is not null. This feature is available in Postfix 2.1 and later.

Mit freundlichen Grüßen

Drießen

Am 28. Juni 2010 08:25 schrieb Robert Schetterer robert@schetterer.org:

das kommt darauf an wo die regel steht an sich sollte er schon deswegen ablehnen wenn dein server nicht fuer diese zustaendig ist ( zb weil nicht in relay_domains enthalten etc ) wenn dein mailserver auch die mailboxen haelt reicht ein zb auch reject_unlisted_recipient, dann kannst du recipient verify ganz vergessen

...

Ich habe gedacht das reject_unverified_recipient wendet Postfix nur auf die relay_domains an?

an sich recipient verify ist ein zusaetzlicher check, meines wissens, wenn eine domain nicht in deiner zb relay_domains etc steht dann weiss dein mailserver ohnehin dass er nicht zustaendig ist , zusaetzlich ein verify ist ueberfluessig, die kombi macht keinen Sinn

...

Also muss ich es mit smtpd_recipient_restrictions = check_recipient_access

nur wenn du statisch noch zusaetzliche regeln benutzen willst an sich sollte sowas ausreichen

smtpd_recipient_restrictions = reject_unknown_recipient_domain,                               reject_non_fqdn_recipient,                               permit_mynetworks,                               permit_sasl_authenticated, ... reject_unlisted_recipient, reject_unauth_destination

Hi Robert,

folgendes ist dann aber seltsam bzw. ich verstehe es nicht...

Wenn ich es so mache wie von dir erwähnt kriege ich immer ein relay access denied wenn man im SMTP Dialog eine falsche Empfängeradresse angibt.

Das soll ja auch so sein weil ich kein offenes Relay bin.

Aber das merkwürdige ist dieses hier: (Bug?)

Mal angenommen ich bin für die Domains firma.de und firma.com zuständig. Ein Spammer versucht z.B. zu testen ob er über meinen Server relayen kann und macht als Absender xyz@example.com und als Emfpänger xyz@googlemail.com.

Sobald ich reject_unverified_recipient benutze baut Postfix zum eingehenden Mailserver von googlemail.com eine Verbindung auf, stellt fest die Mailadresse ist zustellbar und gibt dem potenziellen Spammer trotzdem mit 7 Sekunden Verzögerung ein relay access denied.

Genau das verstehe ich nicht. Warum baut er überhaupt unnötig die Verbindung auf?

Hat jemand von euch die Möglichkeit das mal selbst auszuprobieren?

Chris

Am 28. Juni 2010 12:50 schrieb Gregor Hermens gregor.hermens@a-mazing.de:

Hallo Chris,

Am Montag, 28. Juni 2010 schrieb Christopher Stolzenberg:

...

folgendes ist dann aber seltsam bzw. ich verstehe es nicht...

Wenn ich es so mache wie von dir erwähnt kriege ich immer ein relay access denied wenn man im SMTP Dialog eine falsche Empfängeradresse angibt.

Das soll ja auch so sein weil ich kein offenes Relay bin.

Aber das merkwürdige ist dieses hier: (Bug?)

Mal angenommen ich bin für die Domains firma.de und firma.com zuständig. Ein Spammer versucht z.B. zu testen ob er über meinen Server relayen kann und macht als Absender xyz@example.com und als Emfpänger xyz@googlemail.com.

Sobald ich reject_unverified_recipient benutze baut Postfix zum eingehenden Mailserver von googlemail.com eine Verbindung auf, stellt fest die Mailadresse ist zustellbar und gibt dem potenziellen Spammer trotzdem mit 7 Sekunden Verzögerung ein relay access denied.

Genau das verstehe ich nicht. Warum baut er überhaupt unnötig die Verbindung auf?

Hat jemand von euch die Möglichkeit das mal selbst auszuprobieren?

mit ziemlicher Sicherheit haben in deiner Konfiguration die einzelnen Prüfungen die falsche Reihenfolge. Für Mails an @googlemail.com ist dein Server schlicht nicht zuständig (außer der Client hat sich authentifiziert), also sollte Postfix das als erstes überprüfen...

Zeig bitte mal deine vollständige Konfiguration (Ausgabe von postconf -n).

Gruß, Gregor --     @mazing           fon +49 8142 6528665  Gregor Hermens       fax +49 8142 6528669 Brucker Strasse 12  gregor.hermens@a-mazing.de D-82216 Gernlinden    http://www.a-mazing.de/ _______________________________________________ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users

Okay hier die smtpd_recipient_restrictions:

smtpd_recipient_restrictions = reject_unknown_recipient_domain, reject_unknown_sender_domain, reject_non_fqdn_recipient, reject_non_fqdn_sender, permit_mynetworks, permit_sasl_authenticated, reject_unverified_recipient, # check_recipient_access hash:/etc/postfix/verify_domains, reject_invalid_hostname, reject_non_fqdn_hostname, reject_unknown_reverse_client_hostname, reject_unauth_destination, reject_unauth_pipelining, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_rbl_client ix.dnsbl.manitu.net, reject_rbl_client zen.spamhaus.org

Chris

Am 28. Juni 2010 16:04 schrieb Gregor Hermens gregor.hermens@a-mazing.de:

Bei dir kommt reject_unverified_recipient vor reject_unauth_destination. Dadurch kommt es zu dem oben beschriebenen Verhalten.

Du solltest alles, was nach permit_sasl_authenticated kommt, von billig nach teuer sortieren. reject_unverified_recipient ist wohl die teuerste Regel in der ganzen Liste. Mein Vorschlag:

smtpd_recipient_restrictions =        reject_unknown_recipient_domain,        reject_unknown_sender_domain,        reject_non_fqdn_recipient,        reject_non_fqdn_sender,        permit_mynetworks,        permit_sasl_authenticated,        reject_unauth_destination,        reject_invalid_hostname,        reject_non_fqdn_hostname,        reject_unknown_reverse_client_hostname,        reject_invalid_helo_hostname,        reject_non_fqdn_helo_hostname,        reject_unauth_pipelining,        reject_rbl_client zen.spamhaus.org        reject_rbl_client ix.dnsbl.manitu.net,        reject_unverified_recipient, #      check_recipient_access hash:/etc/postfix/verify_domains,

Hi Gregor,

danke :) Damit ist das Problem gelöst.

Noch etwas in dem Zusammenhang: Mit address_verify_map kann Postfix doch die gültigen Adressen cachen? Aktualisiert sich das automatisch? Beispiel xyz@firma.com gibt es (noch) nicht. im Verify Cache befindet sich xyz@firma.com als ungültig. Damit würde Postfix die Adresse dann abweisen ohne nochmal beim anderen Mailserver zu fragen... Reinigt sich dieser address_verify_map Cache automatisch?

Danke

Chris

Am 28. Juni 2010 18:25 schrieb Gregor Hermens gregor.hermens@a-mazing.de:

http://www.postfix.org/ADDRESS_VERIFICATION_README.html#caching

erklärt die Details und was sich bei den einzelnen Postfix-Versionen geändert hat...

Hi Gregor,

okay Debian hat noch Postfix Version 2.5.5.

"The verify(8) daemon will periodically remove expired entries from the address verification database, and log the number of entries retained and dropped (Postfix versions 2.7 and later)."

Darf man das so verstehen das Postfix erst ab Version 2.7 die Datenbank automatisch aufräumt? Oder bezieht sich Postfix 2.7 nur aufs logging?

http://www.postfix.org/verify.8.html

Dort kann man ja auch festlegen, dass nur Adressen die es auch tatsächlich gibt gecached werden? z.B. mit:

main.cf

address_verify_negative_cache = no

Dann hätte ich das Problem umgegangen?

Chris