[postfix-users] message size problem
Hallo allerseits
Ich bins nochmal. Zur Erinnerung schildere ich nochmal mein Problem. Ein Kunde von uns möchte mails bis 20mb verschicken. Also habe ich den Wert entsprechend in meiner main.cf angepasst und zwar auf: message_size_limit = 26214400 (25mb einfach um sicher zu gehen...) und den dienst entsprechend neu gestartet.
Verschicke ich nun ein Mail mit einem ca. 19mb grossen anhang erhalte ich folgende Fehlermeldung: Unfortunately, I was unable to deliver your mail. The error given was:
552 5.2.3 Message exceeds maximum fixed size (20000000)
You may need to contact your e-mail administrator to solve this problem.
Message header: Subject: Undelivered Mail Returned to Sender From: =?windows-1252?Q?TestyMc_Test?= testy@darktemple.ch To: =?windows-1252?Q?SKull?= skull@darktemple.ch Date: Sun, 19 Jun 2011 20:40:42 +0000 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_ZG_static" X-Mailer: Zarafa 6.40.7-26119
(Ja ich habe ein Zarafa Mailsystem installiert, da ist das Limit allerdings sogar auf 35mb hochgeschraubt)
Die Meldung kommt aber so wie ich das sehe nicht von meinem relay host (der smtp meines providers).
Weiss einer von euch hier weiter? Ist das ein Zarafa Problem? Oder ignoriert postfix wirklich mein message_size_limit?
gruss mathias
* SKull skull@darktemple.ch:
Ich bins nochmal. Zur Erinnerung schildere ich nochmal mein Problem. Ein Kunde von uns möchte mails bis 20mb verschicken. Also habe ich den Wert entsprechend in meiner main.cf angepasst und zwar auf: message_size_limit = 26214400 (25mb einfach um sicher zu gehen...) und den dienst entsprechend neu gestartet.
Nachrichten die nicht reines ASCII sind, werden MIME-kodiert. Sind es Attachments, werden die in der Regel base64 kodiert. Bei der Kodierung vergrössert sich eine Datei so um 1/3.
Wenn Du also 20 MB als Limit willst, solltest Du min. 27 MB erlauben. Ich lege immer noch was oben drauf.
p@rick
On Behalf Of SKull
Ich bins nochmal. Zur Erinnerung schildere ich nochmal mein Problem. Ein Kunde von uns möchte mails bis 20mb verschicken. Also habe ich den Wert entsprechend in meiner main.cf angepasst und zwar auf: message_size_limit = 26214400 (25mb einfach um sicher zu gehen...) und den dienst entsprechend neu gestartet.
Verschicke ich nun ein Mail mit einem ca. 19mb grossen anhang erhalte ich folgende Fehlermeldung: Unfortunately, I was unable to deliver your mail. The error given was:
19 mb + ca. 30% = 24,7 MB (die 30% sind nur eine Schätzung da der Anhang codiert und umgewandelt wird).
Bleibt anzumerken das mail im Ursprung nicht für Datenübertragung definiert wurde und ist.
552 5.2.3 Message exceeds maximum fixed size (20000000)
Tja da würde ich sagen das da einer dazwischen auf 20 MB begrenzt hat. Wenn du es nicht bist dann ist es ein anderer. Hier wären die kompletten Logzeilen zu der Mail hilfreich zu sehen.
You may need to contact your e-mail administrator to solve this problem.
Message header: Subject: Undelivered Mail Returned to Sender From: =?windows-1252?Q?TestyMc_Test?= testy@darktemple.ch To: =?windows-1252?Q?SKull?= skull@darktemple.ch Date: Sun, 19 Jun 2011 20:40:42 +0000 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_ZG_static" X-Mailer: Zarafa 6.40.7-26119
(Ja ich habe ein Zarafa Mailsystem installiert, da ist das Limit allerdings sogar auf 35mb hochgeschraubt)
Die Meldung kommt aber so wie ich das sehe nicht von meinem relay host (der smtp meines providers).
Tja dann wird es wohl ein anderer Beteiligter in der Kette sein.
Weiss einer von euch hier weiter?
Klar. Eigener Mailserver von vorne bis Hinten dann hat man das alles unter der Kontrolle (zumindest das eigener Kunde entsprechende Größe senden und empfangen kann sofern beim senden der Zielserver mitspielt).
Ist das ein Zarafa Problem? Oder ignoriert postfix wirklich mein message_size_limit?
Wenn message_size_limit nicht mehrfach in main.cf und/oder in der master.cf definiert sind wirst du nicht ignoriert bzw. die eingegebene Größe beachtet.
Wenn mehrfach vorhanden dann gewinnt der letzte Eintrag in der Kette.
Postconf -n , master.cf (bitte ohne Kommentare) und komplette Logzeilen bringen Licht ins Dunkel.
Mit freundlichen Grüßen
Drießen
Am 23.06.2011 08:04, schrieb Driessen:
On Behalf Of SKull
Ich bins nochmal. Zur Erinnerung schildere ich nochmal mein Problem. Ein Kunde von uns möchte mails bis 20mb verschicken. Also habe ich den Wert entsprechend in meiner main.cf angepasst und zwar auf: message_size_limit = 26214400 (25mb einfach um sicher zu gehen...) und den dienst entsprechend neu gestartet.
Verschicke ich nun ein Mail mit einem ca. 19mb grossen anhang erhalte ich folgende Fehlermeldung: Unfortunately, I was unable to deliver your mail. The error given was:
19 mb + ca. 30% = 24,7 MB (die 30% sind nur eine Schätzung da der Anhang codiert und umgewandelt wird).
Bleibt anzumerken das mail im Ursprung nicht für Datenübertragung definiert wurde und ist.
552 5.2.3 Message exceeds maximum fixed size (20000000)
Tja da würde ich sagen das da einer dazwischen auf 20 MB begrenzt hat. Wenn du es nicht bist dann ist es ein anderer. Hier wären die kompletten Logzeilen zu der Mail hilfreich zu sehen.
You may need to contact your e-mail administrator to solve this problem.
Message header: Subject: Undelivered Mail Returned to Sender From: =?windows-1252?Q?TestyMc_Test?= testy@darktemple.ch To: =?windows-1252?Q?SKull?= skull@darktemple.ch Date: Sun, 19 Jun 2011 20:40:42 +0000 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_ZG_static" X-Mailer: Zarafa 6.40.7-26119
(Ja ich habe ein Zarafa Mailsystem installiert, da ist das Limit allerdings sogar auf 35mb hochgeschraubt)
Die Meldung kommt aber so wie ich das sehe nicht von meinem relay host (der smtp meines providers).
Tja dann wird es wohl ein anderer Beteiligter in der Kette sein.
Weiss einer von euch hier weiter?
Klar. Eigener Mailserver von vorne bis Hinten dann hat man das alles unter der Kontrolle (zumindest das eigener Kunde entsprechende Größe senden und empfangen kann sofern beim senden der Zielserver mitspielt).
Ist das ein Zarafa Problem? Oder ignoriert postfix wirklich mein message_size_limit?
Wenn message_size_limit nicht mehrfach in main.cf und/oder in der master.cf definiert sind wirst du nicht ignoriert bzw. die eingegebene Größe beachtet.
Wenn mehrfach vorhanden dann gewinnt der letzte Eintrag in der Kette.
Postconf -n , master.cf (bitte ohne Kommentare) und komplette Logzeilen bringen Licht ins Dunkel.
Mit freundlichen Grüßen
Drießen
ich moechte mal anmerken, das viele grosse Mailprovider ohnehin nur 10 MB erlauben, je nachdem koennten also mails jetzt haeufiger in deiner Warteschlange duempeln weil sie nicht ausgeliefert werden koennen
* SKull skull@darktemple.ch:
Hallo allerseits
Ich bins nochmal. Zur Erinnerung schildere ich nochmal mein Problem. Ein Kunde von uns möchte mails bis 20mb verschicken. Also habe ich den Wert entsprechend in meiner main.cf angepasst und zwar auf: message_size_limit = 26214400 (25mb einfach um sicher zu gehen...) und den dienst entsprechend neu gestartet.
Verschicke ich nun ein Mail mit einem ca. 19mb grossen anhang erhalte ich folgende Fehlermeldung: Unfortunately, I was unable to deliver your mail. The error given was:
552 5.2.3 Message exceeds maximum fixed size (20000000)
Keine Postfix meldung Ist da irgendwo eine ISA Firewall?
Was sagt dein Postfix log dazu?
Hallo Liste,
heute ist mir in meinen Logs folgendes aufgefallen:
Jun 24 11:55:37 winnetou postfix/smtpd[24567]: initializing the server-side TLS engine Jun 24 11:55:37 winnetou postfix/smtpd[24567]: connect from mailout06.t-online.de[194.25.134.19] Jun 24 11:55:38 winnetou postfix/smtpd[24567]: NOQUEUE: reject: RCPT from mailout06.t-online.de[194.25.134.19]: 554 5.7.1 Service unavailable; Client host [194.25.134.19] blocked using dnsbl.sorbs.net; Currently Sending Spam See: http://www.sorbs.net/lookup.shtml?194.25.134.19; from=rechnungonline1@telekom.de to=tobias@koopmann-mail.de proto=ESMTP helo=<mailout06.t-online.de> Jun 24 11:55:38 winnetou postfix/smtpd[24567]: disconnect from mailout06.t-online.de[194.25.134.19]
Warum ist die Telekom hier gelistet und hat heute noch jemand sowas beobachtet?
Vielleicht ist auch was an meiner Config bröselig?!, häng sie einfach mal an:
postconf -n
address_verify_map = btree:${data_directory}/verify alias_database = proxy:btree:/etc/aliases alias_maps = proxy:btree:/etc/aliases biff = no bounce_template_file = /etc/postfix/bounce.de-DE.cf config_directory = /etc/postfix default_database_type = btree delay_warning_time = 24h html_directory = /usr/share/doc/postfix/html inet_protocols = ipv4, ipv6 mail_owner = postfix message_size_limit = 51200000 mydestination = localhost.$mydomain $myhostname mydomain = kokelnet.de myhostname = winnetou.$mydomain mynetworks = cidr:/etc/postfix/mynetworks_table mynetworks_style = subnet myorigin = $mydomain readme_directory = /usr/share/doc/postfix recipient_delimiter = + relay_domains = listen.kokelnet.de smtp_tls_cert_file = /etc/ssl/certs/winnetou.kokelnet.de.cert.pem smtp_tls_ciphers = export smtp_tls_key_file = /etc/ssl/private/winnetou.kokelnet.key.pem smtp_tls_loglevel = 2 smtp_tls_protocols = !SSLv2 smtp_tls_security_level = may smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache smtp_tls_session_cache_timeout = 3600s smtpd_banner = $myhostname ESMTP $mail_name smtpd_client_connection_rate_limit = 25 smtpd_client_message_rate_limit = 100 smtpd_client_recipient_rate_limit = 100 smtpd_delay_reject = yes smtpd_helo_required = yes smtpd_recipient_restrictions = check_recipient_access btree:/etc/postfix/access_recipient-rfc, check_client_access cidr:/etc/postfix/access_client, check_helo_access btree:/etc/postfix/access_helo, check_sender_access btree:/etc/postfix/access_sender, check_recipient_access btree:/etc/postfix/access_recipient, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, permit_sasl_authenticated, permit_mynetworks, reject_rbl_client zen.spamhaus.org, reject_rbl_client ix.dnsbl.manitu.net, reject_rbl_client bl.spamcop.net, reject_rbl_client dnsbl.njabl.org, reject_rbl_client dnsbl.sorbs.net, reject_rbl_client psbl.surriel.com, check_policy_service inet:127.0.0.1:12525, check_policy_service inet:127.0.0.1:10023, reject_unverified_recipient, reject_unauth_destination, permit smtpd_reject_footer = For assistance, call +491781765547.\nPlease provide the following information in your problem report:\ntime ($localtime), client ($client_address) and server ($server_name). smtpd_sasl_auth_enable = yes smtpd_sasl_authenticated_header = yes smtpd_sasl_path = private/auth smtpd_sasl_type = dovecot smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/ssl/certs/kokelnet_cert.pem smtpd_tls_ciphers = export smtpd_tls_key_file = /etc/ssl/private/kokelnet_private.pem smtpd_tls_loglevel = 2 smtpd_tls_protocols = !SSLv2 smtpd_tls_received_header = yes smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache smtpd_tls_session_cache_timeout = 3600s soft_bounce = no strict_rfc821_envelopes = yes tls_random_source = dev:/dev/urandom transport_maps = proxy:btree:/etc/postfix/transport unknown_address_reject_code = 550 unknown_client_reject_code = 550 unknown_hostname_reject_code = 550 unverified_recipient_reject_code = 577 unverified_recipient_reject_reason = The recipient-address is not valid! Maybe wrong syntax? virtual_alias_maps = proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf, proxy:mysql:/etc/postfix/mysql_virtual_alias_domain_maps.cf, virtual_gid_maps = static:8 virtual_mailbox_base = /var/vmail virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql_virtual_domains_maps.cf virtual_mailbox_limit = proxy:mysql:/etc/postfix/mysql_virtual_mailbox_limit_maps.cf virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf, proxy:mysql:/etc/postfix/mysql_virtual_alias_domain_mailbox_maps.cf, proxy:mysql:/etc/postfix/mysql_virtual_alias_domain_catchall_maps.cf virtual_minimum_uid = 150 virtual_transport = dovecot virtual_uid_maps = static:150
master.cf:
# # Postfix master process configuration file. For details on the format # of the file, see the master(5) manual page (command: "man 5 master"). # # Do not forget to execute "postfix reload" after editing this file. # # ========================================================================== # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100) # ========================================================================== smtp inet n - y - 80 smtpd -o smtpd_proxy_filter=127.0.0.1:10024 -o smtpd_proxy_options=speed_adjust -o content_filter=
127.0.0.1:10025 inet n - y - - smtpd -o content_filter= -o smtpd_proxy_filter= -o smtpd_authorized_xforward_hosts=127.0.0.0/8,[::1]/128,88.198.36.2/32,[2a01:4f8:63:11c2:0:dead:beef:69]/128 -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions= -o mynetworks=127.0.0.0/8,[::1]/128,88.198.36.2/32,[2a01:4f8:63:11c2:0:dead:beef:69]/128 -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks
smtps inet n - y - 60 smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o smtpd_proxy_filter=127.0.0.1:10030 -o smtpd_proxy_options=speed_adjust -o content_filter=
dovecot unix - n n - - pipe flags=DRhu user=vmail:mail argv=/usr/lib/dovecot/deliver -f ${sender} -d ${recipient}
mailman unix - n n - - pipe flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py ${nexthop} ${user}
vacation unix - n n - - pipe flags=DRhu user=vacation argv=/usr/bin/perl /var/spool/vacation/vacation.pl -f ${sender} -- ${recipient}
#628 inet n - - - - qmqpd pickup fifo n - - 60 1 pickup cleanup unix n - - - 0 cleanup qmgr fifo n - n 300 1 qmgr #qmgr fifo n - - 300 1 oqmgr tlsmgr unix - - - 1000? 1 tlsmgr rewrite unix - - - - - trivial-rewrite bounce unix - - - - 0 bounce defer unix - - - - 0 bounce trace unix - - - - 0 bounce verify unix - - - - 1 verify flush unix n - - 1000? 0 flush proxymap unix - - n - - proxymap proxywrite unix - - n - 1 proxymap smtp unix - - - - - smtp
# When relaying mail as backup MX, disable fallback_relay to avoid MX loops relay unix - - - - - smtp -o smtp_fallback_relay= # -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
showq unix n - - - - showq error unix - - - - - error retry unix - - - - - error discard unix - - - - - discard local unix - n n - - local virtual unix - n n - - virtual lmtp unix - - - - - lmtp anvil unix - - - - 1 anvil scache unix - - - - 1 scache
# ==================================================================== # Interfaces to non-Postfix software. Be sure to examine the manual # pages of the non-Postfix software to find out what options it wants. # # Many of the following services use the Postfix pipe(8) delivery # agent. See the pipe(8) man page for information about ${recipient} # and other message envelope options. # ==================================================================== # # maildrop. See the Postfix MAILDROP_README file for details. # Also specify in main.cf: maildrop_destination_recipient_limit=1 # maildrop unix - n n - - pipe flags=DRhu user=vmail argv=/usr/bin/maildrop -d ${recipient} # # ==================================================================== # # Recent Cyrus versions can use the existing "lmtp" master.cf entry. # # Specify in cyrus.conf: # lmtp cmd="lmtpd -a" listen="localhost:lmtp" proto=tcp4 # # Specify in main.cf one or more of the following: # mailbox_transport = lmtp:inet:localhost # virtual_transport = lmtp:inet:localhost # # ==================================================================== # # Cyrus 2.1.5 (Amos Gouaux) # Also specify in main.cf: cyrus_destination_recipient_limit=1 # #cyrus unix - n n - - pipe # user=cyrus argv=/cyrus/bin/deliver -e -r ${sender} -m ${extension} ${user} # # ==================================================================== # Old example of delivery via Cyrus. # #old-cyrus unix - n n - - pipe # flags=R user=cyrus argv=/cyrus/bin/deliver -e -m ${extension} ${user} # # ==================================================================== # # See the Postfix UUCP_README file for configuration details. # uucp unix - n n - - pipe flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
# # Other external delivery methods. # ifmail unix - n n - - pipe flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient) bsmtp unix - n n - - pipe flags=Fq. user=bsmtp argv=/usr/lib/bsmtp/bsmtp -t$nexthop -f$sender $recipient scalemail-backend unix - n n - 2 pipe flags=R user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store ${nexthop} ${user} ${extension}
--- Mit freundlichen Grüßen,
Tobias Koopmann
------------------------------------------------------------------ ...and I will promise to go on as long as you want me to, and I will dream along and help to make it real for you, too... (the mirror & the lie - Motorpsycho) ------------------------------------------------------------------
* Tobias Koopmann tobias@koopmann-mail.de:
Warum ist die Telekom hier gelistet und hat heute noch jemand sowas beobachtet?
Problem Entries, (listings will cause email problems.) 29 "Spam" entries [Latest: 06:13:11 24 Jun 2011 GMT+10]. 8 "Escalated" entries [Latest: 00:31:49 14 Mar 2010 GMT+10].
On Fri, 24 Jun 2011 13:27:38 +0200, Ralf Hildebrandt wrote:
Problem Entries, (listings will cause email problems.) 29 "Spam" entries [Latest: 06:13:11 24 Jun 2011 GMT+10]. 8 "Escalated" entries [Latest: 00:31:49 14 Mar 2010 GMT+10].
Ja, soweit war ich auch schon. Würde etwas dagegen sprechen die Telekom zu whitelisten?
--- Mit freundlichen Grüßen,
Tobias Koopmann
------------------------------------------------------------------ ...and I will promise to go on as long as you want me to, and I will dream along and help to make it real for you, too... (the mirror & the lie - Motorpsycho) ------------------------------------------------------------------
* Tobias Koopmann tobias@koopmann-mail.de:
On Fri, 24 Jun 2011 13:27:38 +0200, Ralf Hildebrandt wrote:
Problem Entries, (listings will cause email problems.) 29 "Spam" entries [Latest: 06:13:11 24 Jun 2011 GMT+10]. 8 "Escalated" entries [Latest: 00:31:49 14 Mar 2010 GMT+10].
Ja, soweit war ich auch schon. Würde etwas dagegen sprechen die Telekom zu whitelisten?
Das hängt von deinen Bedürfnissen ab.
* Ralf Hildebrandt Ralf.Hildebrandt@charite.de:
- Tobias Koopmann tobias@koopmann-mail.de:
On Fri, 24 Jun 2011 13:27:38 +0200, Ralf Hildebrandt wrote:
Problem Entries, (listings will cause email problems.) 29 "Spam" entries [Latest: 06:13:11 24 Jun 2011 GMT+10]. 8 "Escalated" entries [Latest: 00:31:49 14 Mar 2010 GMT+10].
Ja, soweit war ich auch schon. Würde etwas dagegen sprechen die Telekom zu whitelisten?
Das hängt von deinen Bedürfnissen ab.
(also da dich das zu stören scheint, würde ich denken du willst von da Mail empfangen)
On Fri, 24 Jun 2011 13:38:53 +0200, Ralf Hildebrandt wrote:
Das hängt von deinen Bedürfnissen ab.
(also da dich das zu stören scheint, würde ich denken du willst von da Mail empfangen)
Ja, das möchte ich und auch andere User, deren mailaccounts bei mir liegen. Der E-mail Verkehr des Telekom Support, Vertrieb, etc. wird nun mal über diese Server abgewickelt.
Meine Fragen: Würde explizit was dagegen sprechen die Mailouts der Telekom über die check_client_access Map zu whitelisten? Die Mails, die mein Postfix dann von denen annimmt müssen ja sowieso noch durch amavisd-new, würden allerdings nach der aktuellen Config an greylist und policyd-weight vorbeihuschen.
Mich würde auch interessieren wie hier die Meinung zu den Blacklists aussieht, die ich verwende, auch in verbindung mit Policyd-weight, der ja auch schon DNS Blacklists abfragt?
--- Mit freundlichen Grüßen,
Tobias Koopmann
------------------------------------------------------------------ ...and I will promise to go on as long as you want me to, and I will dream along and help to make it real for you, too... (the mirror & the lie - Motorpsycho) ------------------------------------------------------------------
Am 24.06.2011 13:35 schrieb Tobias Koopmann:
On Fri, 24 Jun 2011 13:27:38 +0200, Ralf Hildebrandt wrote:
Problem Entries, (listings will cause email problems.) 29 "Spam" entries [Latest: 06:13:11 24 Jun 2011 GMT+10]. 8 "Escalated" entries [Latest: 00:31:49 14 Mar 2010 GMT+10].
Ja, soweit war ich auch schon. Würde etwas dagegen sprechen die Telekom zu whitelisten?
Ja, von da kommt offenbar Spam *duck*
*SCNR*
Zitat von Florian Streibelt postfix@f-streibelt.de:
Am 24.06.2011 13:35 schrieb Tobias Koopmann:
On Fri, 24 Jun 2011 13:27:38 +0200, Ralf Hildebrandt wrote:
Problem Entries, (listings will cause email problems.) 29 "Spam" entries [Latest: 06:13:11 24 Jun 2011 GMT+10]. 8 "Escalated" entries [Latest: 00:31:49 14 Mar 2010 GMT+10].
Ja, soweit war ich auch schon. Würde etwas dagegen sprechen die Telekom zu whitelisten?
Ja, von da kommt offenbar Spam *duck*
Bitte Yahoo, Hotmail, web.de, GMX und Googlemail dazu nehmen, dann wird es ein ruhiger Tag :-)
Andreas
On Behalf Of lst_hoe02@kwsoft.de
Zitat von Florian Streibelt postfix@f-streibelt.de:
Am 24.06.2011 13:35 schrieb Tobias Koopmann:
On Fri, 24 Jun 2011 13:27:38 +0200, Ralf Hildebrandt wrote:
Problem Entries, (listings will cause email problems.) 29 "Spam" entries [Latest: 06:13:11 24 Jun 2011 GMT+10]. 8 "Escalated" entries [Latest: 00:31:49 14 Mar 2010 GMT+10].
Ja, soweit war ich auch schon. Würde etwas dagegen sprechen die Telekom zu whitelisten?
Ja, von da kommt offenbar Spam *duck*
Bitte Yahoo, Hotmail, web.de, GMX und Googlemail dazu nehmen, dann wird es ein ruhiger Tag :-)
Da würde mir eh nix fehlen *gg wer dort noch Mailkonten hat ist selber schuld.
Andreas
Mit freundlichen Grüßen
Drießen
Zitat von Driessen driessen@fblan.de:
On Behalf Of lst_hoe02@kwsoft.de
Zitat von Florian Streibelt postfix@f-streibelt.de:
Am 24.06.2011 13:35 schrieb Tobias Koopmann:
On Fri, 24 Jun 2011 13:27:38 +0200, Ralf Hildebrandt wrote:
Problem Entries, (listings will cause email problems.) 29 "Spam" entries [Latest: 06:13:11 24 Jun 2011 GMT+10]. 8 "Escalated" entries [Latest: 00:31:49 14 Mar 2010 GMT+10].
Ja, soweit war ich auch schon. Würde etwas dagegen sprechen die Telekom zu whitelisten?
Ja, von da kommt offenbar Spam *duck*
Bitte Yahoo, Hotmail, web.de, GMX und Googlemail dazu nehmen, dann wird es ein ruhiger Tag :-)
Da würde mir eh nix fehlen *gg wer dort noch Mailkonten hat ist selber schuld.
Die oben aufgeführten werden wohl von rund 90% der Privatnutzer in Deutschland und rund 30% der KMU verwendet, der Rest ist bei 1&1 bzw. einer der vielen anderen Marken von UI.
Gruß
Andreas
* Tobias Koopmann tobias@koopmann-mail.de:
from mailout06.t-online.de[194.25.134.19]: 554 5.7.1 Service unavailable; Client host [194.25.134.19] blocked using dnsbl.sorbs.net; Currently Sending Spam See: http://www.sorbs.net/lookup.shtml?194.25.134.19;
Natürlich senden die Spam. Es reciht wenn einer (oder mehrere) ihrer Kunden trojanisiert sind und im großen Stil über die Telekom Relay Spam schicken - dann sind alle "guten" Benutzer, die diese Relays nutzen, mitgefangen
Zitat von Tobias Koopmann tobias@koopmann-mail.de:
Hallo Liste,
heute ist mir in meinen Logs folgendes aufgefallen:
Jun 24 11:55:37 winnetou postfix/smtpd[24567]: initializing the server-side TLS engine Jun 24 11:55:37 winnetou postfix/smtpd[24567]: connect from mailout06.t-online.de[194.25.134.19] Jun 24 11:55:38 winnetou postfix/smtpd[24567]: NOQUEUE: reject: RCPT from mailout06.t-online.de[194.25.134.19]: 554 5.7.1 Service unavailable; Client host [194.25.134.19] blocked using dnsbl.sorbs.net; Currently Sending Spam See: http://www.sorbs.net/lookup.shtml?194.25.134.19; from=rechnungonline1@telekom.de to=tobias@koopmann-mail.de proto=ESMTP helo=<mailout06.t-online.de> Jun 24 11:55:38 winnetou postfix/smtpd[24567]: disconnect from mailout06.t-online.de[194.25.134.19]
Warum ist die Telekom hier gelistet und hat heute noch jemand sowas beobachtet?
Vielleicht ist auch was an meiner Config bröselig?!, häng sie einfach mal an:
Also SORBS für reject zu verwenden halte ich nicht für eine gute Idee. Korrekterweise sollte man genau die Listing-Policy der RBLs lesen und dann entscheiden ob man damit klarkommt.
Aber wie immer YMMV
Gruß
Andreas
participants (8)
-
Driessen -
Florian Streibelt -
lst_hoe02＠kwsoft.de -
Patrick Ben Koetter -
Ralf Hildebrandt -
Robert Schetterer -
SKull -
Tobias Koopmann