Hallo!
Nun hatte ich das mal wieder:
> Your membership in the mailing list pkg-kde-extras has been disabled
> due to excessive bounces The last bounce received from you was dated
> 01-Aug-2016. You will not get any more messages from this list until
> you re-enable your membership. You will receive 2 more reminders like
> this before your membership in the list is deleted.
>
> To re-enable your membership, you can simply respond to this message
> (leaving the Subject: line intact), or visit the confirmation page at
[…]
Also fange ich die REJECT oder DISCARD-Diskussion nochmal an, allerdings
diesmal mit der entsprechenden Recherche zum Thema.
Ich mache REJECT, kein Bounce. Warum Mailman da von Bounces spricht, ist mir
nicht schlüssig.¹ ²
[1] http://www.dontbouncespam.org/
[2] RFC 5321 says: "silent dropping of messages should be considered only in
those cases where there is very high confidence that the messages are
seriously fraudulent or otherwise inappropriate."
https://en.wikipedia.org/wiki/Backscatter_(email)
Daher, denke ich, halte ich mich schon an Best Practice-Standards.
Das Digital Ocean-Zeug discarde ich weiterhin, aber die von SpamAssassin oder
policyd-weight erkannten Spams möchte ich nicht einfach so wegwerfen. Ich
setze das jetzt aber auch auf REJECT um, da Digital Ocean die IP-Adressen ja
eventuell irgendwann mal an andere, legitime Kunden vergibt, die besser auf
ihre Server aufpassen.
Die Meinung der Debian-Listmaster dazu:
> I have been unsubscribed from a list, because my Mailsystem refused to
> accept Listmail containing Spam
>
> It is bad behaviour to refuse incoming mail because of the content, because:
>
> - RfC 2821 discourages in such practices Chapter 3.3:
> Server SMTP systems SHOULD NOT reject messages based on perceived
> defects in the RFC 822 or MIME [12] message header or message body.
>
> - If you bounce back such mails, you worsen the spam problem, as most spam
> uses mailaddresses of innocents, and bounces are then returned to those.
>
> - You double-opted-in to our lists, so you should accept (or discard if you
> please) all mails that comes through it.
>
> If you want to help us against spam, see the next chapter.
[3] https://wiki.debian.org/Teams/ListMaster/
FAQ#I_have_been_unsubscribed_from_a_list.
2C_because_my_Mailsystem_refused_to_accept_Listmail_containing_Spam
Sowie:
> But the mail you got a bounce for was Spam!
>
> Mail should never be bounced because of its content. Our mails are tagged
> with a 'Precedence: list' so if you decide to not receive mails for which
> you subscribed drop them silently.
[4] https://wiki.debian.org/Teams/ListMaster/
FAQ#But_the_mail_you_got_a_bounce_for_was_Spam.21
Meine Idee ist nun: Falls die Spam-Mail von einer Mailingliste kommt, also
eine "List-Id:"- oder eben diese "Precendence: list"-Kopfzeile hat, dann
DISCARD, ansonsten REJECT. Weil technisch verschickt natürlich der
entsprechende Debian-Mailserver die Spam. Allerdings leitet er diese auch nur
weiter. Daher müsste ich den REJECT entweder an den Sender davor laufen
lassen, was aber nicht geht, da dieser mit meinem Server keine SMTP-Verbindung
hat, *oder* wie von den Listen-Meistern empfohlen die Mail einfach still
wegwerfen.
Was meint ihr? Macht das Sinn?
Für SpamAssassin könnte ich das hier anpassen:
mondschein:/etc/postfix> cat header_checks
/^X-Spam-Flag:.YES/ REJECT Your mail is likely spam.
Das habe ich via
smtpd_recipient_restrictions =
permit_mynetworks
permit_sasl_authenticated
reject_non_fqdn_recipient
reject_unknown_recipient_domain
reject_unauth_destination
check_client_access hash:/etc/postfix/client_checks
check_sender_access pcre:/etc/postfix/sender_checks
check_policy_service inet:127.0.0.1:12525
in den Postfix eingehängt. Ich könnte mir nun vorstellen, dass sich eine
solche Abfrage auf die List-Id-Kopfzeile mit einer Perl Regular Expression
umsetzen lässt, auch wenn ich dazu erstmal etwas recherchieren müsste, wie so
ein Ausdruck dann aussieht.
Hmm, und ich frage mich gerade inwiefern check_client_access und
check_sender_access nicht entsprechend unterhalb von smptd_client_restrictions
und smtpd_senser_restrictions hingehören. Es scheint zwar so zu funktionieren,
kommt mir aber… ich hoffe es gibt bald eine Neu-Auflage vom Postfix-Buch, da
ich das bis heute nicht 100% verstanden habe, wie das im Postfix verdrahtet
ist und wo ein bestimmter Check hingehört. smtpd_recipient_- versus
smtp_relay_restrictions ist da ja auch eine spannende Frage.
Ciao,
--
Martin
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname : signature.asc
Dateityp : application/pgp-signature
Dateigröße : 801 bytes
Beschreibung: This is a digitally signed message part.
URL : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20160812/f11bdaeb/attachment.asc>