Re: Frage: Mail mit leerem oder statischem Inhalt als Reaktion auf Posteingang generieren

[Robert Schetterer via postfix-users]

Am 27.11.23 um 15:13 schrieb Jörg Hartmann via postfix-users:

Hallo,
ich bitte mal um Erleuchtung, wie man folgendes realisieren könnte/sollte:
- Auf eine fix Adresse (Bsp: huenerst...@bauernhof.bla 
) kommt eine Mail rein.
Diese Mail wird "normal" weiterverarbeitet und landet im zugehörigen 
Postfach, in meinem Fall auf einer anderen Kiste.
Gleichzeit wird jedoch (vom postfix) eine neue Mail generiert, die an 
eine andere Adresse geht und den Body / content der Ausgangsmail *nicht* 
enthält.
Gemeint ist etwa folgendes, wenn auf huenerst...@bauernhof.bla 
 eine Mail reinkommt, wird eine Art 
Notiz / Ping generiert (mit völlig statischem Inhalt a la "Es gibt Zoff 
im Stall") und zum Bsp. an bauer.he...@bauernhof.bla 
 versandt.

Eine Art Ping also... nur *ein* Ping...
Mittels /etc/aliases kann ich leicht die zweite Mail anstoßen, OK 
soweit, aber wie bekomme ich den Body der Ursprungsmail da raus?

Am liebsten mit postfix-Bordmitteln, wenn es halt geht.
Ich wäre schon mit einem (hilfreichen) Fingerzeig zufrieden.
Danke!
Viele Grüße
Jörg


Hi , das ware mit sieve kein Problem
aber da brauchst du halt ein dovecot, ansonsten
waere wahrscheinlich am einfachsten lokal auf ein maildir einzuliefern
und mit procmail die Info zu verschicken


https://www.trash.net/wissen/e-mailanleitungen/procmail-howto/

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Emails Zugang beim Empfänger bewiesen und trotzdem verschwunden

[Robert Schetterer via postfix-users]

Am 28.10.23 um 16:02 schrieb postfi...@herzteddy.de:

Hallo,
ich muss feststellen das z.B. auch öffentliche Einrichtungen Emails als 
Kommunikationsmöglichkeiten anbieten. Aber Emails auch negativ 
klassifiziert werden, z.B. als SPAM was dazu führen kann das sie später 
order gar nicht bearbeitet werden. Das kann oft sogar der Sachbearbeiter 
entscheiden oder Emails sogar nach Empfang einfach "verschwinden".

Darüber wird der Absender häufig sogar nicht informiert.
Was sind dafür sie gesetzlichen Grundlagen oder wird das in der IT 
rechts los und willkürlich entscheiden.


Oder wie kann ich überhaupt herausfinden wie meine Email klassifiziert ist.

Ansonsten kann ich nur feststellen das eine Email gegenüber einem FAX in 
vielen Fällen nachteilig ist.


Gruss




Hi, was du verlangst ist in der realen Welt nicht durchfuehrbar denn es 
wuerde heissen das oeffentliche Einrichtungen am Ende jede Email 
annehmen muessten und sichten muessten.


Was du verlangen kannst ist das einen technischen
Kontakt gibt fuer den Fehlerfall. Und ja, Fax oder Telefon ist durchaus 
erlaubt, ueblicher ist jedoch ein Emailformular auf einer Website.





--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Emailempfang nach ISO oder Zertifikate

[Robert Schetterer via postfix-users]

Am 21.10.23 um 21:48 schrieb postfi...@mytelpbx.com:

Hallo,
nach welchen Kriterien wird eigentlich der Emailempfang, insbesondere in 
öffentlichen Einrichtungen oder kommunalen Unternehmen festgelegt?
Macht da jeder wie er will, insbesondere wenn großflächig Emails als 
Kommunikationsmöglichkeit angeboten werden.

Gibt es Zertifikate, ISO oder anderes um den Zugang sicherzustellen.


Sep 25 13:15:07 h2946990 postfix/smtp[12852]: 01F676A0530: host
mx.svo-holding.de[213.252.153.78] said: 450-4.7.1 This email was
rejected because it violates our security policy or the address is not
found or not anymore. - Diese E-Mail wurde abgelehnt, da sie gegen
unsere Sicherheitsrichtlinie verstoesst oder die Adresse nicht oder
nicht mehr gefunden wird. 450-4.7.1   The host 85.214.219.0/24 is not
yet authorized to send emails to this server. 450 4.7.1   The reputation
filter deemed your email unworthy. (in reply to end of DATA command)




Hi, soweit ich weiss gibts da nur max eine "best practise" die sich 
wahrscheinlich auf irgendeine Empfehlung des BSI bezieht.

Anderes waere das kaum moeglich.

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Verteilerliste mit virtual aliases - address rewriting

[Robert Schetterer]

Am 03.10.22 um 12:48 schrieb Andreas Wass - Glas Gasperlmair:

Generelle Frage an alle:
Wie handhabt ihr eure internen E-Mail-Verteiler, welche extern nicht 
bekannt sein sollten/dürfen?


Nun wie kommt eine Email Adi nach aussen, entweder jemand nutzt sie als 
Versender, oder sie steht irgendwo, wo sie abgegriffen werden kann


wer absolut sicherstellen will dass eine Adresse nur Intern benutzt wird
nutzt eine domain die eben nur intern geroutet werden kann, das 
funktioniert freilich nur auf smtp level





Vg, Andi

Am 03.10.2022 um 12:33 schrieb Walter H.:

On 03.10.2022 10:32, Robert Schetterer wrote:

Am 03.10.22 um 09:11 schrieb Andreas Wass - Glas Gasperlmair:

Hallo Liste,

Hab jetzt ziemlich rumprobiert und lt. folgender readme müsste es 
doch möglich sein einen alias in seine einzelnen Adressen 
umzuschreiben:

Hier drin steht:

  *

    Replace an address by multiple addresses. For example, replace the
    address of an alias by the addresses listed under that alias.

readme:
https://www.postfix.org/ADDRESS_REWRITING_README.html

meine sender_canonical_maps bzw. meine recipient_canonical_maps 
sehen so aus:
abt-vers...@meinedomain.at 
ema...@meinedomain.at,ema...@meinedomain.at,ema...@meinedomain.at


Versende ich nun eine E-Mail an meine externe private E-Mail-Adresse 
und CC an abt-vers...@meinedomain.at, sehe ich trotzdem nur den 
alias "abt-vers...@meinedomain.at" nicht aber die einzelnen 3 
E-Mail-Adressen, die diesen alias haben.


Keiner eine Idee?


Idee schon, aber nicht mit puren postfix
du koenntest das wohl mit einer .forward , oder mit sieve machen etc 
evtl auch mit /usr/bin/sendmail ansonsten wuerde mir nur 
header_checks einfallen


hier ist sowas aehnliches muesst man dementsprechend abaendern

https://serverfault.com/questions/643070/postfix-rewriting-sender-with-generic-header-check 



aber das ist arges gefrickel, sorry mehr faellt mir grad nicht ein


ich würde davon abraten,
Mails mit Reply-to im Header werden wahrscheinlicher als SPAM 
klassifiziert;










--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Verteilerliste mit virtual aliases - address rewriting

[Robert Schetterer]

Am 03.10.22 um 09:11 schrieb Andreas Wass - Glas Gasperlmair:

Hallo Liste,

Hab jetzt ziemlich rumprobiert und lt. folgender readme müsste es doch 
möglich sein einen alias in seine einzelnen Adressen umzuschreiben:

Hier drin steht:

  *

Replace an address by multiple addresses. For example, replace the
address of an alias by the addresses listed under that alias.

readme:
https://www.postfix.org/ADDRESS_REWRITING_README.html

meine sender_canonical_maps bzw. meine recipient_canonical_maps sehen so 
aus:
abt-vers...@meinedomain.at 
ema...@meinedomain.at,ema...@meinedomain.at,ema...@meinedomain.at


Versende ich nun eine E-Mail an meine externe private E-Mail-Adresse und 
CC an abt-vers...@meinedomain.at, sehe ich trotzdem nur den alias 
"abt-vers...@meinedomain.at" nicht aber die einzelnen 3 E-Mail-Adressen, 
die diesen alias haben.


Keiner eine Idee?


Idee schon, aber nicht mit puren postfix
du koenntest das wohl mit einer .forward , oder mit sieve machen etc 
evtl auch mit /usr/bin/sendmail ansonsten wuerde mir nur header_checks 
einfallen


hier ist sowas aehnliches muesst man dementsprechend abaendern

https://serverfault.com/questions/643070/postfix-rewriting-sender-with-generic-header-check

aber das ist arges gefrickel, sorry mehr faellt mir grad nicht ein

milter koennte auch funktionieren
http://www.snertsoft.com/sendmail/milter-ahead/

so wie ich das sehe kannst du die Mail vor der weiterleitung
manipulieren oder danach, aber nicht waehrend oder mit der postfix 
weiterleitung




VG, Andi

Am 30.09.2022 um 11:29 schrieb Andreas Wass - Glas Gasperlmair:

Hallo Liste,

Gleich vorab: Bitte keine Kommentare bezüglich "verwende doch mailman" 
oder "schreib den alias doch ins BCC Feld"


Ich habe da einige aliases in meiner DB, welche ich als Verteilerliste 
verwenden möchte.

virtual_alias_maps = proxy:mysql:/etc/postfix/mysql-virtual-alias-maps.cf

+-+---+++
| id  | domain_id | source | destination |
+-+---+++
| 1 | 2 | abt-vers...@meinedomain.at | ema...@meinedomain.at |
| 2 | 2 | abt-vers...@meinedomain.at | ema...@meinedomain.at |
| 3 | 2 | abt-vers...@meinedomain.at | ema...@meinedomain.at  |
+-+---+++

Das ganze funktioniert prima, allerdings hätte ich gerne, dass 
Empfänger nicht sehen, dass das E-Mail an abt-vers...@meinedomain.at 
gesendet wurde, sondern dass das E-Mail an ema...@meinedomain.at, 
ema...@meinedomain.at und ema...@meinedomain.at gesendet wurde.


Ich möchte einfach verhindern, wenn ein E-Mail z.B. extern an 
off...@irgendeinkunde.at versendet und der alias ("Verteiler" ) 
abt-vers...@meinedomain.at  im Feld CC steht, dass dieser alias 
(Verteiler) NICHT als solcher beim Kunden z.B. ersichtlich ist.
Trotzdem möchte ich, dass der Kunde sieht, dass das E-Mail als CC auch 
an ema...@meinedomain.at, ema...@meinedomain.at und 
ema...@meinedomain.at gesendet wurde


Kann man das mit address rewriting umsetzen und wenn ja wie?

Ich hoffe, ich habe mich klar genug ausgedrückt

Anbei noch meine master.cf, falls hier was zu ändern ist:

# 
==

# service type  private unpriv  chroot  wakeup  maxproc command + args
#   (yes)   (yes)   (no)    (never) (100)
# 
==

#smtp  inet  n   -   y   -   -   smtpd
smtp  inet  n   -   y   -   1   postscreen
smtpd pass  -   -   y   -   -   smtpd
  -o smtpd_sasl_auth_enable=no
dnsblog   unix  -   -   y   -   0   dnsblog
tlsproxy  unix  -   -   y   -   0   tlsproxy
submission inet n   -   y   -   -   smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_tls_auth_only=yes
  -o smtpd_reject_unlisted_recipient=no
#  -o smtpd_client_restrictions=$mua_client_restrictions
#  -o smtpd_helo_restrictions=$mua_helo_restrictions
#  -o smtpd_sender_restrictions=$mua_sender_restrictions
  -o smtpd_recipient_restrictions=
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING
#smtps inet  n   -   y   -   -   smtpd
#  -o syslog_name=postfix/smtps
#  -o smtpd_tls_wrappermode=yes
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_reject_unlisted_recipient=no
#  -o smtpd_client_restrictions=$mua_client_restrictions
#  -o smtpd_helo_restrictions=$mua_helo_restrictions
#  -o smtpd_sender_restrictions=$mua_sender_restrictions
#  -o smtpd_recipient_restrictions=
#  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING
#628   inet  n   -   y   -   -   qmqpd

Re: Postfix soll E-Mails an E-Mail-Adressen annehmen, deren Existenz es derzeit nicht feststellen kann

[Robert Schetterer]

Am 09.03.2022 um 13:35 schrieb Rudolf E. Steiner:

Am 09.03.22 um 08:23 zitierte/schrieb Robert Schetterer:


Kennt jemand von Euch eine Möglichkeit, Postfix auf diese Art zu
konfigurieren?

Aus meiner Sicht ist "diese Form" von Backup MX tot, du solltest diesen
Versuch nicht weiter verfolgen


Vielen Dank für den Hinweis.

Was wäre dann eine sinnvolle Konfiguration, wenn Kunden eigene Haupt-MX
in deren Infrastruktur betreiben und einen Reserve-MX beim
Diensteanbieter wünschen?


Das mindeste ist, dass der Kunde dir ein Liste der validen Adressen
ueberlaesst, oder selbst pflegt ( das geht zb ganz gut ueber webmin ), 
aber auch dann bleibt es schwierig, weil im Grunde

alle Antispam Dinge usw mit dem prime Server uebereinstimmen muessen
auch Einstellungen zu SPF,DKIM, DMARC etc



Eine Variante, die mir einfällt wäre, dem Haupt-MX und dem Reserve-MX im
DNS die selbe Priorität zu geben. Damit sollte gewährleistet sein, dass
Postfix als Reserve-MX alle in Verwendung stehenden E-Mail-Adressen
lernen kann. Jedoch würde ich dann bei 50 % der ankommenden E-Mails
einen unnötigen Umweg produzieren.



Du wirst dich sehr ungluecklich machen damit, ich verstehe ohnehin nicht
wozu man das braucht ( ausser in ganz bestimmten Ausnahmen und dann auch 
nur wenn man alle Server selber im Griff hat )


Ein Sender Server wird 5 Tage lang versuchen eine Mail zuzustellen
das sollte ausreichen um einen Maildienst wieder in Betrieb zu nehmen
und wenn nicht dann gibt es halt ein "nicht zustellbar", das ist nichts 
boeses


Der Kunde sollte daran arbeiten dass er Redundanz in seinen Mailservern 
hat, das ist kein Hexenwerk, das klassische Backup mx Konzept ist tot

das gibt nur endlose Probleme

hier ein Blog, achtung schon sehr alt, aber zeigt ein Konzept mit load 
balancern bei mail


https://blog.sys4.de/loadbalancing-mit-keepalived-postfix-dovecot-de.html

--
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Postfix soll E-Mails an E-Mail-Adressen annehmen, deren Existenz es derzeit nicht feststellen kann

[Robert Schetterer]

Am 08.03.22 um 22:00 schrieb Rudolf E. Steiner:

Hallo Kollegen.

Wir verwenden Postfix auch als Reserve-MX für Domänen, deren Haupt-MX
wir selbst nicht betreiben. Damit haben wir auch keine Informationen
darüber, welche E-Mail-Adressen in den jeweiligen Domänen existieren.

Wenn bekannt ist, welche E-Mail-Adressen in einer Domäne existieren,
können diese in der Konfiguration von Postfix angegeben werden.

Wenn diese aber nicht bekannt sind, wird folgendes Szenario aktiv:

Postfix als Reserve-MX überprüft während des Erhalts einer E-Mail, ob
die E-Mail-Adresse existiert, indem es beim Haupt-MX nachfragt und das
Resultat in der Datei "verify_cache.db" speichert. Wenn der Haupt-MX
positiv reagiert, nimmt Postfix die E-Mail an und leitet sie weiter.
Wenn der Haupt-MX negativ reagiert, lehnt Postfix die E-Mail schon im
SMTP-Dialog ab, damit kein potentieller "Müll" in der Queue entsteht,
der zu potentiell gefälschten Absenderadressen retour gesendet werden muss.

Wenn nun aber der Haupt-MX nicht erreichbar ist oder beispielsweise den
Verbindungsaufbau per ICMP ablehnt und gleichzeitig noch kein passender
Eintrag in der Datei "verify_cache.db" existiert, kann der Backup-MX
nicht feststellen, ob die Ziel-E-Mail-Adresse existiert.

In diesem Fall lehnt Postfix als Backup-MX die E-Mail ab. Das läuft
entgegen der Funktion eines Backup-MX.

Ich würde Postfix gerne beibringen, dass er im Fall der
Nichtfeststellbarkeit der Existenz einer Ziel-E-Mail-Adresse, die E-Mail
trotzdem annimmt, in allen anderen Fällen aber wie oben beschrieben
arbeitet. Mir ist bewusst, dass dadurch vereinzelt E-Mails angenommen
werden könnten, die auch dann, wenn der Haupt-MX wieder erreichbar ist,
nicht zugestellt werden können, da die Ziel-E-Mail-Adressen nicht
existieren könnten. Insgesamt wäre das aber, meiner Ansicht nach, die
wesentlich schönere Lösung bei einem Ausfall des Haupt-MX. Mit vielen
solcher Nachrichten ist, denke ich, nicht zu rechnen, da die liste der
existierenden bzw. nicht existierenden E-Mail-Adressen bereits zum
Großteil in der Datei "verify_cache.db" abgebildet sein sollte.

Kennt jemand von Euch eine Möglichkeit, Postfix auf diese Art zu
konfigurieren?



Aus meiner Sicht ist "diese Form" von Backup MX tot, du solltest diesen 
Versuch nicht weiter verfolgen


--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Sparkassenspam

[Robert Schetterer]

Am 09.11.21 um 16:45 schrieb Andreas Reschke:

Hallo zusammen,

täglich kommen bei meinen User ca. 5 Mails mit Sparkasse Spam bzw. 
Pishing an. Mein rspamd lässt viele davon leider durch.


Was kann kann ich ändern bzw. wie Abhilfe leisten?

So zeigt rspamd dies über das Webinterface an:
Symbols

Sort by:

*RSPAMD_URIBL* (4.5) [yomegosmr.com:url]
*RECEIVED_SPAMHAUS_XBL* (3) [92.80.251.71:received]
*OLD_X_MAILER* (2)
*AUTH_NA* (1)
*R_MIXED_CHARSET* (0.83) [subject]
*MV_CASE* (0.5)
*MIME_HTML_ONLY* (0.2)
*RCVD_NO_TLS_LAST* (0.1)
*FROM_HAS_DN* (0)
*TO_DN_NONE* (0)
*ARC_NA* (0)
*RCVD_VIA_SMTP_AUTH* (0)
*RCVD_COUNT_TWO* (0) [2]
*RECEIVED_SPAMHAUS_PBL* (0) [92.80.251.71:received]
*R_SPF_NA* (0) [no SPF record]
*MIME_TRACE* (0) [0:~]
*TO_MATCH_ENVRCPT_ALL* (0)
*FROM_EQ_ENVFROM* (0)
*DMARC_NA* (0) [carsystem.co.rs]
*MID_RHS_MATCH_FROM* (0)
*GREYLIST* (0) [pass,body]
*RCPT_COUNT_ONE* (0) [1]
*R_DKIM_NA* (0)
*ASN* (0) [asn:203877, ipnet:185.102.236.0/22, country:RS]

*PREVIOUSLY_DELIVERED* (0) [x...@xxx.de]

subject = Wir ändern unsere Verfahren oder Sparkasse Sicherheitshinweis


Gruß

Andreas



Kann ich dir natuerlich nicht garantieren
aber clamav-milter mit

https://sanesecurity.com/usage/signatures/

war da eigentlich immer ganz gut
ansonsten besser mal auf der rspamd liste fragen
mit Beispielen , oder eben an ein paar parameter drehen

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Postfix-rspamd Problem durch recipient_bcc_maps

[Robert Schetterer]

Am 18.10.21 um 17:26 schrieb Andreas Wass - Glas Gasperlmair:

Hallo Liste,

möchten in naher Zukunft auf Postfix mit Dovecot und rspamd (zur Zeit 
amavisd) umsteigen.


1.)    Alle eingehenden und ausgehenden Mails sollten zusätzlich mit 
postfix durch recipient_bcc_maps und sender_bcc_maps an die 
Archivpostfächer archiveing...@meinedomain.at und 
archivausg...@meinedomain.at weitergeleitet.


2.    Soll ein globales Sieve-Script alle Mails, welche header :contains 
"X-Spam" "Yes" haben in einen globalen Spam-Ordner redirecten


3.)    alle Mails welche header :contains "X-Spamd-Result" 
["FILENAME_BLACKLISTED", "MIME_BAD_ATTACHMENT", "MIME_BAD_EXTENSION"] 
haben in einen globalen Banned-Ordner redirecten.


Das Problem dabei ist, dass auch alle Mails durch recipient_bcc_maps und 
sender_bcc_maps durch die Prüfung von rspamd geschickt werden und dann 
natürlich doppelt in den spam und banned ordner landen und die Filterung 
im Sievescript unnötig erschwert wird.


Gibt es eine Möglichkeit, die Prüfung dieser E-Mails mit rspamd 
auszulassen über die multimaps oder ähnliches,
oder über die master.cf bzw. main.cf in postfix wenn diese per 
recipient_bcc_maps und sender_bcc_maps weitergeleitet werden?


Oder was würdet ihr für so eine Anforderung machen?

Vg, Andi


mit rspamd kenne ich mich nicht aus
aber ich hab uber sowas aehnliches mal einen blog geschrieben
evtl hilfts ein wenig

https://blog.sys4.de/mailarchiv-mit-dovecot-und-postfix-sortiert-nach-datum-mailadressen-und-ein-ausgehend-unterordnern-de.html

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Submission Port - receive_override_options=no_header_body_checks funktioniert nicht

[Robert Schetterer]

 -   1   proxymap
smtp  unix  -   -   y   -   -   smtp
relay unix  -   -   y   -   -   smtp
    -o syslog_name=postfix/$service_name
#   -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
showq unix  n   -   y   -   -   showq
error unix  -   -   y   -   -   error
retry unix  -   -   y   -   -   error
discard   unix  -   -   y   -   -   discard
local unix  -   n   n   -   -   local
virtual   unix  -   n   n   -   -   virtual
lmtp  unix  -   -   y   -   -   lmtp
anvil unix  -   -   y   -   1   anvil
scache    unix  -   -   y   -   1   scache
postlog   unix-dgram n  -   n   -   1   postlogd
#
# 
# 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=DRXhu 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
#  flags=DRX 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}

mailman   unix  -   n   n   -   -   pipe
  flags=FRX user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py 
${nexthop} ${user}

# Rückgabe der untersuchten Mails von amavis an postfix
*localhost:10025 inet  n   -   -   - -   smtpd**
**  -o content_filter=**
**  -o smtpd_proxy_filter=**
**  -o smtpd_authorized_xforward_hosts=127.0.0.0/8**
**  -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**
**  -o receive_override_options=no_unknown_recipient_checks**
**## Folgende Zeile verhindert die checks komplett (zur Zeit)**
**##  -o 
receive_override_options=no_header_body_checks,no_unknown_recipient_checks*


vg, Andi

Am 07.09.2021 um 16:32 schrieb Robert Schetterer:

Am 07.09.21 um 08:51 schrieb Andreas Wass - Glas Gasperlmair:

Hallo Liste,

Möchte Header- und Bodychecks für submission port deaktivieren, hab 
den receive_override_options=no_header_body_checks brav in die 
master.cf wie folgt eingetragen, allerdings funktioniert das nicht.


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

NOTE: do not use spaces around the "=" or "," characters

ich hab mich mal daemlich gesucht weil ich da einen whitespace
hatte, evtl mal checken




Mails mit diversen Keyword werden sowohl an port 25 (wo es ja 
berechtigt ist) als auch am submission (wo sie durchgelassen werden 
solten) in die HOLD queue gestellt.


# 
==

# service type  private unpriv  chroot 

Re: Submission Port - receive_override_options=no_header_body_checks funktioniert nicht

[Robert Schetterer]

Am 07.09.21 um 08:51 schrieb Andreas Wass - Glas Gasperlmair:

Hallo Liste,

Möchte Header- und Bodychecks für submission port deaktivieren, hab den 
receive_override_options=no_header_body_checks brav in die master.cf wie 
folgt eingetragen, allerdings funktioniert das nicht.


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

NOTE: do not use spaces around the "=" or "," characters

ich hab mich mal daemlich gesucht weil ich da einen whitespace
hatte, evtl mal checken




Mails mit diversen Keyword werden sowohl an port 25 (wo es ja berechtigt 
ist) als auch am submission (wo sie durchgelassen werden solten) in die 
HOLD queue gestellt.


# ==
# service type  private unpriv  chroot  wakeup  maxproc command + args
#   (yes)   (yes)   (no)    (never) (100)
# ==
#smtp  inet  n   -   y   -   -   smtpd
# Port 25 - alle extern ankommenden mails per postscreen pruefen
smtp  inet  n   -   y   -   1   postscreen
smtpd pass  -   -   y   -   -   smtpd
# SASL auf port 25 nicht zulassen (senden nur über submission s. unten)
   -o smtpd_sasl_auth_enable=no
# extern ankommende Mails per smtpd_proxy_filter an amavis übergeben
   -o smtpd_proxy_filter=localhost:10024
dnsblog   unix  -   -   y   -   0   dnsblog
tlsproxy  unix  -   -   y   -   0   tlsproxy
# Port 587 - Senden von mails nur über diesen Port zulassen
*submission inet n   -   y   -   -   smtpd**
**  -o receive_override_options=no_header_body_checks*
   -o syslog_name=postfix/submission
   -o smtpd_tls_security_level=encrypt
   -o smtpd_sasl_auth_enable=yes
#  -o smtpd_tls_auth_only=yes
   -o smtpd_reject_unlisted_recipient=no
#  -o smtpd_client_restrictions=$mua_client_restrictions
#  -o smtpd_helo_restrictions=$mua_helo_restrictions
#  -o smtpd_sender_restrictions=$mua_sender_restrictions
   -o smtpd_recipient_restrictions=
   -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
#  -o receive_override_options=no_header_body_checks
#  -o milter_macro_daemon_name=ORIGINATING
# zu sendende mails (z.B. Thunderbird) per content_filter an amavis 
übergeben

   -o content_filter=smtp:[127.0.0.1]:10030
#smtps inet  n   -   y   -   -   smtpd
#  -o syslog_name=postfix/smtps
#  -o smtpd_tls_wrappermode=yes
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_reject_unlisted_recipient=no
#  -o smtpd_client_restrictions=$mua_client_restrictions
#  -o smtpd_helo_restrictions=$mua_helo_restrictions
#  -o smtpd_sender_restrictions=$mua_sender_restrictions
#  -o smtpd_recipient_restrictions=
#  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING
#628   inet  n   -   y   -   -   qmqpd
pickup    unix  n   -   y   60  1   pickup
cleanup   unix  n   -   y   -   0   cleanup
qmgr  unix  n   -   n   300 1   qmgr
#qmgr unix  n   -   n   300 1   oqmgr
tlsmgr    unix  -   -   y   1000?   1   tlsmgr
rewrite   unix  -   -   y   -   - trivial-rewrite
bounce    unix  -   -   y   -   0   bounce
defer unix  -   -   y   -   0   bounce
trace unix  -   -   y   -   0   bounce
verify    unix  -   -   y   -   1   verify
flush unix  n   -   y   1000?   0   flush
proxymap  unix  -   -   n   -   -   proxymap
proxywrite unix -   -   n   -   1   proxymap
smtp  unix  -   -   y   -   -   smtp
relay unix  -   -   y   -   -   smtp
     -o syslog_name=postfix/$service_name
#   -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
showq unix  n   -   y   -   -   showq
error unix  -   -   y   -   -   error
retry unix  -   -   y   -   -   error
discard   unix  -   -   y   -   -   discard
local unix  -   n   n   -   -   local
virtual   unix  -   n   n   -   -   virtual
lmtp  unix  -   -   y   -   -   lmtp
anvil unix  -   -   y   -   1   anvil
scache    unix  -   -   y   -   1   scache
postlog   unix-dgram n  -   n   -   1   postlogd
#
# 
# 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 

Re: DKIM, SPF, DMARC usw.

[Robert Schetterer]

Am 06.09.21 um 14:24 schrieb Patrick Ben Koetter:

Andi,

Am 02.09.21 um 11:45 schrieb Andreas Wass - Glas Gasperlmair:

Hallo Liste,

bin ja gerade am tüfteln unseres neuen Setups für unseren neuen 
Mailserver auf Debian mit postfix, dovecot, amavis und Co.


Macht es überhaupt Sinn DKIM, SPF, DMARC usw einzusetzen?

Im Postfix Buch von Peer Heinlein habe ich gelesen, dass das seiner 
Meinung nach der falsche Ansatz ist, da sich heute jeder Spammer 
gültige DNS Einträge, gültige Signaturen usw. konfigurieren kann und 
es dadurch eigentlich noch leichter wird durch Spamfilter hindurch zu 
kommen, denn


verfolgt man folgenden Ansatz,

https://blog.sys4.de/amavisd-new-dkim-howto-de.html

dann würde man bei gültigen Absendern ja Viren und Spamprüfungen per 
Policies für gewisse Absender ausschalten und nur ungültige Absender 
durch Viren- und Spamfilter jagen.


Sender-Authentication, also der Dreiklang aus SPF, DKIM und DMARC ist 
angekommen, wird genutzt und es wird in absehbarer Zeit verbindlich sein 
wenn Du E-Mail auf den Plattformen "der Großen" einliefern willst.


Das BSI wird diese drei Technologien in der beauftragten, aber noch zu 
schaffenden TR01380 verankern und beschreiben wie die Technologien 
implementiert werden müssen, damit sie TR-konform sind. Die Arbeiten an 
der TR beginnen dieses Jahr und sollen – aktueller Stand der Planung – 
Ende Q2/2022 abgeschlossen sein.


In D beabsichtigen die (großen) Provider inbound SPF, DKIM und DMARC zu 
prüfen. Sie legen dabei Wert darauf, dass vor allem DKIM am Start sein 
muss, denn IP-basierte Policies nehmen, dank wandernder IPs im 
Cloud-Alltag, an Bedeutung abnehmen. Setzt also vor allem DKIM und DMARC 
ein bzw. "ertüchtigt" Eure Plattform entsprechend. Ziel der Großen ist 
vor allem Massenversender in den Griff zu bekommen. Die Kleinen wollen 
sich nicht schlechter stellen, wenn DKIM und DMARC nicht am Start sind.


Grüße

p@rick

--
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein



Danke und Amen *g

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: DKIM, SPF, DMARC usw.

[Robert Schetterer]

Am 02.09.21 um 13:32 schrieb Juergen Dollinger:

Robert Schetterer wrote:

Am 02.09.21 um 11:45 schrieb Andreas Wass - Glas Gasperlmair:

Hallo Liste,

bin ja gerade am tüfteln unseres neuen Setups für unseren neuen
Mailserver auf Debian mit postfix, dovecot, amavis und Co.

Macht es überhaupt Sinn DKIM, SPF, DMARC usw einzusetzen?


Ohne das brauchst du heut zu Tage erst gar nicht anfangen.


Quatsch. DMARC macht Mailinglisten kaputt, und den Rest braucht auch
keiner.



Ok

sys4.de.3600IN  TXT "v=spf1 
ip4:194.126.158.132 ip4:194.126.158.144 ip6:2001:1578:400:111::7 -all"


was machen wir falsch *g


--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: DKIM, SPF, DMARC usw.

[Robert Schetterer]

Am 02.09.21 um 11:45 schrieb Andreas Wass - Glas Gasperlmair:

Hallo Liste,

bin ja gerade am tüfteln unseres neuen Setups für unseren neuen 
Mailserver auf Debian mit postfix, dovecot, amavis und Co.


Macht es überhaupt Sinn DKIM, SPF, DMARC usw einzusetzen?


Ohne das brauchst du heut zu Tage erst gar nicht anfangen.



Im Postfix Buch von Peer Heinlein habe ich gelesen, dass das seiner 
Meinung nach der falsche Ansatz ist, da sich heute jeder Spammer gültige 
DNS Einträge, gültige Signaturen usw. konfigurieren kann und es dadurch 
eigentlich noch leichter wird durch Spamfilter hindurch zu kommen, denn


Seufz.ja auch ein "verifizierter" Sender kann dir Spam senden
( typischerweise kommts von goggle etc )
diese Standards sind gar nicht wirklich gedacht zur Spamabwehr
sie wirken da mit wenn es alles gut geht



verfolgt man folgenden Ansatz,

https://blog.sys4.de/amavisd-new-dkim-howto-de.html

dann würde man bei gültigen Absendern ja Viren und Spamprüfungen per 
Policies für gewisse Absender ausschalten und nur ungültige Absender 
durch Viren- und Spamfilter jagen.



FAZIT aus meiner Sicht:

 1. Abweisen aller Versender (Kunden die uns Aufträge senden) mit
ungültigen DKIM, SPF aufgrund schlecht konfigurierter Mailserver
wäre fatal.
 2. Ausnahme von Viren- und Spamfilter aufgrund von gültigen DKIM, SPF
Absendern, die ich mühsam in einer Liste pflegen muss bringt auch
nix, da ich natürlich möchte, dass auch Emails unserer Kunden trotz
gültiger DKIM, SPF usw. durch alle Spam- und Virenfilter gehen.

  * Also was tun?
Weist Ihr Versender aufgrund ungültiger Prüfungen dieser Mechanismen
ab? (Es sollen ja auch viele Office 365 Mailserver im Hinblick
darauf schlecht konfiguriert sein und viel ungültige Prüfung in
diese Richtung auslösen)

  * Was macht Sinn?

  * Oder habe ich generell etwas falsch verstanden?


vg, Andi


Standards einsetzen, z.B Kunden per Whitelist
Policy musst du dir selber ueberlegen
--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Problem mit IP-Reputation

[Robert Schetterer]

Am 28.04.21 um 14:03 schrieb Papierkorb:

Mahlzeit zusammen,

ich bin Admin einer kleinen Postfix/Dovecot-Kombo auf nem dedizierten 
Hetzner-Server.


Seit 2 Tagen lehnen einige Mailserver E-Mails von meinem Mailserver ab, 
mit der Begründung, dass die IP-Reputation sehr schlecht sei.
Noch ist das Problem überschaubar, derzeit sind nur einzelne Mails 
betroffen, aber auch die wollen ja irgendwann auch mal wieder zugestellt 
werden.
Sofort habe ich geprüft, ob mein Mailserver auf ner Blacklist steht, was 
jedoch nicht der Fall ist.


Als Ursache für das Problem vermute ich daher, dass
a) ein Newsletter, der mit ca 8.500 Empfängern (opt-in) über meinen 
Server versendet worden ist.
b) ein ganzes Subnetz von Hetzner schlecht bewertet wird, wofür ich 
vielleicht gar nichts kann.


Wahrscheinlich wird es jedoch a) gewesen sein, da der Newsletter erst 
vor 2 Tagen versendet worden ist und seitdem auch die Probleme auftreten.
Komischerweise gab es damals nie Probleme mit dem gleichen 
Newsletterversand, als ich den Server noch bei Hosteurope hatte.
Aber ok - ich habe nun von mehreren Seiten gehört, dass ein solch großer 
Newsletter durchaus ein Problem sein kann und habe den Newsletter nun 
auch umgehend gestoppt, um ihn künftig auf anderem Wege zu versenden, 
möglicherweise einen darauf spezialisierten Dienstleister.


Die Frage ist nun, wie ich die IP-Reputation wieder in Ordnung bringen 
kann.
Erledigt sich das üblicherweise innerhalb weniger Tage wieder von 
allein, oder ist die IP-Adresse nun für alle Zeit unbrauchbar, sodass 
ich den Server schnellstmöglichst umziehen sollte?
Wie groß ist der Einfluß von SPF und DKIM auf die Reputation? Ist das 
nice to have, oder heutzutage essentiell wichtig - wie seht ihr das?


Vielen Dank vorab für euren Rat.

Gruß
Markus




Hetzner hat immer mal wieder schlechte Reputation
da musst du dich bei den grossen extra freischalten lassen
DKIM usw sind wichtig und selbstverstaendlich heut zu Tage, aber die IP 
Reputation wird tatsaechlich

zumindest "auch" von Support Menschen betreut
Ein Umzug bringt per se wahrscheinlich nichts, Newsletter einem 
Spezialisten zu uebergeben ist ein gute Idee, aber 8500 kann man schon 
auch noch selbst machen, wenn man Erfahrung hat, Betreuung des Servers 
ist aber ein must have
das heisst man muss einen Versand monitoren, und dann eben die kaputten 
Empfaenger rauswerfen und sich die Ablehnungen ansehen und eben die div

Support Portale , postmaster Freischaltungen bemuehen

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Emails an T-Online mit eigener Domain und Postfix Server ohne Impressum macht Probleme

[Robert Schetterer]

Am 31.03.21 um 06:33 schrieb Florian Schaal:

Am 30.03.2021 um 18:24 schrieb Walter H.:

On 30.03.2021 16:24, maillistpostfixger...@mytelpbx.com wrote:

Hallo,
wollte an eine T-Online Adresse eine Email senden. Die kam zurück.
Begründung, sinngemäß Auszug aus den AGB und E-Mail Verkehr mit denen:
Ich hätte kein Impressum, meinen ich sollte eine Webseite aktivieren 
und dort Impressum anbieten für meine Domain.

das ist kompletter Quark, weil SMTP und HTTP sind 2 Paar Schuhe ...


Das mag sein, bei t-offline will aber für die Domain des Mail-Servers 
eine Webseite, "die eine Anbieterkennzeichnung mit sämtlichen 
Kontaktdaten beinhaltet."



korrekter MX PTR usw reicht nicht,


die Frage ist hier was Du mit 'usw' alles meinst?

SPF, DKIM, DMARC?

Gibt es noch andere Provider die so was machen, ist das stark im 
kommen oder wie soll ich das bewerten.

einfach vergessen;






Hi, wenn dem so ist , ist das voellig braindead, aber am Ende bleibt 
halt dann nix anderes als es umzusetzen.



--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Gibt es eine Beschränkung bei der Anzahl der Empfänger bei Einlieferung per SASL?

[Robert Schetterer]

Am 25.02.21 um 20:47 schrieb Markus Winkler:

Hallo Joachim,

On 25.02.21 19:43, j.burb...@jo-it.net wrote:
gerade eben hatte ich auch noch das gefunden da ich mir überlegt habe 
dass deren Programm vielleicht alles gleichzeitig schicken möchte.

smtpd_client_connection_count_limit (default: 50)


richtig.

Wenn ich Deine Ursprungsmail allerdings noch mal lese:


kurzfristig einige hunderte Mails auf dem Mail Gateway einliefern.


und nicht nur den Betreff, das klingt das vielleicht doch eher nach 
'smtpd_client_connection_count_limit'. Zumal, glaube ich, beim 
Überschreiten von 'default_destination_recipient_limit' dann einfach 
gesplittet wird. Muss ich direkt noch mal genauer lesen.


Du müsstest aber eigentlich schon anhand der bisherigen Versuche im Log 
sehen können, wie genau sich der einliefernde Client verhält und ob das 
ein Fall für 'smtpd_client_connection_count_limit' ist.


Schönen Abend und viele Grüße
Markus


Wobei man anmerken muss, dass man evtl das Einliefern via Sasl beschleunigen
kann ,das Ausliefern fuer gewoehnlich viel laenger dauert, typische 
Massenmailer haben grundsaetzlich ein Rate Limit, das heisst viele Mails 
duempeln dann auch schon mal einen Tag in der Warteschleife rum

und belasten das Gate

Fer Massenmails nimmt man deswegen typischerweise Software her
bei dem man das Einliefern zeitlich  steuern kann, zb 5 Mails pro min 
etc, geht natuerlich auch mit bash sleep und mail etc


--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: rbl spamhaus lehnt alle Mails ab

[Robert Schetterer]

Am 02.02.21 um 11:07 schrieb Bornholt Joerg:

Hallo Lars

Unglaublich und das durch Cisco, ich habe mich dann getraut und die RBL wieder 
aktiviert und siehe da, alles ist gut.

Vielen Dank

Jörg

-Ursprüngliche Nachricht-
Von: postfix-users 
 Im Auftrag von 
Lars Täuber
Gesendet: Dienstag, 2. Februar 2021 08:11
An: postfix-users@de.postfix.org
Betreff: Re: rbl spamhaus lehnt alle Mails ab

Hallo Jörg,

schau mal hier:
https://www.heise.de/news/Spamcop-verbaselt-seinen-Domainnamen-5042358.html

Grüße
Lars

Tue, 2 Feb 2021 06:52:32 +
Bornholt Joerg  ==> "postfix-users@de.postfix.org" 
 :

Hallo,

ich nutze seit über 10 Jahren postfix als relay für Exchange und
verwende auch die RBL's. wie z.B. die Liste von Spamhaus
(dbl.spamhaus.org). Am Samstag über das ganze Wochenende bis gestern
früh als ich dann die Einträge für die Backlist aus der Konfiguration
genommen habe, wurden alle Mails als gelistet abgelehnt. Ich habe überhaupt 
keinen Anhaltspunkt wonach ich suchen soll und ich würde die Liste schon gerne 
benutzen.
Vielleicht gab es ja so ein verhalten schon auf einem anderen System bei Euch?

Gruß

Jörg Bornholt






RBLS sollt man grundsaetzlich monitoren , vor allem ob man selbst drauf 
gelandet ist, weiter hilft dass nur auf bestimmte ips zb mit mehr als 3 
Punkte im dnsnamen usw anzuwenden, dann ist der Schaden nicht gleich so 
gross


hier ein checker

https://blog.sys4.de/xymon-rbl-check-script-de.html

gibts aber auch als reines script

wenn man den Alarm bekommt dass man selbst auf einer RBL ist , sollte 
man nachsehen was da los ist , und es sollte der Defekt bei einer RBL 
dann auch auffallen



--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: alte Mail-Clients und neue Server (SSLv3?)

[Robert Schetterer]

Am 25.11.2020 um 17:43 schrieb "Frank J. Dürring":

Hallo zusammen,

ich habe leider ein Problem mit alten Servern (Exchange 2010), 



https://docs.microsoft.com/de-de/microsoft-365/enterprise/exchange-2010-end-of-support?view=o365-worldwide

Exchange Server 2010 hat am 13. Oktober 2020das Ende der Unterstützung 
erreicht


ist natuerlich ein bekanntes Problem, du kannst natuerlich einen 
Workaround finden, aber wenn du jemand dis Schmerzen nimmst

wird er es hinausschieben


Kopier- und Mail-Clients (z.B. macOS 10.11 El Capitan) etc.
Ja ich weiß das diese Systeme nicht mehr supported werden, aber sie 
liegen *nicht* in einer Verwaltung und ich hab die Kunde bereits 
eindringlich darauf hingewiesen.


Mein Problem ist das Sie weiterhin E-Mails versenden möchten und mit 
meinem aktuellen Mailserver leider nicht mehr sprechen können, ich 
vermute es liegt am alten Encoding von SSLv3.
Jetzt möchte ich diese Kunden zumindest so gut es geht weiter versorgen, 
die Frage ist wie?


Der neue Mailserver hat diese Konfiguration (*main.cf)*
https://pastebin.com/PHCsWAbU 

Die Fehlermeldung sieht so aus:

Nov 16 19:15:07 mx10 dovecot: pop3-login: Disconnected (no auth 
attempts in 1 secs): user=<>, rip=217.92.555.555, lip=49.12.999.999, 
TLS handshaking: SSL_accept() failed: error:1420918C:SSL 
routines:tls_early_post_process_client_hello:version too low, 
session=


Wie macht ihr sowas?

  * Radikal die Kunden rauswerfen?
  * Die Konfiguration des (neuen) Mailservers aufweichen?
  * Einen zweiten Mailserver für altes Encoding bereitstellen?


Oder habe ich eine schlechte Konfiguration?
Das mag ich nicht ausschließen, wobei 95% meiner Kunden keinerlei 
Problem damit haben.


Danke und Gruß Frank.





--
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein

Re: smtpd_banner?

[Robert Schetterer]

Am 18.10.20 um 20:05 schrieb Walter H.:

Hallo,

Gute Frage,

woher kommt beim folgenden

telnet #SMTPSRVR 25
Trying #IPADDR...
Connected to #SMTPSRVR.
Escape character is '^]'.
220 #HOSTNAME ESMTP
ehlo me
250-#OTHERHOSTNAME
250-PIPELINING
250-SIZE 50331648
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250 8BITMIME
quit
221 2.0.0 Bye

der #OTHERHOSTNAME

#IPADDR ist die IP-Adresse von #SMTPSRVR,
#HOSTNAME ist im Parameter smtp_banner in der main.cf

smtpd_banner = #HOSTNAME ESMTP

f. den Fall, dass #OTHERHOSTNAME dem Parameter myhostname in der main.cf 
entspricht,
die Frage, kann ich hier einen DNS-Namen nehmen, welcher nicht ident mit 
eigentlich Servernamen ist?


Beispiel:  der Server heisst    hercules.example.com und hier würde ich 
z.B.


myhostname = mx01.example.com

setzen;

sowohl f. mx01.example.com als auch f. hercules.example.com existiert 
ein A/ Record im DNS


hingegen die IP(6)-Adressen bei den Parametern smtp_bind_address bzw. 
smtp_bind_address6 entsprechen

denen von hercules.example.com, und diese sind auch als rDNS verfügbar;

darf man das so machen?

ich würd meinen Server von einer krypt. Namensgebung eben auf z.B. 
hercules.example.com umbenennen;
die IPv6-Adresse vom Server (hercules.example.com)  ist nicht ident mit 
der vom SMTP-Server (mx01.example.com)


besten Dank f. Info;

Grüße,
Walter





smtpd_banner (default: $myhostname ESMTP $mail_name)

The text that follows the 220 status code in the SMTP greeting 
banner. Some people like to see the mail version advertised. By default, 
Postfix shows no version.


You MUST specify $myhostname at the start of the text. This is 
required by the SMTP protocol.


Example:

smtpd_banner = $myhostname ESMTP $mail_name ($mail_version)

mail_name (default: Postfix)

The mail system name that is displayed in Received: headers, in the 
SMTP greeting banner, and in bounced mail.


myhostname (default: see "postconf -d" output)

The internet hostname of this mail system. The default is to use 
the fully-qualified domain name (FQDN) from gethostname(), or to use the 
non-FQDN result from gethostname() and append ".$mydomain". $myhostname 
is used as a default value for many other configuration parameters.


Example:

myhostname = host.example.com

Hi , wenn ich mir das so durchlese kannst du
in smtpd_banner etwas anderes setzen als in myhostname
rein technisch ,ob das wirklich Sinn ergibt glaube ich nicht
im Zweifel besser beim default lassen, ich vermute das ist fuer 
Spezialfaelle gedacht


--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Google blockt Mails

[Robert Schetterer]

Am 04.03.19 um 19:08 schrieb Patrick Ben Koetter:

mir war bewusst, dass Dir das nicht gefallen würde und ich habe Deine Antwort
erwartet.

Ich bleibe dabei: Niemand darf die Mailingliste dazu nutzen, andere dazu
aufzurufen jemandem Schaden zuzufügen. Ob es möglich ist, tatsächlich auch
Schaden zu verursachen, ist dabei nicht von Bedeutung.

p@rick


ACK
ich bin zwar kein Jurist aber ich vermute mal wenn ein List Admin hier 
nicht einschreitet kann man ihn sogar belangen


Das wirkliche Problem ist die marktbeherrschende Stellung von Google und 
Co, ein handvoll Konzerne macht im Grunde was sie wollen


Das hier sollte aber eine technische Liste sein keine politische.

Das technische Problem wurde geloest ich denke keiner hat Beifall 
geklatscht...aber um mehr zu erreichen ist zumindest diese Liste nicht 
der richtige Platz da gibt es andere Foren



--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Warum DNSSEC wichtig ist!

[Robert Schetterer]

Am 01.03.19 um 21:17 schrieb Michael Ströder:

On 2/27/19 10:48 PM, Patrick Ben Koetter wrote:

Iranische Hacker haben im großen Stil E-Mail Passworte und andere, sensible
Daten verschiedener Regierungsorganisationen und privater Unternehmen
abgegriffen.
(mehr dazu: 
https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/)

Mit DNSSEC und DNSSEC-aktivierten Resolvern wie z.B. unbound, wäre das nicht
möglich gewesen.


Sorry, aber ich muss da ein wenig Wasser in den Wein giessen.

Vielleicht habe ich in o.g. Text was falsch verstanden, aber ich hätte
da durchaus ein paar ernste Fragen an den betroffenen Domain-Registrar.
Weil wenn der gehackt wird und der Angreifer dann die NS nebst DNSSEC
RRs austauschen kann, dann ist doch nix gewonnen.


Wenn du gehacked wirst ist das immer Mist , mit oder ohne DNSSEC oder 
mit was auch immer...



BTW: Mit dem Aufkommen der DNSSEC/DANE-Euphorie war bereits klar, dass
dann halt die Registrare und schlecht gewartete DNS-Server die
PKI-Schwachpunkte sind.

Das soll nicht heissen, dass man DNSSEC nicht einsetzen soll. Aber es
ist halt nicht der allein glücklich machende Ansatz und man muss es halt
genau wie bei X.509-basierter PKI *richtig* machen.

Ciao, Michael.




--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Google blockt Mails

[Robert Schetterer]

Am 01.03.19 um 19:24 schrieb J. Fahrner:

Am 2019-03-01 18:29, schrieb Patrick Ben Koetter:

Ich denke es ist nicht zulässig von "IPv6 wird bei mir abgelehnt" auf
"Mailprovider zu doof (...) IPv6 richtig zu implementieren" zu 
schliessen.


Sorry, aber als Diplom-Informatiker sehe ich das anders. IPv4 oder IPv6 
sind nichts anderes als Transportschichten. Semantisch DARF das keinen 
Unterschied machen. Wenn es das doch tut, dann ist auf einer Seite was 
faul. Meine Seite habe ich mittlerweile ausgeschlossen, auch reverse DNS 
ist sichergestellt. Von daher ist für mich, auch andere Berichte 
bestätigen das, eindeutig Google der Schuldige. Andere Mailhosts machen 
per IPv6 ja auch keine Probleme.


Ich bleibe bei meiner Meinung, Google ist "zu doof" !!!



Recht haben und Recht bekommen sind 2 paar Stiefel
predige ich jeden Tag an der UNI *g

Wenn dich google nervt dann blockiere sie halt ,niemand haelt dich auf

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Google blockt Mails

[Robert Schetterer]

Am 01.03.19 um 18:29 schrieb Patrick Ben Koetter:

* J. Fahrner :

Am 2019-03-01 09:32, schrieb lst_ho...@kwsoft.de:

Ist fast schon so lange wie wir IPv6 haben ein Problem. Bei Google
werden immer wieder IPv6 Verbindungen abgewiesen wenn sie ein
(temporäres) Problem mit der PTR Auflösung haben. Wir haben deshalb
schon seit Jahren einen IPv4 Only Transport für diese technischen
Leuchten.


Ehrlich gesagt ist mir das zu blöd, mein ganzes Postfix-Setup zu verhunzen,
nur weil ein Mailprovider zu doof ist IPv6 richtig zu implementieren. Auch
wenn der Google heisst.


doof passt in der Tat nicht, so wie ich das in Erinnerung habe
hat Google einfach strengere Antispam Regeln fuer IPv6, und das macht 
vermutlich aus deren Sicht auch Sinn, seit jeder Pfurz eine Ipv6 Adresse 
inkl smtp hat, werden die da vermutlich uebelst zugemuellt.


Der Eingriff um das in postfix zu umgehen ist minimal und durchaus 
vertretbar, da gibts wirklich schlimmeres





Ich denke es ist nicht zulässig von "IPv6 wird bei mir abgelehnt" auf
"Mailprovider zu doof (...) IPv6 richtig zu implementieren" zu schliessen. Bei
uns läuft google und IPv6 störungsfrei und ich bin sicher, wir haben keinen
Feenstaub über unserem Postfix ausgeschüttet.

Einen oder mehrere workaround-Transporte stellen – meine persönliche Meinung –
kein "Verhunzuen" dar. Ich denke es gibt einfach zu viel Spielraum für
Interpretation im SMTP-Standard und in E-Mails (MIME...), um von einer
einzigen Wahrheit ausgehen zu können.

Ich fahre deshalb den Ansatz, dass ich mich auf mein Ziel "ich will sicher
transportieren und mit hoher Wahrscheinlicheit zustellen" konzentriere. Ich
könnte auch "Recht haben", aber dann habe ich halt Recht und nichts
zugestellt.


Könnte man nicht im unbound irgendwas machen, damit für Google keine
-Records geliefert werden?


Möglicherweise. In Postfix hast Du sehr wahrscheinlich in viel kürzerer Zeit
eine Lösung umgesetzt.

My 2ct

p@rick




--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Google blockt Mails

[Robert Schetterer]

Am 28.02.19 um 13:16 schrieb J. Fahrner:
Neue Erkenntnis: wenn ich Postfix nur über ipv4 senden lasse, dann geht 
die Mail durch. Nur bei ipv6 werden sie geblockt.


ja das ist bekannt...schon seit Jahren so, bei ipv6 ist deren erkennung mist

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Google blockt Mails

[Robert Schetterer]

Am 28.02.19 um 13:33 schrieb J. Fahrner:

Am 2019-02-28 13:21, schrieb Boris Behrens:

Kein IPv6 ptr?


Doch.


Ich schicke an an google per se nur via ipv4
deren Spamerkennung auf ipv6 war zumindest mal sehr fehlerhaft


--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Bounces wegen voller Mailbox

[Robert Schetterer]

Am 09.02.19 um 10:15 schrieb J. Fahrner:

Am 2019-02-09 10:10, schrieb Thore Bödecker:

dazu am besten die Mail gar nicht erst annehmen und selbst Backscatter
generieren, sondern die Mail direkt ablehnen wenn das Postfach des
Empfängers bereits voll ist.

Dazu brauchst du im Postfix/MTA einen Quota-Check, der bei Dovecot
nachfragt.


Hört sich gut an, aber wie macht man das "bei Dovecot nachfragen"?

Jochen


https://wiki2.dovecot.org/Quota
https://blog.sys4.de/postfix-dovecot-mailbox-quota-en.html

ich hoffe das ist noch aktuell, ansonsten kann auch nur dovecot lmtp bei 
overquota endgueltig ablehnen ,das kann backscatter erzeugen, ist real 
aber selten


https://wiki.dovecot.org/LMTP

lmtp_rcpt_check_quota = yes enables quota checking already at RCPT TO stage

Da hab ich ich dich wohl vorher falsch verstanden , wie auch immer
loesche keine Postmaster mails automatisch ausser du kennst den 
Pappenheimer bereits


--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Bounces wegen voller Mailbox

[Robert Schetterer]

Am 09.02.19 um 09:49 schrieb J. Fahrner:

Hallo,
hat hier jemand eine Idee wie man das lösen kann?
Mein Sohn hat's nicht so mit aufräumen (kennen wohl alle Väter), und 
damit er mir nicht meinen Server vollmüllt habe ich ein Quota auf seine 
Mailbox gelegt.
Nun kommt es natürlich immer wieder mal vor, dass die voll ist, und 
Dovecot verschickt Reject-Meldungen an den Absender. Nun werden aber 
viele Newsletter und so Zeugs mit Adressen verschickt, an die man nix 
senden kann. Das hat dann häufig zur Folge, dass der Postmaster (also 
ich) eine Bounce-Meldung von denen bekommt. Das nervt. Wie verhindere 
ich das?


Du kannst bei bereits bekannten Absendern in der Postmaster Mailbox 
mittels lokalen Filter mails ungelesen loeschen


Alles andere wuerde ich nicht empfehlen...
bounces haben technisch ja einen Sinn insofern muss ein postmaster damit 
einfach leben,


im Grunde sollte dich das so nerven dass du deinen Sohn nervst dass er 
aufraeumt...




Jochen





--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Reverse DNS umgehen

[Robert Schetterer]

Am 21.11.18 um 10:26 schrieb Jan Friedrichs:
evtl. hat der Host auch 2 PTRs gesetzt. Das führt zu dem beschriebenen 
Fehlerbild.


jo das ist wirkt wie "wuerfeln"



Grüße Jan

 Ursprüngliche Nachricht 
Von: Tobi 
Datum: 21.11.18 09:33 (GMT+01:00)
An: postfix-users@de.postfix.org
Betreff: Re: Reverse DNS umgehen

Grundsätzlich liesse sich das sicher durch eine access map
(smtpd_client_restrictions) lösen, die VOR dem
reject_unknown_reverse_client_hostname steht.

Allerdings würde ich erst mal analysieren, warum es manchmal geht und
manchmal ned. Ist es dein lokaler Resolver, der Probleme macht? Oder die
zuständigen DNS Server für die Reverse Zone?

Gruss

tobi

Am 21.11.18 um 08:16 schrieb mirco...@arcor.de:
 > Hallo
 >
 > gibt es im Postfix eine Möglichkeit für einzelne Reverse DNS Abfragen zu
 > deaktivieren. Habe Monentan das Problem das manchmal der Reverse Name 
stimmt und
 > manchmal nicht obwohl der Absender der gleiche ist! Genauer gesagt 
früh kommt
 > die mail nicht durch (cannot find your reverse hostname) und Mittag 
funktioniert es?

 >
 > VG Mirco
 >



--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: abuse-Reporting verbessern

[Robert Schetterer]

Am 11.09.2018 um 13:36 schrieb Patrick Ben Koetter:
> * Kai Fürstenberg :
>> Am 11.09.2018 um 12:06 schrieb Patrick Ben Koetter:
>>> Postmaster aufgepasst!
>>>
>>> Ihr wollt *bitte* die Absenderadresse repo...@reports.cert-bund.de
>>> whitelisten. So kann das Cert Bund Euch und den Ownern von Domains, die ihr
>>> hostet, abuse-Nachrichten zusenden. Damit helft ihr abuse wirkungsvoller
>>> einzudämmen. Das BSI bittet darum, dieses whitelisting einzubauen.
>>
>> Dann soll ich also den nächsten Casino-Spam aus der Ukraine einfach
>> durchlassen, wenn diese Adresse als Absender verwendet wird, ... ja nee,
>> is klar.
>>
>> Jetzt aber mal ehrlich. Warum bitte sollte ich eine Absenderadresse
>> whitelisten, wo doch bekannt ist, dass Adressen gefälscht sein können?
>>
>> Den zugehörigen Host kann ich im Postscreen whitelisten und auch von den
>> übrigen checks ausnehmen. Habe ich kein Problem mit. Aber die
>> Absenderadresse...?
> 
> Die Mails von repo...@reports.cert-bund.de werden über den Host
> reportsmx.cert-bund.de versendet. Er besitzt eine IPv4, die ihr whitelisten
> könnt. Eine IPv6 besitzt er nicht:
> 
> [p@x1 ~]$ dig A reportsmx.cert-bund.de +short
> 194.94.208.36
> [p@x1 ~]$ dig  reportsmx.cert-bund.de +short
> 
> Die Domain hat zusätzlich einen SPF-Record, der auch auf den
> reportsmx.cert-bund.de verweist:
> 
> [p@x1 ~]$ dig TXT reports.cert-bund.de +short
> "google-site-verification=COs-ESeFBr7uef1s5FdHsK6KdAyfro5pSH3mQP-clBY"
> "v=spf1 mx ip4:194.94.208.36 -all"
> 
> Wer die Envelope-Sender-Adresse in der Postfix SMTP Session whitelisten möchte
> kann das wie folgt (Beispiel) tun:
> 
> smtpd_sender_restrictions=
> ...
> hash:/etc/postfix/cert-bund
> 
> Und dann in /etc/postfix/cert-bund:
> repo...@reports.cert-bund.deOK
> 
> Wer die Adresse in SpamAssassin whitelisten möchte trägt z.b. in die local.cf
> folgendes ein:
> 
> whitelist_from_rcvd repo...@reports.cert-bund.de reportsmx.cert-bund.de
> 
> Damit werden E-Mails gewhitelistet, die über den Host reportsmx.cert-bund.de
> versendet wurden *und* die von der Absenderadresse
> repo...@reports.cert-bund.de stammen.
> 
> p@rick
> 

whitelisting ist kein Problem, hoffentlich lohnt es sich dann am Schluss
auch.


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Postfixadmin mit Postfix als Smarthost

[Robert Schetterer]

Am 06.09.2018 um 13:49 schrieb zyrixx:

Hallo Robert,

ich würde es gerne einsetzen, da ich bisher nur die herkömmlichen Files 
per Hand bearbeite und diese immer größer werden. So richtig 
übersichtlich ist das nicht. Mein Gespann besteht nach wie vor aus 
Fetchmail(das wäre eine zusätzliche Baustelle), Dovecot und Postfix.


Also von Fetchmail moechte ich dringend abraten, nimm getmail das ist 
wesentlich einfacher und besser


siehe

https://blog.sys4.de/abholdienst-fur-mail-de.html

ansonsten kenn ich ja dein Setup nicht , aber fuer smart host
habe ich die Dateien auch schon via webmin editiert, das ist weniger 
Aufwand als postfixadmin




Würde mir deine Anleitung, an die ich mich in den nächsten Tagen 
ranmachen werde, helfen, wäre das super. Und ja, dieses Setting ist 
tatsächlich nach wie vor sehr verbreitet, gerade als Exchangeersatz.


Am 06.09.2018 um 13:36 schrieb Robert Schetterer:

Am 06.09.2018 um 13:03 schrieb zyrixx:
Hallo, ist es möglich, Postfixadmin auf einem Postfix zu betreiben, 
der nur als Smarthost fungiert? viele Grüße Zyrixx



Ja sicher die Frage ist ob und wie du es dann einsetzt
Ich hatte es sogar mal in kombinierter Form, ist aber ein wenig 
umstaendlich



https://blog.sys4.de/postfix-transport-fuer-mailboxen-uber-postfixadmin-de.html 



https://blog.sys4.de/postfix-transport-fuer-mailboxen-uber-postfixadmin-2-de.html 








--
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Postfixadmin mit Postfix als Smarthost

[Robert Schetterer]

Am 06.09.2018 um 13:03 schrieb zyrixx:
Hallo, ist es möglich, Postfixadmin auf einem Postfix zu betreiben, der 
nur als Smarthost fungiert? viele Grüße Zyrixx



Ja sicher die Frage ist ob und wie du es dann einsetzt
Ich hatte es sogar mal in kombinierter Form, ist aber ein wenig umstaendlich


https://blog.sys4.de/postfix-transport-fuer-mailboxen-uber-postfixadmin-de.html

https://blog.sys4.de/postfix-transport-fuer-mailboxen-uber-postfixadmin-2-de.html

--
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Spam von gmail.com und yahoo

[Robert Schetterer]

Am 03.09.2018 um 13:46 schrieb J. Fahrner:
> Am 2018-09-03 13:36, schrieb Walter H.:
>> habe schon echten SPAM bekommen, der einen List-Id drin hatte; kann sein,
>> daß man auf die Art manche False Positives nicht blockt und kann sein daß
>> man auf die Art echten SPAM durchläßt;
>>
>> Postfix + Sieve -> wie geht das am einfachsten?
> 
> Wenn schon, dann dürfte man nur List-Ids zulassen die man auch abonniert
> hat. Optimal ist das aber nicht, jedesmal die Postfix Config ändern zu
> müssen wenn man eine neue Liste abonniert.
> 
> Am besten gefällt mir Roberts Vorschlag, From: und Reply-To: zu
> vergleichen. Nur wenn beides Freemail ist und sie sich unterscheiden,
> dann blocken. Kriegt man aber mit header_checks nicht hin. Müsste man
> irgendwie ins Spamassassin reinbasteln oder in rspamd. Da mir SA bisher
> nie so richtig gefallen hat (Konfiguration komplex und unübersichtlich,
> und Trefferrate schlecht) stelle ich gerade auf rspamd um. Muss mich da
> aber erst reinfuchsen.
> 
> Jochen

rspamd ist sicher eine gute Wahl

Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Spam von gmail.com und yahoo

[Robert Schetterer]

Am 03.09.2018 um 13:36 schrieb Walter H.:
> On Sun, September 2, 2018 22:50, Robert Schetterer wrote:
>> mit sieve wuerde man einfach alles ausnehmen was List-Id enthaelt, muss
>> am Ende jeder selbst wissen wie und ob er das will
>>
> habe schon echten SPAM bekommen, der einen List-Id drin hatte; kann sein,
> daß man auf die Art manche False Positives nicht blockt und kann sein daß
> man auf die Art echten SPAM durchläßt;
> 
> Postfix + Sieve -> wie geht das am einfachsten?
> 

Also eine Welt ohne Spam gibts einfach nicht.
Normalerweise versucht man halt in postfix , spamassassin, clamav das
meisste schon mal rauszufangen, hat man dovecot mit sieve kann man
danach entweder global und/oder per user sieve regeln einrichten.

Der wesentliche Punkt ist ob der Mailserver viele div domains bedienen
muss oder nicht. Gehts nur um eigene domains kann man natuerlich
strikter verfahren. Sieve ist halt gut so zu konfigurieren, dass jeder
User z.b in einem webmail seine eigenen Regeln machen kann. Das geht
natuerlich auch in spamassassin ist aber so kompliziert das die meisten
user mit Regeln scheitern werden die ueber ein simples white und
blacklisting hinausgehen. Hier ging es ja um das filtern des reply to,
da es sich da um ein "legales Verfahren" handelt ist es vermutlich ein
gute Idee es im per User level zu konfigurieren, bzw es in spamassassin
wie bereits hier beschrieben in der Freemail Regel hoeher zu bewerten.





Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Spam von gmail.com und yahoo

[Robert Schetterer]

Am 02.09.2018 um 21:03 schrieb J. Fahrner:
> Am 2018-09-02 16:12, schrieb Walter H.:
>>> ich wuerde per se Mail Lists ausnehmen
>>>
>>>
>> Ja, diese sind bei mir oben unter #handverlesene liste# inkludiert
> 
> Deine #handverlesene liste# betrifft aber nur das reply-to. Das hilft
> dir nicht wenn irgendsoein Esel mit reply-to freemail in die Liste
> postet. Da bräuchte man ein whitelisting von Listen das vorher schon
> greift.
> 
> Jochen

mit sieve wuerde man einfach alles ausnehmen was List-Id enthaelt, muss
am Ende jeder selbst wissen wie und ob er das will


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Spam von gmail.com und yahoo

[Robert Schetterer]

Am 01.09.2018 um 15:23 schrieb J. Fahrner:
> Am 2018-08-25 09:49, schrieb Walter H.:
>> hier diese header_checks-Regel, wie ich sie habe ...
>>
>> if /^reply-to:[[:space:]].*$/
>> /^reply-to:[[:space:]][[:print:]]*(\<)?[[:alnum:]_\.\-]+\@(aol\.com|mail\.ru|sms\.at|web\.de|googlemail\.com|gmail\.com|rocketmail\.com|qq\.com|(gmx|hotmail|msn|outlook|yahoo|ymail)[[:alpha:]\.]+)(\>)?.*$/
>>
>>     REJECT 5.7.1 Mail is SPAM. Freemail 'reply-to' ($2) not accepted.
>> /^reply-to:[[:space:]][[:print:]]*(\<)?(#handverlesene liste#)(\>)?.*$/
>>     OK
>> # tld .at, .de, .eu ist erlaubt
>> /^reply-to:[[:space:]][[:print:]]*(\<)?[[:alnum:]_\.\-]+\@[[:alnum:]_\.\-]+\.(at|de|eu)(\>)?.*$/
>>
>>     OK
>> /^reply-to:[[:space:]][[:print:]]*(\<)?[[:alnum:]_\.\-]+\@[[:alnum:]_\.\-]+(\>)?.*$/
>>
>>     REJECT 5.7.1 Mail is SPAM. Unknown 'reply-to' not accepted.
>> endif
>>
>> es gibt für mich keinen sinnvollen use case, der die notwendigkeit
>> eines reply-to's zwingend notwendig macht ...
> 
> Heute hat die erste Regel 2 mal zugeschlagen. Einmal war es wirklich
> SPAM, das zweite Mal kam die Mail offensichtlich von einer abonnierten
> Mailingliste. Wobei mir nicht ganz klar ist was das soll. Wieso taucht
> in einer Mailingliste ein Reply-To an eine gmail-Adresse auf? Wenn ich
> antworte, dann will ich doch an die Liste antworten. Das scheint mir
> wohl ein Bug der Mailingliste zu sein, wenn die sowas überhaupt zulässt.
> Das macht ja keinen Sinn.
> 
> Jochen

ich wuerde per se Mail Lists ausnehmen


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Spam von gmail.com und yahoo

[Robert Schetterer]

Am 26.08.2018 um 09:23 schrieb Alexander Dick:
> Hallo zusammen,
> 
> möchte nur kurz einwerfen, dass unterschiedliche Adressen in From und
> Reply-To durchaus seine Berechtigung haben können. Beispielsweise bei
> Mails die über ein Kontaktformular auf einer Website generiert und "im
> Namen des Gastes" an den Seitenbetreiber geschickt werden. Hier setzen
> wir immer die Adresse des Gastes ins Reply-To und setzen als From
> noreply@... ein. Denn der Webserver bzw der dahinterliegende Mailserver
> ist ja nicht dazu berechtigt, beispielsweise Mails von der Domain gmx.de
> <http://gmx.de> zu versenden (SPF).
> 
> Grüße
> Alexander

Hi, das duerfte den meisten hier bekannt sein, aber wer sein Geschaeft
ernst meint sollte dann schon nicht ueber einen der bekannten Freemailer
ausliefern, die paar Euro fuer ein anderes relay sollten wirklich drinn
sein.

> 
> Gesendet mit BlueMail <http://www.bluemail.me/r?b=13187>
> Am 26. Aug. 2018, um 08:56, "J. Fahrner"  <mailto:j...@fahrner.name>> schrieb:
> 
> Am 2018-08-25 09:48, schrieb Robert Schetterer:
> 
> Ich greif diese Idee nochmal auf ,gleich ein Liste
> von Freemailern zu nutzen und entweder in einen extra Ordner filtern
> oder mit einer Message gleich ganz abzulehnen
> wenn Reply-To und From nicht gleich sind find ich ganz brauchbar
> am coolsten ist das in spamassassin um das ueber das default Tag
> level
> zu hieven, oder mit sieve
> 
> 
> Das mit dem spamfence.net <http://spamfence.net> hat sich schon wieder 
> erledigt, die 2 Mails 
> von Robert wurden gleich mal als Spam aussortiert. :-(
> 
> Ich versuche mal ob ich das als Rule für Spamassassin hinbekomme. Hab 
> sowas leider noch nie gemacht.
> 
> Jochen
> 



Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Spam von gmail.com und yahoo

[Robert Schetterer]

Am 26.08.2018 um 08:59 schrieb J. Fahrner:
> Am 2018-08-25 09:48, schrieb Robert Schetterer:
>> Ich greif diese Idee nochmal auf ,gleich ein Liste
>> von Freemailern zu nutzen und entweder in einen extra Ordner filtern
>> oder mit einer Message gleich ganz abzulehnen
>> wenn Reply-To und From nicht gleich sind find ich ganz brauchbar
>> am coolsten ist das in spamassassin um das ueber das default Tag level
>> zu hieven, oder mit sieve
> 
> Das mit dem spamfence.net hat sich schon wieder erledigt, die 2 Mails
> von Robert wurden gleich mal als Spam aussortiert. :-(
> 
> Ich versuche mal ob ich das als Rule für Spamassassin hinbekomme. Hab
> sowas leider noch nie gemacht.
> 
> Jochen
> 

Hi, man muss auch reichlich Vertrauen haben wenn man
seine Mails ueber extern filtern laesst. Im Grund kann man dann auch
gleich zu den Freemailern wechseln.


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Spam von gmail.com und yahoo

[Robert Schetterer]

Am 25.08.2018 um 09:49 schrieb Walter H.:
> On 25.08.2018 08:17, J. Fahrner wrote:
>> Am 2018-08-24 19:22, schrieb Walter H.:
>>
>>> Du könntest nach einem Reply-to im Header prüfen, und wenn der eine
>>> Freemail-Domain ist => Reject, genau das mach ich nämlich;
>>> wobei ich lass nur ein Reply-to von einer handverlesenen liste an
>>> Domains zu ...
>>
>> Das versteh ich jetzt nicht. Reply-to ist doch ein optionaler Header,
>> wieso sollte der Spam identifizieren können?
> stimmt der Header ist optional, und sämtlicher SPAM den ich bekam,
> hatte im Reply-to  eine Mailadresse eines Freemail hosters wie
> - yahoo
> - google (gmail)
> - hotmail, outlook, msn
> ...
> da ich aber umgekehrt vorgehe, ich erlaube wenn ein reply-to vorkommt nur
> eine handverlesene liste an domains ..., kommt da auch kein SPAM durch
> 
> hier diese header_checks-Regel, wie ich sie habe ...
> 
> if /^reply-to:[[:space:]].*$/
> /^reply-to:[[:space:]][[:print:]]*(\<)?[[:alnum:]_\.\-]+\@(aol\.com|mail\.ru|sms\.at|web\.de|googlemail\.com|gmail\.com|rocketmail\.com|qq\.com|(gmx|hotmail|msn|outlook|yahoo|ymail)[[:alpha:]\.]+)(\>)?.*$/
> 
>     REJECT 5.7.1 Mail is SPAM. Freemail 'reply-to' ($2) not accepted.
> /^reply-to:[[:space:]][[:print:]]*(\<)?(#handverlesene liste#)(\>)?.*$/
>     OK
> # tld .at, .de, .eu ist erlaubt
> /^reply-to:[[:space:]][[:print:]]*(\<)?[[:alnum:]_\.\-]+\@[[:alnum:]_\.\-]+\.(at|de|eu)(\>)?.*$/
> 
>     OK
> /^reply-to:[[:space:]][[:print:]]*(\<)?[[:alnum:]_\.\-]+\@[[:alnum:]_\.\-]+(\>)?.*$/
> 
>     REJECT 5.7.1 Mail is SPAM. Unknown 'reply-to' not accepted.
> endif
> 
> es gibt für mich keinen sinnvollen use case, der die notwendigkeit eines
> reply-to's zwingend notwendig macht ...
> 
> Grüße,
> Walter
> 
cool
eine Ausnahme fuer/mit  List-Id besonders fuer yahoo waere evtl sinnvoll


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Spam von gmail.com und yahoo

[Robert Schetterer]

Am 25.08.2018 um 09:33 schrieb Robert Schetterer:
> Am 24.08.2018 um 17:28 schrieb J. Fahrner:
>> Am 2018-08-24 17:03, schrieb Robert Schetterer:
>>
>>> Ich kann vermehrten Spam von google nicht bestaetigen
>>
>> Komisch. Ich krieg da jetzt alles Mögliche, Betreffs wie "How are you
>> doing", oder irgendwas mit Bitcoin, kein erkennbares Muster drin. Und
>> immer andere gmail Absender.
>>
>> Betroffen ist nur meine eine Mailadresse, die ich praktisch überall
>> öffentlich im Internet verwende, Online-Shops, Foren, und auch hier in
>> der Liste. Meine Private Adresse ist davon bisher nicht betroffen.
>>
>> Ich leite meine öffentliche Adresse jetzt mal über spamfence.net, mal
>> sehen ob das Besserung bringt. Wie gesagt, Spamassassin enttäuscht mich.
>>
>> Jochen
> 
> ging auch an dich offlist
> 
> ein Match wenn von google und Absender und Reply to
> Adresse ungleich dann spam folder, das wuerde dann mit sieve gehen
> 
> aus deiner mail
> 
> Reply-To: barredwincla...@gmail.com
> From: Edwin Clark 
> 
> etwas unscharf aber sollte auf die Schnelle schon mal helfen
> 
> 
> Best Regards
> MfG Robert Schetterer
> 

Ich greif diese Idee nochmal auf ,gleich ein Liste
von Freemailern zu nutzen und entweder in einen extra Ordner filtern
oder mit einer Message gleich ganz abzulehnen
wenn Reply-To und From nicht gleich sind find ich ganz brauchbar
am coolsten ist das in spamassassin um das ueber das default Tag level
zu hieven, oder mit sieve


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Spam von gmail.com und yahoo

[Robert Schetterer]

Am 24.08.2018 um 17:28 schrieb J. Fahrner:
> Am 2018-08-24 17:03, schrieb Robert Schetterer:
> 
>> Ich kann vermehrten Spam von google nicht bestaetigen
> 
> Komisch. Ich krieg da jetzt alles Mögliche, Betreffs wie "How are you
> doing", oder irgendwas mit Bitcoin, kein erkennbares Muster drin. Und
> immer andere gmail Absender.
> 
> Betroffen ist nur meine eine Mailadresse, die ich praktisch überall
> öffentlich im Internet verwende, Online-Shops, Foren, und auch hier in
> der Liste. Meine Private Adresse ist davon bisher nicht betroffen.
> 
> Ich leite meine öffentliche Adresse jetzt mal über spamfence.net, mal
> sehen ob das Besserung bringt. Wie gesagt, Spamassassin enttäuscht mich.
> 
> Jochen

ging auch an dich offlist

ein Match wenn von google und Absender und Reply to
Adresse ungleich dann spam folder, das wuerde dann mit sieve gehen

aus deiner mail

Reply-To: barredwincla...@gmail.com
From: Edwin Clark 

etwas unscharf aber sollte auf die Schnelle schon mal helfen


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Spam von gmail.com und yahoo

[Robert Schetterer]

Am 24.08.2018 um 16:41 schrieb J. Fahrner:
> Hallo Liste,
> 
> ich bekomme in letzter Zeit vermehrt Spam von gmail.com Adressen sowie
> yahoo. Ich habe den Eindruck, diese Firmen kämpfen in letzter Zeit mehr
> gegen "Hatespeech" als gegen Spam. Das Schlimme: Blacklists sind hier
> wirkungslos, und auch Spamassassin versagt da völlig (mit SA habe ich
> ohnehin keine guten Erfahrungen, was nicht durch DNS Blacklists geblockt
> wird passiert auch SA mühelos. Kann ich glaub ich rauswerfen).
> 
> Habt ihr Ideen wie man gegen den gmail Spam vorgehen könnte? Notfalls
> müsste ich eine Sieve-Regel anlegen die *@gmail.com automatisch in den
> Spamordner verschiebt. Irgendwie nervt das nämlich.
> 
> Jochen
> 
> 

Ich kann vermehrten Spam von google nicht bestaetigen
und das Einzige was mir einfallen wuerde waere sozusagen
eine extra harte Antispampruefung  fuer google Mails einzufuehren.
Technisch gibts da mehrere Moeglichkeiten aber an spamassassin etc
kommst du nicht vorbei, wenn wiederkehrende Schlagworte dabei sind geht
evtl auch header oder body checks


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Could not change Return-Path

[Robert Schetterer]

Am 28.05.2018 um 21:13 schrieb Jamie Katharina Knuth:
> am 28.05.18, 20:17 schrieb Robert Schetterer :
> 
> 
>>> postfix-local[15783]: Could not change Return-Path in message
>>> envelope(SRS): No at sign in sender address
> 
>>
>> SRS ist keine native postfix funktion, und ich wuerde die Nutzung auch
>> nicht empfehlen
>>
>> wie hast du das denn eingebunden zb wie hier ?
> 
> 
> ich traue es mir gar nicht zu sagen ..
> Das kommt von Plesk wahrscheinlich. :-/
>>
>> https://christophfischer.com/linux/15-mailserver/56-sender-rewriting-scheme-srs-fuer-postfix-unter-debian
>>
>>
>> brauchst du das wirklich ?
> 
> nee, kenne ich bis dato überhaupt nicht. ;)
> 

wenn du es nicht brauchst . schalt es ab. Sollte es mit Plesk kommen
frag auf deren Liste wie man das macht


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Could not change Return-Path

[Robert Schetterer]

Am 28.05.2018 um 19:57 schrieb Jamie Katharina Knuth:
> Hallo, ich habe hier seit kurzem folgendes im Log
> 
> postfix-local[15783]: Could not change Return-Path in message
> envelope(SRS): No at sign in sender address
> 
> postconf -n liefere ich sofort nach, wenn gewünscht. ;)
> 

SRS ist keine native postfix funktion, und ich wuerde die Nutzung auch
nicht empfehlen

wie hast du das denn eingebunden zb wie hier ?

https://christophfischer.com/linux/15-mailserver/56-sender-rewriting-scheme-srs-fuer-postfix-unter-debian

brauchst du das wirklich ?


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: #efail

[Robert Schetterer]

Am 14.05.2018 um 17:46 schrieb J. Fahrner:
> Mit DKIM signierten Mails sollte das doch eigentlich nicht zum Problem
> werden, oder?
> https://www.heise.de/security/artikel/PGP-und-S-MIME-So-funktioniert-efail-4048873.html
> 
> 
> LG Jochen

hm grad erst eingelesen..
ich seh jetzt keinen direkten Zusammenhang, es geht ja um "man in the
middle", ich stell mir das erstmal so vor, der Boese will doch nicht
entdeckt werden d.h er wird zunaechst ein Kopie herstellen/ausleiten
damit du nicht mitbekommst dass er mitliest. Er arbeitet dann mit der
Kopie und wendet efail an. Insofern wirst du via DKIM keine Manipulation
feststellen koennen.

Der wesentliche Punkt ist also erstmal die Uebermittlung und Speicherung
der Mail muss moeglichst sicher sein. Das immer sicherzustellen ist per
se schon gar nicht so einfach. Beim Transport sollte dann dane state of
the art sein, aber bei den Mail clients wird dann schon haarig.
Thunderbird und die neueste Enigmailversion mit gpg "sollen" halbwegs
gepatched sein.

In jedem Fall keine guten Nachrichten, aber wenn man genau nachliest nun
auch nicht wirklich so ueberraschend. Zufrieden mit smime/gpg usw konnte
man schon frueher nicht sein aber auf den anderen Seite ich sehe keine
grundsaetzlich bessere Idee/Verfahren. Die Berichterstattung empfinde
ich etwas zu sensationsgetrieben , von der Sorte "seht Email ist einfach
nicht mehr zu retten"



Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: DMARC: Sinnvoll oder nicht?

[Robert Schetterer]

Am 10.03.2018 um 15:53 schrieb Walter H.:
> On 10.03.2018 08:38, Patrick Ben Koetter wrote:
>> * Walter H.<walte...@mathemainzel.info>:
>>> On 08.03.2018 16:03, Patrick Ben Koetter wrote:
>>>> * Marco Dickert<ma...@misterunknown.de>:
>>>>> -
>>>>> $ dig _dmarc.sys4.de TXT +short
>>>>> "v=DMARC1; p=none;"
>>>>> -
>>>> Es ist kein Dummy. Den habe ich mit Absicht gesetzt. Die Policy lautet:
>>>>
>>>>   Ja, wir kennen DMARC
>>>>   Ja, wir haben eine DMARC-Policy
>>>>   Die Policy lautet: Wir machen nichts.
>>>>
>>>>
>>> wodurch unterscheidet sich diese Policy, die ihr angegeben habt
>>> von jeder, welche z.B. so lautet
>>>
>>> "v=DMARC1; p=none; ruf=mailaddr; rua=mailaddr;"
>> Mit $ruf und $rua teilst Du DMARC-Prüfenden mit, wohin sie _r_eports
>> senden
>> sollen. Der $ruf ist für _f_ailure reports und der $rua für
>> _a_ggregierte Reports.
> und was teile ich denen mit wenn dies mit p=none angegeben ist?
> (darauf wollte ich hinaus)

https://dmarc.org/wiki/FAQ#Does_DMARC_.E2.80.9Cp.3Dnone.E2.80.9D_affect_the_way_my_emails_get_delivered.3F

> 
> sprich der Unterschied zu eurer Policy, denn eure sagt, daß ihr nichts
> macht;
> und was macht dann diese?
>> Beim Reporten musst Du darauf achten, *was* Du mitteilst, denn einige
>> Daten,
>> wie z.B. die IP-Adresse, sind aus Sicht des dt. Datenschutzes
>> personenbezogene
>> Merkmale.
> meiner Meinung sind die Reports Käse, denn f. Menschen lesbar sieht
> anders aus zum einem und zum anderen
> so wie DMARC definiert ist, kann es nicht herhalten einen
> eingeschriebenen Brief mit Rückschein nachzubilden ...
>> Wenn Du DMARC testweise warmfahren willst, ist die Angabe einer
>> report-Adresse
>> sinnvoll, denn dann kannst Du sehen, welche Verstösse andere
>> wahrnehmen und
>> dann ggf. von einer DMARC-policy Abstand nehmen oder die Plattform so
>> anpassen, dass es zu keinen oder weniger Verstössen kommt.

> ich hab ein Autoreply mit dem Inhalt, daß es mich nicht interessiert :-)

da dir das eine Software schickt wird das nicht gelesen
nutze die richtige Policy oder schmeiss den Bericht per sieve weg, ich
wuerde empfehlen ihn weg zu sortieren und nach 7 Tagen etc auto zu
loeschen, es kann schon sinnvoll sein zu wissen wie oft deine domain
gefaked wird, aber ich gebe zu ist eher selten sinnvoll


> 
> 



Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Hardwareanforderungen an einen Postfix Server

[Robert Schetterer]

Am 19.02.2018 um 12:37 schrieb Herzberger, Patrick, ICS:
> RAM und CPU sind beim reinen Versand nicht wirklich das Thema.
> 
> Auch nicht wenn die Mails DKIM signiert werden.
> 
> Ich würde allerdings auf die Mailqueue aufpassen und diese richtig
> dimensionieren, sodass zur Not ( bei Rückstau ) ALLE Mails einer
> Kampagne Platz haben.
> 
> Allerdings kommt es auch darauf an wie die Mail generiert werden.
> 
>  
> 
> lG
> 
>  
> 
> Patrick
> 
>  
> 
> *Von:*postfix-users
> [mailto:postfix-users-bounces+patrick.herzberger=ics-informationsystems@de.postfix.org]
> *Im Auftrag von *MS Exchange
> *Gesendet:* Montag, 19. Februar 2018 12:21
> *An:* Bastian Heinrich <bastian.heinr...@jin42.de>
> *Cc:* Postfix users <postfix-users@de.postfix.org>
> *Betreff:* Re: Hardwareanforderungen an einen Postfix Server
> 
>  
> 
> Hallo Bastian!
> 
>  
> 
> Danke für deine Antwort.
> 
> Derzeit gehen wir Mal von 150.000 Mails mit jeweils 100 bis 200 kB aus.
> 
>  
> 
> LG
> 
> Gerald
> 
>  
> 
>  
> 
> Am 19.02.2018 12:16 nachm. schrieb "Bastian Heinrich"
> <bastian.heinr...@jin42.de <mailto:bastian.heinr...@jin42.de>>:
> 
> Hallo Gerald,
> 
> über was für Email-Mengen reden wir denn hier (und wie groß sind die
> jeweils)?
> 
> Ansonsten meine Postfix-Server haben jeweils 256 MB Ram und 1 vCPU, und
> laufen damit ohne Probleme.
> Insofern: Wenn ihr einen Hardware-Server wollt, tut es praktisch jeder
> handelsüblicher Server.
> 
> MfG
> Bastian
> 
> 
> On 19.02.2018 08:36, MS Exchange wrote:
> > Hallo!
> >
> > Wir wollen für den Newsletter versandt einen Postfix Server
> aufbauen, der
> > rein für outbound Mails gedacht sein soll.
> > Da Postfix derzeit bei uns nicht eingesetzt wird, fehlen uns hier die
> > Erfahrungswerte. Leider konnte ich online auch kaum Informationen
> darüber
> > finden was die Anforderungen an die Hardware sind.
> > Daher bitte ich euch um Input.
> >
> > Vielen Dank!
> >
> > LG
> > Gerald
> >
> 
>  
> 

Hi, je nachdem wie deine weiteren Anforderungen
sind wuerde ich mir stark ueberlegen sich diesen Service extern einzukaufen.
Hardware ist da nicht wirklich die Herausforderung sondern ob du deine
Mails auch regelmaessig pro gewuenschten Zeitlimit los wirst ohne dabei
haeufig als Spamsender gelistet zu werden, dazu gehoert dann auch ein
gutes Bounce und Adressen Management ,Opt out usw. Das frisst Zeit ...
Es gibt dafuer gute deutsche Dienstleister zusaetzlich gibts da auch
Tools um Kampangien auszuwerten.



Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Authentifizierung in Thunderbird "Verschlüsseltes Passwort"

[Robert Schetterer]

Am 29.12.2017 um 16:31 schrieb Walter H.:
> On 29.12.2017 08:50, Patrick Ben Koetter wrote:
>> * Walter H.<walte...@mathemainzel.info>:
>>> On 28.12.2017 22:11, Patrick Ben Koetter wrote:
>>>> * Frank Röhm<francwal...@gmx.net>:
>>>>> Im Moment muss ich ja "Passwort, normal" auswählen, damit es geht.
>>>>> Das ist
>>>>> ja auch nicht optimal.
>>>> Es ist optimal, auch wenn es auf den ersten Blick nicht so wirkt,
>>>> *solange* Du
>>>> STARTTLS vor dem AUTH erzwingst.
>>>>
>>>> Wenn Du eine TLS-verschlüsselte Verbindung erzwingst (nur auf Port
>>>> 587) sind
>>> nicht ganz;
>>> Port 587 ist der Submissionport, welcher wenn der Serveradmin es
>>> komplett
>>> verkorkst gar keine Verschlüsselung geben muss;
>>> Port 465 ist der SMTPS-Port (das SMTP-pendant) zu HTTPS mit Port 443 ...
>> Ich präzisiere: Das darfst Du nur auf 587 erzwingen, denn auf dem Port 25
>> können auch MTAs aufschlagen, die gar kein TLS können und die könnten
>> in dem
>> Fall nicht einmal einen Mail an postmaster@DOMAIN absetzen, um ihr
>> Problem zu
>> schildern.
> für die eigene Domain vielleicht gar nicht mal so doof, auf die Art zu
> sagen:
> "besorg Dir einen ordentlichen Mailserver, wennst mir SPAM schicken willst"
>> - Administrator/Anwender
>>    Daran arbeiten sie eher selten. Wietse hat intensivst für Postfix
>> daran
>>    gearbeitet. Wie wenig Arbeit in amavis oder rspamd geflossen ist,
>> erlebt man
>>    sofort wenn man sich den Programmen nähert.
> mein Mailserver kommt mit Postfix/OpenDKIM/OpenDMARC aus,
> keine Notwendigkeit f. SPAMassassin, amavis, ...

schoen fuer dich, das kann sich aber zu jeder Zeit aendern
ein weit verbreitetes Problem von sich auf andere zu schliessen,
wenn man mal ein paar hundert/tausend Mailboxen hostet wird das
unverzichtbar, ich kennen sogar domains mit nur einer Handvoll
Mailadressen, die so zugespammed werden dass man nur dafuer schon high
performance Mailserver und filter braucht.


>>   Das Interface von Thunderbird
>>    stammt aus den 90ern - leider.
> als ob der Pfusch der "Gegenwart" was Interfaces betriffft, da besser ist;
>>   Aber da Geld auszugeben lohnt nicht mehr. Die
>>    Tage der Desktop-Clients sind gezählt.
> ob die Welt der "Heizflossen" besser ist, wage ich mal zu bezweifeln;
> 

ein grosser Mail Hoster wird dir aber "premium" support nur fuer
"seinen" Mail Client anbieten, das ist fuer gewoehnlich ein webmail,
fuer den Rest kannst du froh sein wenn
es Faqs gibt und/oder du bezahlst "extra" dafuer.

Wie Patrick gesagt hat der Kern des Problems bei den Clients ist die
langfristige Finanzierung, Versuche in der Vergangenheit dass ueber den
Software Verkauf zu finanzieren sind gescheitert. Als wirklicher Multi
OS Mailclient hat nur Thunderbird ueberlebt, dessen weitere Faehigkeiten
mit Kalendern und Adressbuechern ist aber nicht auf der Hoehe der Zeit.


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: spam...@tiscali.it

[Robert Schetterer]

Am 28.12.2017 um 13:37 schrieb J. Fahrner:
> Hallo Liste,
> immer wenn ich so durch meine Logs scrolle, fällt mir eine Adresse ganz
> besonders auf: spam...@tiscali.it
> Wird zwar in schöner Regelmäßigkeit durch Blacklists geblockt, aber so
> langsam frage ich mich: was steckt da dahinter? Wer ist so bescheuert
> und nennt seinen Spamabsender "spameri"? Und probiert es damit in
> schöner Regelmäßigkeit immer wieder? Mittlerweile dürfte doch auch der
> letzte diese Mails blocken.
> Weiß jemand was da dahinter steckt? Ist das irgendsoein Botnetz aus der
> Saurierzeit, welches immer noch nicht trockengelegt ist? Würde mich
> jetzt echt mal interessieren.
> 
> Jochen
> 

also zumindest tiscali.it spam absender sind in Internetjahren wirklich
aus der Vorsteinzeit, der Rest ist wie immer Spekulation


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Vor- und Nachteile von check_recipient_access gegenüber '/dev/null'

[Robert Schetterer]

Am 18.10.2017 um 16:05 schrieb Walter H.:
> Hallo,
> 
> habe folgendes in der main.cf (der Mailserver ist f. 2 Domains als MX im
> DNS eingetragen)
> 
> smtpd_recipient_restrictions = permit_mynetworks,
> permit_sasl_authenticated, reject_non_fqdn_recipient,
> reject_unauth_destination, reject_unknown_recipient_domain,
> check_recipient_access hash:/etc/postfix/recipient_access, reject
> 
> und recipient_access beinhaltet
> 
> mailadresse1@domain    OK
> mailadresse2@domain    OK
> 
> damit ist klar, will jemand eine Mail mit Empfänger mailadresse3@domain
> abladen, scheitert er ...
> 
> läßt man dies weg, und macht an Stelle
> 
> virtual_alias_maps = hash:/etc/postfix/virtual
> 
> mit folgenden Inhalt in virtual
> 
> mailadresse1@domain    mailbox@local
> mailadresse2@domain    mailbox@local
> @domain    shredder@devnull
> 
> und folgendes in der hosts-Datei
> 
> 127.0.0.1  devnull
> 
> sowie das im transport-File
> 
> devnull    discard:
> 
> würde in einem Fall der SPAM-Sender bei fehlerhaften Zieladressen
> einen Error bekommen und im anderen nichts davon mitbekommen, richtig?
> 
> welche Vor- und Nachteile ergeben sich sonst noch bei diesen Varianten?
> 
> Grüße,
> Walter
> 
> 
> 

silent discard sollte man grundsaetzlich nicht machen, ausser in
besonderen Faellen, mails im orcus zu versenken ist sehr schlechter Stil
es gibt ja nicht nur spammer auf der Welt sondern auch Menschen die sich
vertippen, die sollten schon eine vernuenftige Fehlermeldung bekommen


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Microsoft ESMTP MAIL Service

[Robert Schetterer]

Am 24.07.2017 um 21:02 schrieb Joachim Fahrner:
> Am 2017-07-24 20:51, schrieb Robert Schetterer:
> 
>> das Verfahren ist wirklich nur im absoluten
>> Einzelfall sinnvoll,
> 
> Was verstehst du denn unter "Einzelfall"? Eine bestimmte Installation,
> so wie meine, oder für bestimmte Absenderdomains? Letzteres halte ich
> für wenig sinnvoll, denn die Verifizierung macht ja erst bei unbekannten
> Absendern Sinn. Bei bekannten Absendern kann ich auch direkt hart sperren.
> 
> Jochen
> 
> 

eine typische Anwendung war zumindest frueher
bei grossen Absender Domains nach vorgeschalteten checks
ein sender verify fuer z.B yahoo, hotmail
aber ich hab das abgeschafft weil es nicht viel brachte
ob es heute noch zuverlaessig funktionieren wuerde
oder sinnvoll waere bezweifle ich.

Ansonsten kann man solche Sonderfaelle konstruieren...
wenn man z.B seine eigenen Mails ueber mehrere Relays routed
und da nicht existierende Sender abfangen will ( weil warum auch immer
kein anderes Verfahren moeglich ist )
Das Feature wird schlichtweg kaum gebraucht real

Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Microsoft ESMTP MAIL Service

[Robert Schetterer]

Am 24.07.2017 um 19:36 schrieb Joachim Fahrner:
> Am 2017-07-24 19:24, schrieb Robert Schetterer:
>> Jochen , wenn du meinen Server staendig nach mail adressen befragst die
>> nicht existieren, sperre ich deinen Server weil das wiederum Abuse ist
>> und melde wiederum deinen Server auf eine RBL
> 
> Wieso? Du bekommst doch von mir nicht mehr Anfragen als du mir Mails
> schickst. Und zwar pro Absenderadresse nur einmal eine Anfrage. Und wenn
> andere deine Mailadressen massenhaft misbrauchen, dann schütze deine
> Domain eben mit SPF oder DMARC.


Zunaechst gibt es keine Pflicht SPF DMARC DKIM etc zu haben
oder es zu validieren, dann sind strikte Policies eher selten
wegen damit verbundener Probleme, das caching deines Servers daempft das
Problem nur
denn dein Server kann mit x nicht existierenden
Mailadressen von x Quellen beballert werden, die Server an die du
verifizierst koennen x Massnahmen zur Begrenzung
pro Zeiteinheit und/oder greylisting, postscreen oder was auch immer
haben d.h du bekommst evtl keine Antwort die fuer deinen Mailserver
zuverlaessig verwertbar ist, das Verfahren ist wirklich nur im absoluten
Einzelfall sinnvoll, im Zweifelsfalls machst du die Sache fuer Dritte
und dich selbst nur schlimmer, da du mit sinnfreien Abfragen deine wie
die Smtp Slots anderer fuer legalen Mailverkehr blockierst.


> 
> Außerdem ändern sich die Zeiten. Spammer müssen heute keine Absender
> mehr erfinden. Die nehmen real existierende Adressen. Anders bei den
> Phishing-Betrügern, die wollen ja möglichst unentdeckt bleiben. Die
> erfinden dann so Absender wie "sparka...@autolederer.de". Wichtig ist
> denen, dass Wörter wie "Sparkasse" (oder was sie halt gerade abphishen
> wollen) möglichst oft auftaucht, damit man nicht mistrauisch wird.
> 
> 

ich sehe da nichts Neues das gabs schon immer ,im Gegenteil im Grunde
hat sich da nicht viel Neues getan, ich kann eigentlich nur "eine"
Aenderung feststellen , dass man Ziele "genauer" aufs Korn nimmt


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Microsoft ESMTP MAIL Service

[Robert Schetterer]

Am 24.07.2017 um 18:48 schrieb Joachim Fahrner:
> Am 2017-07-24 17:19, schrieb Walter H.:
> 
>> was soll das bringen, wenn damit eine Mailzustellung - eigentlich
>> sinnlos - verzögert wird?
>> die andere Seite, muss ja nicht sofort annehmen, und damit schaukelt
>> sich etwas auf, was nicht wirklich Sinn macht;
> 
> Mit dem gleichen Argument müsstest du auch postscreen und postgrey
> ablehnen.
> 
> Hier eine aktuelles Beispiel wo es geholfen hätte (momentan hab ich es
> nur als warn_if_reject konfiguriert, deshalb kam die Phishing-Mail durch:
> 
> Jul 23 22:56:15 server postfix/postscreen[29838]: CONNECT from
> [85.13.129.212]:49554 to [172.31.1.100]:25
> Jul 23 22:56:15 server postfix/dnsblog[29840]: addr 85.13.129.212 listed
> by domain list.dnswl.org as 127.0.5.1
> Jul 23 22:56:21 server postfix/postscreen[29838]: PASS NEW
> [85.13.129.212]:49554
> Jul 23 22:56:22 server postfix/smtpd[29843]: connect from
> dd3332.kasserver.com[85.13.129.212]
> Jul 23 22:56:22 server postfix/smtpd[29843]: Anonymous TLS connection
> established from dd3332.kasserver.com[85.13.129.212]: TLSv1.2 with
> cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> Jul 23 22:56:23 server postfix/cleanup[29850]: 1BEFC1016DC:
> message-id=<20170723205623.1befc101...@server.fahrner.name>
> Jul 23 22:56:23 server postfix/qmgr[5188]: 1BEFC1016DC:
> from=, size=277, nrcpt=1 (queue active)
> Jul 23 22:56:23 server postfix/verify[29848]: cache
> proxy:btree:/var/lib/postfix/verified_senders full cleanup: retained=475
> dropped=2 entries
> Jul 23 22:56:23 server postfix/smtp[29851]: Trusted TLS connection
> established to w00c4958.kasserver.com[85.13.129.212]:25: TLSv1.2 with
> cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> Jul 23 22:56:23 server postfix/smtp[29851]: 1BEFC1016DC:
> to=,
> relay=w00c4958.kasserver.com[85.13.129.212]:25, delay=0.66,
> delays=0.01/0.04/0.55/0.06, dsn=5.1.1, status=undeliverable (host
> w00c4958.kasserver.com[85.13.129.212] said: 550 5.1.1
> : Recipient address rejected: User unknown
> in virtual alias table (in reply to RCPT TO command))
> Jul 23 22:56:23 server postfix/qmgr[5188]: 1BEFC1016DC: removed
> Jul 23 22:56:26 server postfix/smtpd[29843]: NOQUEUE: reject_warning:
> RCPT from dd3332.kasserver.com[85.13.129.212]: 550 5.1.7
> : Sender address rejected: undeliverable
> address: host w00c4958.kasserver.com[85.13.129.212] said: 550 5.1.1
> : Recipient address rejected: User unknown
> in virtual alias table (in reply to RCPT TO command);
> from= to= proto=ESMTP
> helo=
> Jul 23 22:56:27 server policyd-weight[5974]: weighted check: 
> NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 CL_IP_EQ_FROM_MX=-3.1;
> 

Re: Microsoft ESMTP MAIL Service

[Robert Schetterer]

Am 24.07.2017 um 16:55 schrieb Walter H.:
> On 24.07.2017 15:29, Joachim Fahrner wrote:
>> Ob wohl ich ja grundsätzlich irgendwie der Meinung bin "warum sollte
>> ich Mails annehmen auf die ich nicht antworten kann"? (oder die im
>> Envelope behaupten von jemand anders zu sein).
>>
> hat nur den Pferdefuß, daß Du dir dabei selbst eine trittst ... ,
> spätestens wenn ausgehender Mailserver vom Sender ein anderer ist als
> der eingehende Mailserver;
> (der Mailserver, der Dir eine Mail geben will, wird NIE eine von anderen
> Hosts annehmen)
> 

lesen und verstehen

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

du kannst das gerne einschalten musst dann halt mit den Fehlern leben

beachte besonders

Sender address verification for all email

Unfortunately, sender address verification cannot simply be turned on
for all email - you are likely to lose legitimate mail from
mis-configured systems. You almost certainly will have to set up white
lists for specific addresses, or even for entire domains.

zu deutsch vergiss das einfach ,oder nutze es nur in Sonderfaellen

Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Mario Rönsch

[Robert Schetterer]

Am 19.07.2017 um 09:28 schrieb Patrick Ben Koetter:
> * Robert Schetterer <r...@sys4.de>:
>> Am 18.07.2017 um 18:32 schrieb Joachim Fahrner:
>>> Hallo Liste,
>>> es gibt da einen ziemlich üblen kriminellen Burschen namens Mario
>>> Rönsch. Der hat diverse Datenbanken gehackt und sich deren Mailadressen
>>> bemächtigt. Nun schickt der Typ penetrant rechtsextreme Mails an all
>>> diese Adressen. Ihm gehört die Seite anonymousnews.ru, früher
>>> migrantenschreck.ru (das war ein Onlineshop der ihm von den Behörden
>>> dicht gemacht wurde), und mittlerweile betreibt er einen neuen Shop
>>> patriotenshop.com für den er Werbung macht.
>>
>> sowas gab es schon mal ,war aber sehr primitiv damals
>> man konnte mit body checks arbeiten , da die Botschaften sehr primitiv
>> und einfoermig waren, haste mal ein Beispiel des contents ?
> 
> Gutes Gedächtnis! :) 

gehts so *g

Die header_checks (!) haben wir damals gepostet:

siehste ich war bei body checks also doch nimmer so gut die grauen
Zellen ...

im konkreten Fall ( hatte ein Bsp offlist ) wuerden die evtl auch
funktionieren

> 
> 
> <https://listi.jpberlin.de/pipermail/postfixbuch-users/2005-May/016810.html>
> 
> Dem kannst Du im Ansatz folgen.
> 
> p@rick
> 
> 

schaetze es wurden genug Loesungsansaetze gepostet, sollte reichen

Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Mario Rönsch

[Robert Schetterer]

Am 18.07.2017 um 19:55 schrieb Joachim Fahrner:
> Am 2017-07-18 19:46, schrieb Robert Schetterer:
> 
>> aso und wenn du spamassassin laufen hast kannst du da domains auch
>> blacklisten, sollte auch mit sieve dovecot funktionieren mit zb globaler
>> filter rule auf die domain evtl kombiniert mit einem content filter
> 
> Sieve habe ich auch, damit wäre es einfach. Aber mit Sieve rejecten ist
> nicht die feine Art (Stichwort Backscatter). 

je nachdem wie du das realisiert hast muss du dir daruber keinen Kopf
machen, wirklichen Backscatter hab ich damit noch nicht gesehen
aber es ist natuerlich rein technisch schon moeglich
bleibt also blacklisten im spamassassin, habe ich als milter damit
ist es unbedenklich

Ich könnte es natürlich
> auch einfach in den Müll schieben. Aber lieber wäre mir ein echter
> Reject auf MTA Ebene, damit der Absender auch was davon hat. ;-)

zb. body checks fuer dein Beispiel

> 



Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Mario Rönsch

[Robert Schetterer]

Am 18.07.2017 um 18:32 schrieb Joachim Fahrner:
> Hallo Liste,
> es gibt da einen ziemlich üblen kriminellen Burschen namens Mario
> Rönsch. Der hat diverse Datenbanken gehackt und sich deren Mailadressen
> bemächtigt. Nun schickt der Typ penetrant rechtsextreme Mails an all
> diese Adressen. Ihm gehört die Seite anonymousnews.ru, früher
> migrantenschreck.ru (das war ein Onlineshop der ihm von den Behörden
> dicht gemacht wurde), und mittlerweile betreibt er einen neuen Shop
> patriotenshop.com für den er Werbung macht.
> 
> Ich hab keinen Plan wie ich den effektiv blocken kann. Ich weiß auch
> nicht wie er es schafft unter dem Radar diverser Blacklists zu bleiben.
> Wahrscheinlich, weil seine Adressen eben echte Adressen sind und keine
> Honigtöpfe.
> Hat jemand eine Idee?
> Das ist eine aktuelle Mail von ihm:
> 
> Jul 18 18:06:04 server postfix/postscreen[8738]: CONNECT from
> [193.70.118.115]:62287 to [172.31.1.100]:25
> Jul 18 18:06:04 server postfix/dnsblog[8739]: addr 193.70.118.115 listed
> by domain dnsbl-2.uceprotect.net as 127.0.0.2
> Jul 18 18:06:04 server postfix/postscreen[8738]: PREGREET 11 after 0.01
> from [193.70.118.115]:62287: EHLO User\r\n
> Jul 18 18:06:04 server postfix/postscreen[8738]: DNSBL rank 2 for
> [193.70.118.115]:62287
> Jul 18 18:06:04 server postfix/postscreen[8738]: DISCONNECT
> [193.70.118.115]:62287
> Jul 18 18:09:01 server postfix/postscreen[8938]: CONNECT from
> [198.2.181.10]:29100 to [172.31.1.100]:25
> Jul 18 18:09:01 server postfix/postscreen[8938]: PASS OLD
> [198.2.181.10]:29100
> Jul 18 18:09:01 server postfix/smtpd[8939]: connect from
> mail10.suw17.mcsv.net[198.2.181.10]
> Jul 18 18:09:05 server postgrey[2574]: action=pass, reason=triplet
> found, delay=907, client_name=mail10.suw17.mcsv.net,
> client_address=198.2.181.10, s
> ender=bounce-mc.us16_78343126.45573-jf=fahrner.n...@mail10.suw17.mcsv.net,
> recipient=j...@fahrner.name
> Jul 18 18:09:05 server postfix/policyd-weight[23996]: decided
> action=PREPEND X-policyd-weight: using cached result; rate: -6.1;
> 

Re: Mario Rönsch

[Robert Schetterer]

Am 18.07.2017 um 18:32 schrieb Joachim Fahrner:
> Hallo Liste,
> es gibt da einen ziemlich üblen kriminellen Burschen namens Mario
> Rönsch. Der hat diverse Datenbanken gehackt und sich deren Mailadressen
> bemächtigt. Nun schickt der Typ penetrant rechtsextreme Mails an all
> diese Adressen. Ihm gehört die Seite anonymousnews.ru, früher
> migrantenschreck.ru (das war ein Onlineshop der ihm von den Behörden
> dicht gemacht wurde), und mittlerweile betreibt er einen neuen Shop
> patriotenshop.com für den er Werbung macht.
> 
> Ich hab keinen Plan wie ich den effektiv blocken kann. Ich weiß auch
> nicht wie er es schafft unter dem Radar diverser Blacklists zu bleiben.
> Wahrscheinlich, weil seine Adressen eben echte Adressen sind und keine
> Honigtöpfe.
> Hat jemand eine Idee?
> Das ist eine aktuelle Mail von ihm:
> 
> Jul 18 18:06:04 server postfix/postscreen[8738]: CONNECT from
> [193.70.118.115]:62287 to [172.31.1.100]:25
> Jul 18 18:06:04 server postfix/dnsblog[8739]: addr 193.70.118.115 listed
> by domain dnsbl-2.uceprotect.net as 127.0.0.2
> Jul 18 18:06:04 server postfix/postscreen[8738]: PREGREET 11 after 0.01
> from [193.70.118.115]:62287: EHLO User\r\n
> Jul 18 18:06:04 server postfix/postscreen[8738]: DNSBL rank 2 for
> [193.70.118.115]:62287
> Jul 18 18:06:04 server postfix/postscreen[8738]: DISCONNECT
> [193.70.118.115]:62287
> Jul 18 18:09:01 server postfix/postscreen[8938]: CONNECT from
> [198.2.181.10]:29100 to [172.31.1.100]:25
> Jul 18 18:09:01 server postfix/postscreen[8938]: PASS OLD
> [198.2.181.10]:29100
> Jul 18 18:09:01 server postfix/smtpd[8939]: connect from
> mail10.suw17.mcsv.net[198.2.181.10]
> Jul 18 18:09:05 server postgrey[2574]: action=pass, reason=triplet
> found, delay=907, client_name=mail10.suw17.mcsv.net,
> client_address=198.2.181.10, s
> ender=bounce-mc.us16_78343126.45573-jf=fahrner.n...@mail10.suw17.mcsv.net,
> recipient=j...@fahrner.name
> Jul 18 18:09:05 server postfix/policyd-weight[23996]: decided
> action=PREPEND X-policyd-weight: using cached result; rate: -6.1;
> 

Re: Greylisting

[Robert Schetterer]

Am 11.07.2017 um 17:51 schrieb Joachim Fahrner:
> Hallo,
> in letzter Zeit habe ich mich an Roberts Vorschlag gehalten und
> Greylisting nur selektiv angewandt (Dialin-IPs usw.).
> Langsam komme ich ins Grübeln, ob ich das nicht doch generell wieder für
> alles aktivieren soll. Ich bekomme in letzter Zeit häufig Spam und
> Phishing von "echten" Mailservern (wurden die gehackt?), 

naja gehacked wurde nicht der Server, sondern die Ktos

für die
> Greylisting nicht angewandt wurde, und die auch (noch) auf keiner
> Blacklist waren. Kurze Zeit später findet man die dann auch auf manchen
> Blacklists. Das heisst: die ziehen ihre Aktionen in kürzester Zeit über
> (gehackte?) Server durch, und suchen sich dann wieder einen anderen
> "unverbrauchten" Server.

hm, typisch waere eher man bringt Ktos grosser mail provider unter seine
Kontrolle die senden dann eben von div ips, voellig normal

> Hier würde Greylisting enorm helfen, das verzögert die Zustellung, und
> beim nächsten Versuch steigt die Wahrscheinlichkeit, dass sie von einer
> Blacklist registriert wurden.

koennte klappen, hab ich aber so fast nie erlebt und z.B google und co
ist bei mir grundsaetzlich gewhitelistet ( alles andere produziert
zuviel support jobs ), das muss der content filter eben richtentut
er auch

> 
> Was meint ihr?

das es da nicht viel Neues drueber zu sagen gibt .?

> 
> Jochen
> 



Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: SPF - "It is impossible for us to say why it was rejected."

[Robert Schetterer]

Am 10.07.2017 um 19:43 schrieb Walter H.:
> On 10.07.2017 15:11, Marc Risse wrote:
>> Hallo Joachim,
>>
>> genau deshalb verstehe ich es nicht. DNS in alle möglichen Richtungen
>> funktioniert auch ohne Probleme. Ich durchsuche gerade die
>> Mailinglisten von OpenSPF, vielleicht finde ich dort etwas. Einen
>> Bugtracker habe ich nicht finden können.
>>
>> :-(
> 
> bei dem DNS Eintrag
> 
> ruhr-uni-bochum.de  text = "v=spf1
> exists:%{ir}.%{v}._spfx.ruhr-uni-bochum.de
> exists:%{ir}._ip.%{l}._spfx.ruhr-uni-bochum.de -all"
> 
> würd ich auch WO geben ...
> 
> wie kommt man eigentlich auf eine derartige Paranoia das so zu verkorksen?
> 
> ein  "v=spf1 mx -all" oder ähnlich einfaches würde es auch tun ...
> 

sehr wahrscheinlich kriegt das openspf wegen bugs nicht gebacken,
umsteigen auf anderen spf client oder whitelisten


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: HELO Access restrictions

[Robert Schetterer]

Am 04.07.2017 um 22:10 schrieb Joachim Fahrner:
> Am 2017-07-04 22:01, schrieb Robert Schetterer:
> 
>>> Die Idee hinter den HELO restrictions war ja, dass Botnet Zombies normal
>>> keinen korrekt konfigurierten Hostnamen und DNS-Einträge haben.
>>
>> was definierst du als korrekt ?
> 
> Na dass der Rechner ein passendes Forward- und Reverse-DNS hat.
> 


gibt die postfix faq so als zwingend nicht her ,nach meiner Lesart

reject_invalid_helo_hostname (with Postfix < 2.3: reject_invalid_hostname)
Reject the request when the HELO or EHLO hostname is malformed.
Note: specify "smtpd_helo_required = yes" to fully enforce this
restriction (without "smtpd_helo_required = yes", a client can simply
skip reject_invalid_helo_hostname by not sending HELO or EHLO).
The invalid_hostname_reject_code specifies the response code for
rejected requests (default: 501).

und

reject_non_fqdn_helo_hostname (with Postfix < 2.3: reject_non_fqdn_hostname)
Reject the request when the HELO or EHLO hostname is not in
fully-qualified domain or address literal form, as required by the RFC
<<<<<<<

im Gegensatz zu

reject_unknown_helo_hostname (with Postfix < 2.3: reject_unknown_hostname)
Reject the request when the HELO or EHLO hostname has no DNS A or MX
record.
The reply is specified with the unknown_hostname_reject_code
parameter (default: 450) or unknown_helo_hostname_tempfail_action
(default: defer_if_permit). See the respective parameter descriptions
for details.
Note: specify "smtpd_helo_required = yes" to fully enforce this
restriction (without "smtpd_helo_required = yes", a client can simply
skip reject_unknown_helo_hostname by not sending HELO or EHLO).





Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: HELO Access restrictions

[Robert Schetterer]

Am 04.07.2017 um 22:01 schrieb Robert Schetterer:
> Am 04.07.2017 um 18:09 schrieb Joachim Fahrner:
>> Hallo,
>>
>> ich stelle mal eine Frage zur Diskussion: nützen die HELO Access
>> restrictions heute überhaupt noch was?
> 
> Ja ,aber eher selten
> 
>>
>> Wenn ich so in meinen Logs stöbere, finde ich da kaum abgewiesene Mails.
>> Und wenn, dann war es kein Spam. Der meiste Spam wird bei mir durch RBL
>> geblockt.
>>
>> Die Idee hinter den HELO restrictions war ja, dass Botnet Zombies normal
>> keinen korrekt konfigurierten Hostnamen und DNS-Einträge haben.
> 
> was definierst du als korrekt ?
> 
>  Aber die
>> Spamsoftware wird auch immer schlauer, und es ist ja ein Leichtes mit 2
>> DNS-Abfragen einen zur IP passenden Hostnamen zu bekommen:
>>
>> $ host 93.104.124.64
>> 64.124.104.93.in-addr.arpa domain name pointer
>> ppp-93-104-124-64.dynamic.mnet-online.de.
>> $ host ppp-93-104-124-64.dynamic.mnet-online.de
>> ppp-93-104-124-64.dynamic.mnet-online.de has address 93.104.124.64
>>
>> Und wenn ich mir die Logs so ansehe bestätigt das meine These: da gibt
>> es sehr viele HELO Namen die ziemlich kryptisch aussehen, so wie die von
>> DSL-Anschlüssen. Also wären diese Prüfungen ja reine Zeitverschwendung,
>> und sogar kontraproduktiv.
>>
>> Jochen
> 
> ich fordere dass es "formal" richtig ist
> und ich lass mir nicht meinen eigenen hostnamen und/oder ipadresse im
> helo praesentieren via access list, das wars aber auch schon, was
> anderes hatte ich nie

localhost , localhost.localdomains kann man auch noch reinschreiben

nicht vergessen mynetworks etc ausnehmen
> 
> Best Regards
> MfG Robert Schetterer
> 



Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: HELO Access restrictions

[Robert Schetterer]

Am 04.07.2017 um 18:09 schrieb Joachim Fahrner:
> Hallo,
> 
> ich stelle mal eine Frage zur Diskussion: nützen die HELO Access
> restrictions heute überhaupt noch was?

Ja ,aber eher selten

> 
> Wenn ich so in meinen Logs stöbere, finde ich da kaum abgewiesene Mails.
> Und wenn, dann war es kein Spam. Der meiste Spam wird bei mir durch RBL
> geblockt.
> 
> Die Idee hinter den HELO restrictions war ja, dass Botnet Zombies normal
> keinen korrekt konfigurierten Hostnamen und DNS-Einträge haben.

was definierst du als korrekt ?

 Aber die
> Spamsoftware wird auch immer schlauer, und es ist ja ein Leichtes mit 2
> DNS-Abfragen einen zur IP passenden Hostnamen zu bekommen:
> 
> $ host 93.104.124.64
> 64.124.104.93.in-addr.arpa domain name pointer
> ppp-93-104-124-64.dynamic.mnet-online.de.
> $ host ppp-93-104-124-64.dynamic.mnet-online.de
> ppp-93-104-124-64.dynamic.mnet-online.de has address 93.104.124.64
> 
> Und wenn ich mir die Logs so ansehe bestätigt das meine These: da gibt
> es sehr viele HELO Namen die ziemlich kryptisch aussehen, so wie die von
> DSL-Anschlüssen. Also wären diese Prüfungen ja reine Zeitverschwendung,
> und sogar kontraproduktiv.
> 
> Jochen

ich fordere dass es "formal" richtig ist
und ich lass mir nicht meinen eigenen hostnamen und/oder ipadresse im
helo praesentieren via access list, das wars aber auch schon, was
anderes hatte ich nie

Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Phishing Mails

[Robert Schetterer]

Am 03.07.2017 um 18:14 schrieb Joachim Fahrner:
> Am 2017-07-03 17:38, schrieb Robert Schetterer:
> 
>> will man also nicht im Support
>> versinken ( und evtl. kein Geld mehr verdienen ) muss man sich schon
>> sehr genau ueberlegen wie man was filtert.
> 
> Schon klar, das macht natürlich einen riesen Unterschied, ob man einen
> Maildienst anbietet, oder das nur privat für die Familie betreibt. Ich
> könnte z.B. alles per default sperren, und nur Amazon, Zalando und ebay
> auf eine Whitelist setzen. Würde keiner merken. ;-)
> 
> Jochen

sicher dass Tschibo nicht auch ein Muss ist ? *g


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Phishing Mails

[Robert Schetterer]

Am 03.07.2017 um 07:51 schrieb Joachim Fahrner:
> Am 2017-07-03 06:50, schrieb Robert Schetterer:
>> kann ich mir kaum vorstellen, hab aber auch grad keine Zeit nachzulesen,
>> real wird das allerdings zu einigen false positives fuehren
> 
> Ich könnte mir vorstellen dass es einige Dienste trifft, wo ein
> Webserver etwas aus Scripten heraus (PHP) verschickt, z.B.
> Bestellbestätigungen aus Online-Shops. Die sind meist ziemlich mies
> konfiguriert.
> 
> Jochen

Es gibt bedauerlicherweise x mailsysteme in der Welt die nachlaessig
konfiguriert sind ,auf die eine oder andere Art, und wie die Welt so ist
meint der eine oder andere Empfaenger genau von diesen Absendern kommen
die "wirklich" wichtigen Mails *g , will man also nicht im Support
versinken ( und evtl. kein Geld mehr verdienen ) muss man sich schon
sehr genau ueberlegen wie man was filtert. Ausserdem gibts da einfach
sehr viele kulturelle und rechtliche Unterschiede.





Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Phishing Mails

[Robert Schetterer]

Am 02.07.2017 um 21:48 schrieb Uwe Drießen:
> Im Auftrag von Robert Schetterer
>> client restrictions beziehen sich auf die Ip Adresse nicht auf das helo
>> das helo ist nach rfc mehr oder weniger Schall und Rauch ,es wird nur
>> als "formal" richtig gefordert ( zumindest war das mal so ), ich will
>> jetzt nicht nachlesen ,aber soviel ich erinnere ist nicht mal ein
>> reverse ptr gefordert sondern nur ein A und/oder MX Eintrag, alles
>> andere ist mehr oder weniger best practice oder hat sich im Laufe der
>> Zeit eben als pseudo Standard durchgesetzt ... jedenfalls wird man
>> ebenfalls nicht gluecklich werden wenn man mit postfix im helo einen
>> aufloesbaren dns Eintrag zwingend fordert der dann noch zusaetzlich
>> forward und reverse matchen soll. Umgekehrt ist man allerdings gut
>> beraten wenn man seinen eigenen Mailserver als Sender eben moeglichst
>> genauso einrichtet.
> 
> Soweit ich mich an die RFC's in Ihrem Zusammenhang / Zusammenspiel aus den 
> einzelnen Bereichen erinnere ist das sehr wohl aus den RFC's abzuleiten das 
> PTR als auch alle DNS Namen auf die jeweilige IP zurückzuverfolgen sein 
> sollen/müssen
> 
> War vor ca. 3 oder 4 Jahren eine Große Diskussion auf der Liste von Peer 
> Heinlein  und sollte dort auch mit der Nennung aller relevanten RFC's zu 
> finden sein. 


kann ich mir kaum vorstellen, hab aber auch grad keine Zeit nachzulesen,
real wird das allerdings zu einigen false positives fuehren

> 
> Allerdings ist immer die Sache in wie weit diese strenge Prüfung  auf den 
> Mailservern eingesetzt werden kann.
> Es wäre allerdings ein Schritt in die Richtige Richtung gegen UBE/UCE usw.  
> 
>  
>>
>> Best Regards
>> MfG Robert Schetterer
> 
> 
> Mit freundlichen Grüßen
> 
> Uwe Drießen
> --
> Software & Computer
> 
> Netzwerke, Server. 
> Wir vernetzen Sie und Ihre Rechner !
> 
> Uwe Drießen
> Lembergstraße 33
> 67824 Feilbingert
> 
> Tel.: 06708660045 
> 
> 



Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Phishing Mails

[Robert Schetterer]

Am 01.07.2017 um 17:29 schrieb Joachim Fahrner:
> Am 2017-07-01 17:00, schrieb Walter H.:
> 
>> ich denke er meint, daß es durchaus möglich ist, daß es Mails gibt,
>> welche berechtigterweise kommen, aber durch dieses harte blocken aber
>> fehlschlagen,
>> wobei ich mir die Frage stelle, ob ein Mailserver überhaupt eine
>> Existenzberechtigung hat, wenn er sich mit
>> HELO  meldet und dieses  nicht dessen DNS Name ist und die IP
>> Adresse welche connected im Reverse DNS ebensowenig  entspricht
>> ...
> 
> Das sehe ich eigentlich auch so. Jeder professionelle Dienst sollte
> eigentlich ein korrekt konfiguriertes DNS haben. Und wenn Mails
> irgendwelcher Hobby-Admins geblockt werden, dann kann das nicht so
> schlimm sein. Wenn einem so eine Mail wichtig ist, kann man immer noch
> einzelne Server auf eine Whitelist setzen.
> 
> Jochen

Hi, sorry wie schon erwaehnt koennt ihr auf euren Mailserver so
verfahren, aber mit der Realitaet auf grossen Kunden Mailsystemen hat
das eben nicht viel zu tun. Nicht alles was technisch moeglich ist, ist
auch gleich immer eine gute Idee fuer alle


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Phishing Mails

[Robert Schetterer]

Am 01.07.2017 um 17:00 schrieb Walter H.:
> On 01.07.2017 16:47, Joachim Fahrner wrote:
>> Am 2017-07-01 15:55, schrieb Robert Schetterer:
>>
>>> also wenn man das verwenden will ist es klug vorher zu filtern
>>> zb mit
>>>
>>> smtpd_restriction_classes
>>>
>>> oder einem policy server , milter etc
>>
>> Ok. Aber ich steh da wohl grad auf der Leitung. Nach welchen Kriterien
>> sollte man da filtern? Wen prüft man damit, und wen lässt man an der
>> Prüfung vorbei?
>>
>> Jochen 
> ich denke er meint, daß es durchaus möglich ist, daß es Mails gibt,
> welche berechtigterweise kommen, aber durch dieses harte blocken aber
> fehlschlagen,
> wobei ich mir die Frage stelle, ob ein Mailserver überhaupt eine
> Existenzberechtigung hat, wenn er sich mit
> HELO  meldet und dieses  nicht dessen DNS Name ist und die IP
> Adresse welche connected im Reverse DNS ebensowenig  entspricht ...
> 
> 

client restrictions beziehen sich auf die Ip Adresse nicht auf das helo
das helo ist nach rfc mehr oder weniger Schall und Rauch ,es wird nur
als "formal" richtig gefordert ( zumindest war das mal so ), ich will
jetzt nicht nachlesen ,aber soviel ich erinnere ist nicht mal ein
reverse ptr gefordert sondern nur ein A und/oder MX Eintrag, alles
andere ist mehr oder weniger best practice oder hat sich im Laufe der
Zeit eben als pseudo Standard durchgesetzt ... jedenfalls wird man
ebenfalls nicht gluecklich werden wenn man mit postfix im helo einen
aufloesbaren dns Eintrag zwingend fordert der dann noch zusaetzlich
forward und reverse matchen soll. Umgekehrt ist man allerdings gut
beraten wenn man seinen eigenen Mailserver als Sender eben moeglichst
genauso einrichtet. Postfix hat zwar viele Moeglichkeiten solche
restrictions einzurichten es ist aber relativ unbequem diese mit postfix
dynamisch
anzupassen ( Achtung das heisst nicht dass es nicht sinnvoll oder nicht
moeglich ist ), besser ist das jedoch in miltern und/oder policy servern
zu realisieren, vor allem weil man dort eben besser klassifizieren kann
( vergleich spamassassin ). die Aufgabe von postfix ist es in erster
Linie emails zu senden und zu empfangen, nicht die Filterung.


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Phishing Mails

[Robert Schetterer]

Am 01.07.2017 um 13:29 schrieb Joachim Fahrner:
> Am 2017-07-01 12:45, schrieb Robert Schetterer:
> 
>> das gibt real aber zuviel Aerger, wenn man den anwenden will sollte man
>> vorfiltern, also nicht per se auf alles anwenden !
> 
> Wo kann das denn Ärger geben?
> 
> Problem heutzutage ist (aus meiner Sicht), dass die Phishing Mails immer
> perfekter werden. Da wird echt viel Energie reingesteckt, anders als bei
> Spam. Bei Spam möchte man möglichst viele Leute möglichst billig
> erreichen. Bei Phishing reicht es wenige zu erreichen, die dafür aber
> möglichst "zuverlässig". Man will da möglichst perfekt "Seriosität"
> vortäuschen. Es ist erstaunlich, wie da extra für den Zweck
> "unbefleckte" Server angemietet werden, und das DNS eines renomierten
> Dienstes möglichst täuschend echt simuliert wird. An den Headern erkennt
> man kaum noch dass der Absender nicht vertrauenswürdig ist, nur an den
> Links die man dann klicken soll sieht man, dass die auf irgendeine
> dubiose Seite leiten.
> 
> Da stecken professionell arbeitende Banden dahinter, mit ziemlich viel
> Knowhow. Aber die krieg ich schon auch noch in den Griff. Man hat ja
> sonst keine Hobbies. ;-)
> 
> Jochen

Hallo Jochen, man sollte von sich nicht auf andere schliessen
du kannst auf deinem Server machen was du willst, wenn du aber als
Dienstleister taetig bist musst du deine Massnahmen schon sorgfaeltig
abwaegen

reject_unknown_reverse_client_hostname geht ok in den meisten setups

reject_unknown_client_hostname
macht ein Haufen zusaetzliche Support Arbeit
und 99 % aller Kunden interesiert eine technische Erklaerung nicht die
Bohne, also wenn man das verwenden will ist es klug vorher zu filtern
zb mit

smtpd_restriction_classes

oder einem policy server , milter etc



Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Phishing Mails

[Robert Schetterer]

Am 01.07.2017 um 12:45 schrieb Robert Schetterer:
> Am 01.07.2017 um 09:55 schrieb Walter H.:
>> On 01.07.2017 09:14, Joachim Fahrner wrote:
>>> Hallo,
>>>
>>> so langsam wird das hier zum (unfreiwilligen) Hobby mit den
>>> Phishing-Mails.
>>>
>>> Ich frage mich gerade, warum das hier nicht abgewiesen wurde:
>>>
>>> Received: from mail.sicherheit.de (unknown [83.169.1.6])
>>>
>>> Die IP hat zwar einen Reverse pointer zu mail.sicherheit.de:
>>>
>>> $ host 83.169.1.6
>>> 6.1.169.83.in-addr.arpa domain name pointer mail.sicherheit.de.
>>>
>>> Aber mail.sicherheit.de hat eine ganz andere IP:
>>>
>>> $ host mail.sicherheit.de
>>> mail.sicherheit.de has address 72.52.10.14
>>>
>> der Klassiker, wobei die Ursache nicht mal zwingend bösartig war;
>> dies geschieht z.B. schon dadurch, wenn jemand mit seiner Domain zu
>> einem anderen Hoster umzieht und
>> beim alten Hoster die reverse DNS Einträge nicht zurückgesetzt/geändert
>> werden ...
>> (wobei das dann irgendwie der Beweis f. IPv4s im Überfluss wäre)
>>
>>> Sowas müsste sich doch blocken lassen. Ist das nicht Bestandteil von
>>> reject_invalid_helo_hostname?
>>
>> damit blockierst nur die Mails, welche beim HELO eine Domain angeben,
>> die es im DNS entweder nicht gibt oder
>> sonst was ...
>> wenn da jemand weil er lustig ist eben   mail.sicherheit.de angibt, geht
>> das durch, wie Du ja selbst erkannt hast,
>> gibt es die;
>>
>> interessanter wäre ein Mechanismus, der exakt die Mails durchläßt, wo
>> die IP einen reverse DNS ergibt,
>> welcher tatsächlich ein forward DNS wieder diese IP ergibt ...
>> (damit hast den ganzen Quark, wo jemand irgendwas vorgaukelt, weg)
>>
>>
> 
>  http://www.postfix.org/postconf.5.html#reject_unknown_reverse_client_hostname
> 
> Reject the request when the client IP address has no address->name mapping.
> This is a weaker restriction than the reject_unknown_client_hostname
> feature, which requires not only that the address->name and
> name->address mappings exist, but also that the two mappings reproduce
> the client IP address.
> The unknown_client_reject_code parameter specifies the response code for
> rejected requests (default: 450). The reply is always 450 in case the
> address->name lookup failed due to a temporary problem.
> This feature is available in Postfix 2.3 and later.
> 

sorry der isses

http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname


reject_unknown_client_hostname (with Postfix < 2.3: reject_unknown_client)
Reject the request when 1) the client IP address->name mapping
fails, 2) the name->address mapping fails, or 3) the name->address
mapping does not match the client IP address.
This is a stronger restriction than the
reject_unknown_reverse_client_hostname feature, which triggers only
under condition 1) above.
The unknown_client_reject_code parameter specifies the response code
for rejected requests (default: 450). The reply is always 450 in case
the address->name or name->address lookup failed due to a temporary
problem.

schon ewig nimmer nachgesehen
> 
> 
> das gibt real aber zuviel Aerger, wenn man den anwenden will sollte man
> vorfiltern, also nicht per se auf alles anwenden !
> 
> 
> Best Regards
> MfG Robert Schetterer
> 



Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Phishing Mails

[Robert Schetterer]

Am 01.07.2017 um 09:55 schrieb Walter H.:
> On 01.07.2017 09:14, Joachim Fahrner wrote:
>> Hallo,
>>
>> so langsam wird das hier zum (unfreiwilligen) Hobby mit den
>> Phishing-Mails.
>>
>> Ich frage mich gerade, warum das hier nicht abgewiesen wurde:
>>
>> Received: from mail.sicherheit.de (unknown [83.169.1.6])
>>
>> Die IP hat zwar einen Reverse pointer zu mail.sicherheit.de:
>>
>> $ host 83.169.1.6
>> 6.1.169.83.in-addr.arpa domain name pointer mail.sicherheit.de.
>>
>> Aber mail.sicherheit.de hat eine ganz andere IP:
>>
>> $ host mail.sicherheit.de
>> mail.sicherheit.de has address 72.52.10.14
>>
> der Klassiker, wobei die Ursache nicht mal zwingend bösartig war;
> dies geschieht z.B. schon dadurch, wenn jemand mit seiner Domain zu
> einem anderen Hoster umzieht und
> beim alten Hoster die reverse DNS Einträge nicht zurückgesetzt/geändert
> werden ...
> (wobei das dann irgendwie der Beweis f. IPv4s im Überfluss wäre)
> 
>> Sowas müsste sich doch blocken lassen. Ist das nicht Bestandteil von
>> reject_invalid_helo_hostname?
> 
> damit blockierst nur die Mails, welche beim HELO eine Domain angeben,
> die es im DNS entweder nicht gibt oder
> sonst was ...
> wenn da jemand weil er lustig ist eben   mail.sicherheit.de angibt, geht
> das durch, wie Du ja selbst erkannt hast,
> gibt es die;
> 
> interessanter wäre ein Mechanismus, der exakt die Mails durchläßt, wo
> die IP einen reverse DNS ergibt,
> welcher tatsächlich ein forward DNS wieder diese IP ergibt ...
> (damit hast den ganzen Quark, wo jemand irgendwas vorgaukelt, weg)
> 
> 

 http://www.postfix.org/postconf.5.html#reject_unknown_reverse_client_hostname

Reject the request when the client IP address has no address->name mapping.
This is a weaker restriction than the reject_unknown_client_hostname
feature, which requires not only that the address->name and
name->address mappings exist, but also that the two mappings reproduce
the client IP address.
The unknown_client_reject_code parameter specifies the response code for
rejected requests (default: 450). The reply is always 450 in case the
address->name lookup failed due to a temporary problem.
This feature is available in Postfix 2.3 and later.



das gibt real aber zuviel Aerger, wenn man den anwenden will sollte man
vorfiltern, also nicht per se auf alles anwenden !


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: hostname ... does not resolve to address ...

[Robert Schetterer]

Am 29.06.2017 um 11:10 schrieb Joachim Fahrner:
> Hallo,
> ich habe in meinem Log massenhaft solche Fehlermeldungen:
> 
> Jun 29 08:31:31 server postfix/smtpd[16058]: warning: hostname
> tupac2.dyne.org does not resolve to address 178.62.188.7: Temporary
> failure in name resolution
> 
> Ich kann bei der Domain aber keine Fehler erkennen. Sie hat 3
> Nameserver: ns.dyne.org, ns2.dyne.org und ns3.dyne.org. Ich hab die mal
> per dig gefragt, und bei allen dreien bekomme ich die korrekte Adresse
> für tupac2.dyne.org zurück.

es zaehlt exakt nur der Zeitpunkt
im Log, was du nachher machst muss nicht das gleiche resultat liefern

> 
> Über diesen Server erfolgt der Versand einer Mailingliste, und ich
> bekomme da auch reichlich Mails aus der Liste. Der Fehler scheint also
> nur gelegentlich aufzutreten. Bei keiner anderen Domain erhalte ich
> solche Fehlermeldungen, ich gehe daher davon aus dass mein outbound
> richtig funktioniert.
> 
> Hat jemand eine Idee was da faul sein könnte?

dein resolver ,deren nameserver/zone etc ,mehr bleibt nicht wenn sonst
nichts auf dem system zerschossen ist

dyne klingt nach dyn ip, da waere so ein Verhalten gelegentlich zu erwarten

> 
> Jochen



Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Absender "Displayname" umschreiben mit Variable

[Robert Schetterer]

Am 22.06.2017 um 14:26 schrieb Marc Risse:
> Hallo Liste,
> 
> ich dachte mir ich baue da mal schnell was, verzweifele jetzt aber. Ich
> möchte für eine Vielzahl von Linux-Servern eine Standard-Config
> ausrollen. Diese Server haben nur Postfix an Board um den Admin zu
> informieren, also für Cron etc.
> Da wir für unsere Server mehrere eigene DNS-Zonen betreiben (.server,
> .lanserver .etc) und ich auf dem zentralen Mailrelay Mails mit "solchen"
> Zonen zurückweise, habe ich folgendes gebaut:
> 
> myorigin  = /etc/mailname
> mydestination = localhost, $myhostname
> relayhost = relay.foo.de
> sender_canonical_maps = regexp:/etc/postfix/sender_canonical
> 
> /etc/postfix/sender_canonical:
> /./ nore...@foo.de
> 
> 
> nore...@foo.de ist auf dem zuständigen Relay ein blackhole, also /dev/null
> 
> Das ganze Funktioniert! Die Mails haben einen ordentlichen absender und
> werden ordentlich zugestellt. Antworten (Autoreply etc) werden direkt
> vernichtet. Super!
> Jetzt beschweren sich die Admins allerdings, dass im FROM leider immer
> "root <nore...@foo.de>" steht. Statt des Displaynames sollte dort der
> Hostname des sendenden Servers stehen, also ein FROM à la "WEB53.SERVER
> <nore...@citkomm.de>".
> 
> So, lange Vorrede, hier mein Problem:
> 
> Um den Displayname (oder wie auch immer der Text-Teil vor der
> Mailadresse heißt) umzuschreiben, brauche ich den Hostnamen oder
> ähnliches. Ich würde es am liebsten so machen:
> smtp_header_checks = regexp:/etc/postfix/header_checks
> 
> /etc/postfix/header_checks:
> /^From:[[:space:]]+(.*)/ REPLACE From: "$myhostname" <nore...@citkomm.de>
> 
> 
> leider kann ich an der Stelle "$myhostname" keine Variable verwenden,
> zumindest habe ich dafür keine Lösung gefunden.
> Habt Ihr eine Idee, wie ich den Hostnamen "variabel" in den Header
> bekomme? Ziel soll es sein, dass die main.cf und alle anderen Dateien
> keine hostspezifischen Daten enthalten, also $myhostname u.s.w. wird von
> Postfix ermittelt, $myorigin kommt aus /etc/mailname sofern vorhanden.
> 
> Für Tipps/Ideen wäre ich sehr dankbar - allerdings bitte keine
> Diskussionen über die Randbedingungen ;)
> 
> VG
> Marc
> 
> 

Also ich hab so was aehnliches anders geloest, etliche devices
via puppet, ebenfalls nur um status mails auszuliefern via relay
ich hab dafuer ssmtp genutzt weil ich gar keinen "richtigen" Mailserver
da haben will evtl eine Alternative fuer dich

https://sys4.de/de/blog/2015/11/04/einfaches-mail-setup-mit-ssmtp/
https://sys4.de/de/blog/2015/12/29/cron-alternative-cronie/




Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Phishing Mails von der FAZ?

[Robert Schetterer]

Am 18.06.2017 um 10:51 schrieb Walter H.:
> On 18.06.2017 09:10, Robert Schetterer wrote:
>> dig -t mx faz.net
> dig -t mx faz.de

um faz.de gings aber nicht ...

> 
> ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> -t mx faz.de
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46358
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2
> 
> ;; QUESTION SECTION:
> ;faz.de.IN  MX
> 
> ;; ANSWER SECTION:
> faz.de. 21600   IN  MX  45 mailserver2.faz.de.
> faz.de. 21600   IN  MX  45 mailserver1.faz.de.
> 
> ;; AUTHORITY SECTION:
> faz.de. 86400   IN  NS  dns.globvill.de.
> faz.de. 86400   IN  NS  dns.voerde.globvill.de.
> 
> ;; ADDITIONAL SECTION:
> dns.voerde.globvill.de. 75927   IN  A   212.20.160.2
> dns.voerde.globvill.de. 75927   IN  2001:40b8::21
> 
> ;; Query time: 141 msec
> ;; SERVER: 172.23.1.11#53(172.23.1.11)
> ;; WHEN: Sun Jun 18 10:50:31 2017
> ;; MSG SIZE  rcvd: 176
> 



Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Phishing Mails von der FAZ?

[Robert Schetterer]

Am 18.06.2017 um 07:52 schrieb Joachim Fahrner:
> Kann das sein?
> Habe heute eine Phishing Mail von  bekommen. Ähnlich wie die
> hier: http://zy0.de/q/46.163.116.28
> 
> Wurde deren Mailserver gehackt?
> 
> Jochen



 Hi , ist noch frueh
evtl vergugg ich mich, aber mail.faz.net
gibts bei mir grade nicht und der MX von faz.net ist auch ein anderer
also wenn da was gehacked wurde hat man das system aus dem netz/dns genommen

dig mail.faz.net

; <<>> DiG 9.9.5-3ubuntu0.14-Ubuntu <<>> mail.faz.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 47764
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;mail.faz.net.  IN  A

;; AUTHORITY SECTION:
faz.net.645 IN  SOA dns.voerde.globvill.de.
hostmaster.globvill.de. 2017061601 86400 7200 604800 900

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Jun 18 09:06:18 CEST 2017
;; MSG SIZE  rcvd: 110


dig -t mx faz.net

; <<>> DiG 9.9.5-3ubuntu0.14-Ubuntu <<>> -t mx faz.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45921
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;faz.net.   IN  MX

;; ANSWER SECTION:
faz.net.900 IN  MX  110
mail-cust3.eu.lambdanet.net.
faz.net.900 IN  MX  50 mailx.faz.net.

dig mailx.faz.net

; <<>> DiG 9.9.5-3ubuntu0.14-Ubuntu <<>> mailx.faz.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30248
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;mailx.faz.net. IN  A

;; ANSWER SECTION:
mailx.faz.net.  900 IN  A   51.255.44.26


dig mail-cust3.eu.lambdanet.net

; <<>> DiG 9.9.5-3ubuntu0.14-Ubuntu <<>> mail-cust3.eu.lambdanet.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46613
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;mail-cust3.eu.lambdanet.net.   IN  A

;; ANSWER SECTION:
mail-cust3.eu.lambdanet.net. 86400 IN   A   80.86.168.150



Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: ebay-kleinanzeigen (war: Spam-Probleme (v.a. Versicherungs-Spam), wo ist mein Config-Problem?)

[Robert Schetterer]

Am 13.06.2017 um 14:14 schrieb Marco Dickert:
> On 2017-06-13 13:41:57, Walter H. wrote:
>> ist eigentlich die Reinheit der Logik, würdest Du ein Unternehmen
>> beauftragen Kataloge zu produzieren und zu versenden, dann geht dich auch
>> das nichts an, welche Kataloge nicht zugestellt werden können ...
>>
>> hättest sie hingegen selbst zum Versand zur Post gebracht, dann würdest Du
>> auch wissen, welche nicht zugestellt werden können ...
> 
> Wo genau ist der Unterschied ob ich die Kataloge über das Unternehmen XY oder
> über das Unternehmen "Deutsche Post" verschicke? Solange ich die Zieladressen
> vorgebe, sollte ich wissen dürfen, welche Adresse nicht erreichbar ist.
> 
> Viele Grüße,
> 

Also allgem ist Mail Newsletter Versand als Service
ein voellig legaler Geschaeftsbereich.

Durchaus nicht billig  Es gibts da sehr gute serioese Firmen.
Das Tracking der Empfaenger ist da technisch sehr weit entwickelt
wenn der Auftraggeber und der Dienstleister ihre Arbeit gut machen
steht im Vordergrund den Empfaenger moeglichst zielgerichtet,
zuverlaessig und puenktlich zu erreichen.

Man hat also bei einer Werbe Kampagne nichts davon wenn Emails bouncen
und/oder in Spam Ordnern
verschwinden und sucht eben genau das zu verhindern und den
Adressbestand moeglichst perfekt zu pflegen.

Die Weitergabe
von bounces ist technisch dafuer "nicht unbedingt" zwingend erforderlich
kann aber doch hilfreich sein. Denn will man etwas verkaufen /
informieren liegt einem was an seiner Reputation ( was nicht nur
technisch gemeint ist ).

Ich hab in Vergangenheit oft auf diese Firmen verwiesen, wenn die
Kampagnen ueber eine gewisse Groesse hinausgingen welche z.B
die eigenen Firmenmailserver ueberlasten koennten oder kein geeignetes
Personal zur technischen Abwicklung zur Verfuegung stand usw.

Ein Problem wird entsteht meist dann wenn man fuer seine Kampagne
kein Geld ausgeben will oder sich an einen "schlechten" Dienstleister
wendet.

Real gibts natuerlich auch eine Menge schwarze Schafe denen alles egal
istund die nur auf "fluten" setzen.

Ebay ist meiner Meinung nach so ein Zwischending, im Prinzip eine
Verkaufsplattform die auch allerlei technische Unterstuetzung bietet
man sollte sich als Auftraggeber/Verkaeufer halt Gedanken machen ob
dieses Angebot fuer das eigene Geschaeft zielfuehrend ist

Ansonsten gibts wie immer keine "perfekte" Welt


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: ebay-kleinanzeigen (war: Spam-Probleme (v.a. Versicherungs-Spam), wo ist mein Config-Problem?)

[Robert Schetterer]

Am 13.06.2017 um 11:49 schrieb Patrick Ben Koetter:
> * Joachim Fahrner <j...@fahrner.name>:
>> Am 2017-06-12 12:09, schrieb Walter H.:
>>
>>> es hat auch nie jemand ein Mail gesehen, bei dem Emarsys gefragt hätte, ob
>>> man den Newsletter zustellen dürfe ...
>>>
>>> wie gesagt der obligatorische Hacken "ich stimme der Nutzung meiner Daten
>>> zu Werbezwecken zu" ist nicht zulässig;
>>
>> Streiten wir um des Kaisers Bart, oder was?
>>
>> Fakt ist: Emarsys scheint ein Dienstleister zu sein, der im Kundenauftrag
>> Newsletter versendet. Ob eine Zustimmung vorliegt, sollte dann ja wohl der
>> Auftraggeber prüfen (z.B. Online-Shop). Man kann doch jetzt nicht Emarsys
>> pauschal blockieren, nur weil vielleicht ein Kunde die Regeln nicht ganz so
>> strikt ausgelegt hat, wie einige Erbsenzähler das hier tun. Bleibt doch mal
>> auf dem Teppich!
> 
> Zur Ergänzung: Die Kunden stellen die Adressliste! Der ESP bietet den Service
> des Versands mit Auswertung etc. Dabei darf der ESP dem Kunden aus
> gesetzlichen Gründen nicht mitteilen welche Adressen bounces etc. generieren.

Nicht dein Ernst ?

> (Habe ich gestern abend auf dem MAAWG-Meeting erfahren. Da schwimm ich noch.
> Auf Nachfrage muss ich da selber nachfragen).
> 
> Es kann also sein, dass ein neuer Kunde mit einer Empfängerliste daherkommt,
> die erst einmal in Mailings "geputzt" werden muss.
> 
> Die ESPs bemühen sich im onboarding-Prozess schwarze Schafe zu identifizieren.
> Es wäre ein Leichtes, sich untereinander zu informieren und eine Schwarzliste
> für schwarze Schafe zu führen, aber das ist aus Datenschutzgründen nicht
> gestattet.
> 
> So muss jeder ESP die Arbeit also selber machen.
> 
> p@rick
> 



Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: ebay-kleinanzeigen (war: Spam-Probleme (v.a. Versicherungs-Spam), wo ist mein Config-Problem?)

[Robert Schetterer]

Am 12.06.2017 um 19:47 schrieb Walter H.:
> On 12.06.2017 18:00, Joachim Fahrner wrote:
>> Fakt ist: Emarsys scheint ein Dienstleister zu sein, der im
>> Kundenauftrag Newsletter versendet.
> es scheint nicht nur so, es ist auch so; und der Empfänger hat bei
> Emarsys NIE die Zustimmung erteilt ...
>> Ob eine Zustimmung vorliegt, sollte dann ja wohl der Auftraggeber
>> prüfen (z.B. Online-Shop).
> Falsch, es gilt das Datenschutzgesetz, welches eine Weitergabe von Daten
> grundsätzlich untersagt;
> derartige Klauseln in AGBs sind illegal;
>> Man kann doch jetzt nicht Emarsys pauschal blockieren,
> doch kann man ...
> 
> 

Hi,
koennten wir das Thema zum Abschluss bringen ... ich sehe da jetzt
keinen grossen Wissensgewinn mehr. Am Ende entscheidet doch jeder selbst
was fuer ihn Spam ist und welche Massnahmen er dagegen ergreifen will
und kann. Die Problematik ist ja nun auch nicht wirklich neu 


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: *.Zip Files im Anhang blockieren und automatische Mitteilung an den Absender.

[Robert Schetterer]

Am 31.05.2017 um 18:44 schrieb Joachim Fahrner:
> Hallo Lothar,
> 
> wozu soll das gut sein? Manchmal muss man größere Datenmengen
> komprimieren um sie als Mailanhang verschicken zu können. Was soll der
> Absender denn dann nehmen? 7z? lzw? Was wäre dann bei anderen
> Kompressionsmethoden der Vorteil?

Dann sagst  du dem Sender er soll die .zip in zb .txt umbenennen *g
diese Methoden werden haeufig genutzt ..., kommt halt drauf an was man
erreichen will, sicherer lebt man damit nicht wirklichund das ist
kein Ersatz fuer Virenscanner, kleine zip Anhaenge sind wiederum eher
ein Zeichen fuer Spam kann man z.b mit sieve rausfiltern/rejecten

> 
> Am 2017-05-31 18:09, schrieb Wolff, Lothar:
> 
>> Hallo
>>
>>  
>>
>> Ich möchte im Postfix einstellen
>>
>>  
>>
>> -   Alle *.Zip Anhänge sind nicht blockiert
>>
>>  
>>
>> -   Absender bekommt einen Hinweis dass er eine Zip Datei gesendet
>> hatte,
>>
>> die in das System nicht rein gelassen wird und das er diese bitte
>> nochmal in einem anderen Format senden möge usw. usw .
>>
>>  
>>
>>  
>>
>> Wo kann man das am Besten im Postfix einstellen ?
>>
>>  
>>
>> MfG
>>
>> Lothar Wolff
>>
> 



Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Blackhole-Lists

[Robert Schetterer]

Am 29.05.2017 um 14:16 schrieb Marc Risse:
> Hallo Liste,
> 
> das Thema kommt ja immer wieder mal auf:
> Wo bekommt man eine (gute) Liste von Blacklists her, mit denen Postfix,
> Policyd-Weight, SpamAssassin und so weiter gefüttert werden können?
> 
> Meine persönliche Quellen neben diverser HowTos ist die Liste von
> MxToolBox. Ich habe mir einen Check (Check_MK) geschrieben, welcher die
> Antworten der RBLs auswertet, um so z.B. tote Anbieter schneller zu
> identifizieren. Ja, auch ich war von der "plötzlichen" Abschaltung von
> rhsbl.ahbl.org und relays.ordb.org betroffen, die plötzlich nur noch
> Blacklist-Treffer lieferten (und auch weiterhin liefern). Naja, man
> lernt nie aus ;)
> 
> Vielleicht könnte man ein paar Konfigurationen zur Verfügung stellen,
> welche Einträge in welchen Tools Sinn ergeben und welche RBL-Dienste
> "aktuell" sind.
> Leider ist es ja so, dass z.B. in der Default-Konfiguration von
> policyd-weight nicht mehr existente RBLs enthalten sind... für den
> Anfänger bestimmt eine Hürde, die viel Zeit in Anspruch nehmen kann.
> Sollte ich von Euch etwas Input bekommen, würde ich dafür eine
> Domain/Webspace zur Verfügung stellen. Ich bin für Alles offen und
> hoffe, dass wir vielleicht eine schöne Page betreiben können die der
> aktuellen Situation entspricht.
> 
> Auch einige der RBLs im Postfix-Buch sind nicht mehr verfügbar. Da die
> 4. Auflage laut Peer noch ein wenig dauert, könnte man vielleicht auch
> in Kooperation mit Peer so etwas aufbauen...
> 
> Was meint Ihr?
> 
> 
> VG
> Marc
> 
> 

Am Ende wirst du nie aktuell sein 
Fuer Einsteiger z.B in einem Buch auf eben diese RBL Problematik hinweisen
Aber wenn du oder Peer sich diese Muehe machen wollen wird euch sicher
niemand aufhalten


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Ist ein CNAME bei einer rDNS Abfrage erlaubt?

[Robert Schetterer]

Am 15.05.2017 um 11:00 schrieb Tobi:
> Am 12.05.2017 um 19:25 schrieb Robert Schetterer:
>> Am 12.05.2017 um 10:06 schrieb Tobi:
>>>
>>> 241.48.140.185.in-addr.arpa. 2731 INCNAME   
>>> 241.192/26.48.140.185.in-addr.arpa.
>>> 241.192/26.48.140.185.in-addr.arpa. 931IN PTRpsp3.ntp.org.
>>>
>>>
>> erlaubt ist relativ, die Frage ist es ob es Sinn macht ...
>> zunaechst solltest du mal nachsehen welchen dns dein mailserver befragt
>> und ob dieser mal grundsaetzlich die richtige Antwort gibt.
> das obige Resultat ist vom DNS Server, den meine Mailserver befragen.
> Dabei handelt es sich um einen unbound Server, der direkt - ohne
> Forwarder - mit den authorativen Nameservern redet.
>> Ausserdem kann natuerlich aus beliebigen Gruenden eine DNS Abfrage mal
>> scheitern deshalb ist der default error in postfix fuer diesen check
>> auch tmp
> wenn es nur eine oder vereinzelte Mails gewesen wären, die abgelehnt
> wurden hätte mich das nicht weiter verwundert.
> Nur leider wird jede einzelne Mail von der ntp Mailingliste mit dieser
> Meldung abgelehnt.
> 
> Gruss
> 
> tobi
> 
> 

hm evtl mal an die engl Liste posten, ein solcher Sonderfall
koennte oefter mal auftreten, mal sehen was die Gurus sagen


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Ist ein CNAME bei einer rDNS Abfrage erlaubt?

[Robert Schetterer]

Am 12.05.2017 um 10:06 schrieb Tobi:
> Hallo zusammen
> 
> kurze Frage: habe gestern auf meinem Postfix den rDNS Check aktiviert via
> 
> reject_unknown_reverse_client_hostname
> 
> in der smtpd_client_restrictions
> Heute morgen konnte ich sehen, dass dabei die Mailingliste von ntp.org
> abgelehnt wird mit:
> 
> Client host rejected: cannot find your reverse hostname,
>  [185.140.48.241]
> 
> Eine Abfrage des rDNS der IP ergibt ein Resultat, welches ich in dieser
> Form noch nicht gesehen habe
> 
> 241.48.140.185.in-addr.arpa. 2731 INCNAME   
> 241.192/26.48.140.185.in-addr.arpa.
> 241.192/26.48.140.185.in-addr.arpa. 931IN PTRpsp3.ntp.org.
> 
> Gemäss kurzer Recherche im Internet müsste der CNAME erlaubt sein.
> Weiss jemand was der Grund ist, dass Postfix meint den reverse Hostnamen
> nicht finden zu können?
> 
> Gruss
> 
> tobi
> 
> 

erlaubt ist relativ, die Frage ist es ob es Sinn macht ...
zunaechst solltest du mal nachsehen welchen dns dein mailserver befragt
und ob dieser mal grundsaetzlich die richtige Antwort gibt.

Ich vermute ein cname ist dann aehnlich wie mehrere Eintraege, das
heisst das ist dann wie wuerfeln welches Resultat du gerade erhaelst.

Ausserdem kann natuerlich aus beliebigen Gruenden eine DNS Abfrage mal
scheitern deshalb ist der default error in postfix fuer diesen check
auch tmp


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Spam-Probleme (v.a. Versicherungs-Spam), wo ist mein Config-Problem?

[Robert Schetterer]

Am 08.05.2017 um 19:01 schrieb Martin Sebald:
>>> danke für Eure Antworten. Uwe, mir erscheint Deine Methode doch etwas arg
>>> rigoros. Sicherlich erfolgreich, aber erwischt man da nicht auch welche, die
>>> es nicht erwischen soll?
>> Uwe hat das schon laenger im Auge und er scheint sich ziemlich sicher
>> dass es so OK ist, auf jedem Fall eine schnelle Loesung fuer den Notfall
> 
> Vielleicht kann Uwe ja ein klein wenig ins Detail gehen. Wie lange im Einsatz?
> Selbst schon Ham Verlust gehabt dadurch? Eventuell auch, wieviele Domains an
> dem Mailserver dran hängen.

check_sender_ns_access ist der "DNS Server" , also sehr weitreichend
Uwe meinte bis jetzt kein Problem mit seinem Vorschlag ( und ich glaub
ihm das ), es ist also sehr wahrscheinlich das hier richtiges
"Marketing" betrieben wird, der Begriff SPAM entsteht ja hauptsaechlich
im Auge des Betrachters, die Methode ist ein sehr weitreichender
Rundumschlag und kann praktisch von jetzt auf nachher schief gehen, oder
unwirksam werden, trotzdem kann man sie natuerlich anwenden. Ein
typisches Anwendungsgebiet ist diese z.B fuer geparkte Domains
anzuwenden siehe

https://lists.gt.net/spamassassin/users/189142

Vorteil man braucht keinen Spamassassin sondern nur Postfix

> 
>>> bayes_auto_learn_threshold_nonspam -1.0
>> Lösung müsste ich a detail nachlesen,grad keine Zeit, in jedem Fall
>> besser der content scanner erkennt den SPAM jetzt
> 
> Ja, das dachte ich mir auch. Lieber den Spam getaggt bekommen (und so wie es
> nach ein paar Tagen ausschaut auch sehr zuverlässig und ohne false positives)
> als Ham mit geringerer Wertung weil dieser in der Bayes Datenbank als Ham
> drinnen wäre...
> 
> Habe die Lösung hier beschrieben falls jemand ähnliche Probleme hat oder haben
> wird. Parallel freue mich mich natürlich dennoch auf weitere Hinweise, gerne
> auch dieser Lösung bezüglich. Es gibt ja immer etwas zu verbessern denke ich. 
> ;-)
> 
> Viele Grüße
> Martin
> 



Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Spam-Probleme (v.a. Versicherungs-Spam), wo ist mein Config-Problem?

[Robert Schetterer]

Am 08.05.2017 um 16:13 schrieb Martin Sebald:
> Hallo Uwe und Robert,
> 
> danke für Eure Antworten. Uwe, mir erscheint Deine Methode doch etwas arg
> rigoros. Sicherlich erfolgreich, aber erwischt man da nicht auch welche, die
> es nicht erwischen soll?

Uwe hat das schon laenger im Auge und er scheint sich ziemlich sicher
dass es so OK ist, auf jedem Fall eine schnelle Loesung fuer den Notfall

> 
> Robert, habe nicht viel geschrieben, das stimmt. Habe dann noch weiter gesucht
> und bin nun hergegangen und habe an einer Stelle (in der local.cf von
> Spamassassin) etwas verändert:
> 
> bayes_auto_learn_threshold_nonspam -1.0
> 
> Der Default hier ist 0.1 und das sorgte vermutlich dafür, dass Spam Mails auch
> gerne mal als Ham angelernt wurden.
> 
> Habe dann die Bayes Datenbank gelöscht und mit den vorhandenen Spamnachrichten
> (mehrere 1, vom Spamarchiv von untrusted.org mal abgesehen) neu befüllt.
> Die Datenbank zeigt mir nun auch nach wie vor 0 Ham Nachrichten an, die
> gelernt wurden. Auch nicht toll, aber besser als die bisherige Situation.
> 
> Seither kommen fast keine Spams mehr durch. Von 20 am Tag eventuell mal eine,
> meist gar keine. Auch finde ich keine False Positives im Spamordner. Aber gut,
> ist nun erst wenige Tage her, mal abwarten.
> 
> Folgende Seiten habe ich im Netz gefunden und o.g. dann abgeändert:
> 
> https://wiki.apache.org/spamassassin/BasicConfiguration
> http://spamassassin.1065346.n5.nabble.com/bayes-auto-learn-threshold-nonspam-td111659.html
> 
> Viele Grüße,
> Martin
> 

Lösung müsste ich a detail nachlesen,grad keine Zeit, in jedem Fall
besser der content scanner erkennt den SPAM jetzt


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Spam-Probleme (v.a. Versicherungs-Spam), wo ist mein Config-Problem?

[Robert Schetterer]

Am 04.05.2017 um 11:59 schrieb Uwe Drießen:
> Von: postfix-users [mailto:postfix-users-> 
> bounces+driessen=fblan...@de.postfix.org] Im Auftrag von Martin Sebald
>>
>> Hallo zusammen,
>>
>> in letzter Zeit habe ich massive Probleme mit Spam. Vor allem kommt sehr
>> sehr
>> viel "Versicherungs-Spam" (Berufshaftpflicht, Krankenversicherung...) rein.
>> Alleine mein eigener Account bekommt hier mehr als ein Dutzend Mails pro
>> Tag.
>>
>> Mein Mailserverkonstrukt ist Postfix/Amavis/Spamassassin, also mehr oder
>> weniger Standard, und ich erlaube mir mal, hier zu posten, auch, wenn das
>> Thema mehr Richtung Amavis und Spamassassin geht. Falls das nicht ok ist,
>> bitte sagen.
>>
> 
> In der Regel von info@  AN info@
> Alle auf nur wenigen DNS servern 
> 
> 
> reject: RCPT from mxsrv-1.pkvtarifueberblick.com[31.14.135.80]: 550 5.7.1 
> <info@"beispiel".com>: Sender address rejected: your DNS server is hosting 
> spam provider 
> 
>Name Server: DNS1.REGISTRAR-SERVERS.COM
>Name Server: DNS2.REGISTRAR-SERVERS.COM
> 
> check_sender_ns_access hash:/etc/postfix/maps/bogus_dns,
> 
> DNS1.REGISTRAR-SERVERS.COM  550 your DNS server is hosting spam provider 
> #sexspam
> DNS2.REGISTRAR-SERVERS.COM   550 your DNS server is hosting spam provider 
> #sexspam
> DNS3.REGISTRAR-SERVERS.COM   550 your DNS server is hosting spam provider 
> #sexspam
> DNS4.REGISTRAR-SERVERS.COM   550 your DNS server is hosting spam provider 
> #sexspam
> DNS5.REGISTRAR-SERVERS.COM   550 your DNS server is hosting spam provider 
> #sexspam
> 
> 
> Damit sollte kaum noch Versicherungsspam kommen :-))
> 

@Uwe
das kann zwar helfen, ist aber schon sehr weitreichend bissl mit
Kanonen auf Spatzen geschossen...

@orgin
du hast ein bisschen wenig Infos geliefert , evtl sollte du damit besser
an die spamassassin liste und vollstaendige Beispiel Mails liefern

> 
> 
> Mit freundlichen Grüßen
> 
> Uwe Drießen
> --
> Software & Computer
> 
> Netzwerke, Server. 
> Wir vernetzen Sie und Ihre Rechner !
> 
> Uwe Drießen
> Lembergstraße 33
> 67824 Feilbingert
> 
> Tel.: 06708660045
> 



Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: ich werde der Spamflut nicht Herr - postfix amavis-new dovecot

[Robert Schetterer]

Am 06.04.2017 um 12:04 schrieb Christoph P.U. Kukulies:
> Die Vornamen und Texte der Damen sind allesamt engl.,
> 
> chri...@boostmart.com  -> biblestudydiary.com
> jea...@bryair.com.br  -> host3.delairindia.com
> 
> Der Versicherungsspam eindeutig deutsch, habe aber im Moment kein Muster
> zur Hand.
> 
> Was macht postscreen in der Kette?

sorry das sprengt die liste

siehe z.b


https://dokuwiki.nausch.org/doku.php/centos:mail_c7:spam_3

https://blog.schaal-24.de/mail/postscreen-im-kampf-gegen-spam/

> 
> Grüße
> Christoph
> 
> 
> Am 06.04.2017 um 11:14 schrieb Robert Schetterer:
>> Am 06.04.2017 um 11:04 schrieb Christoph P.U. Kukulies:
>>> Sorry, hatte wohl einen falschen Adressaten angegeben. Verwechselt mit
>>> postfixbuch-users...
>>>
>>> Hier mein eigenliches Anliegen:
>>>
>>>
>>> Ubuntu 16.04.2 LTS,postgrey, MX_nolisting, postfix, amavis_new, clamav,
>>> spamassassin, dovecot:
>>>
>>> Ich habe immer noch das Problem, daß zu viele Mails in der Inbox landen
>>> und erst mein Mailclient (Thunderbird) ist dann günstigenfalls in der
>>> Lage, SPAM zu markieren.
>>>
>>> Manchmal ist eine Mail dabei, die im Subj: mit *SPAM* markiert
>>> ist (kommt von /etc/spamassassin/local.cf), manchmal eine mit +++SPAM+++
>>> - so habe ich es in /etc/amavis/conf.d/20-debian_defaults eingetragen,
>>> damit man überhaupt mal sehen kann, wer was und ob überhaupt was macht.
>>> Einmal war bereits ein false positive dabei. Aber sehr sehr selten, daß
>>> überhaupt eine Mail getaggt wird.
>>>
>>> Arbeiten da zwei Mechanismen "gegeneinander"?
>>>
>>> Ich lerne dauernd noch an, indem ich den mit Flämmchen versehen
>>> Thunderbird junk in junk kopiere und sa_learn drüberlaufen lasse.
>>> Nahezu ohne Erfolg. Es kommen vor allem Emails gleichen Typus durch.
>>> Entweder diese BU oder Betriebshaftpflicht, KV oder die
>>> Frauenname, 5 Zeilen Tätigkeits- oder sonstige Merkmale und  eine Zeile
>>> mit einem Link.
>> das klingt etwas nach deutschen spam
>>
>> da gibts ein paar extra rulesets
>>
>> http://zmi.at/x/70_zmi_german.cf
>>
>> clamav wuerde ich mit sanesecurity erweitern
>> razor , pyzor , dcc helfen auch
>> nolisting kannst du in die Tonne treten
>> postscreen ist nicht in deiner Aufzaehlung enthalten
>>
>>>
>>> Grüße
>>> Christoph
>>> Am 06.04.2017 um 10:56 schrieb Christoph P.U. Kukulies:
>>>> TEST. Wieso kriege ich bounces von der postfix-users Liste:
>>>>
>>>>The mail system
>>>>
>>>> <postfix-us...@listen.jpberlin.de>: host
>>>> mx1.jpberlin.de[91.198.250.10] said:
>>>>  577 5.1.1<postfix-us...@listen.jpberlin.de>: Recipient address
>>>> rejected:
>>>>  undeliverable address: host ilpostino.jpberlin.de[213.203.238.6]
>>>> said: 550
>>>>  5.1.1<postfix-us...@listi.jpberlin.de>: Recipient address
>>>> rejected: User
>>>>  unknown in local recipient table (in reply to RCPT TO command) (in
>>>> reply to
>>>>  RCPT TO command)
>>>>
>>>>
>>
>>
>> Best Regards
>> MfG Robert Schetterer
>>
> 



Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Spam über ein Maillkonto - bei GMX geblacklistet

[Robert Schetterer]

Am 06.04.2017 um 11:44 schrieb Frank Röhm:
> Am 20.03.2017 um 10:33 schrieb Frank Röhm:
>>
>> ...
>> Au weh!
>> Jetzt ist unser Server mit seiner IP anscheinend bei Gmail geblockt.
>> Ich habe etwas gesucht und doch tatsächlich auch ein Formularautomat 
>> gefunden, wo ich einiges an Informationen eintragen musste/konnte:
>>
>> https://support.google.com/mail/contact/msgdelivery
>>
>> Ich schrieb u.a.:
>>
>>> Hallo, two weeks ago an account of our server was hacked and has sent many 
>>> spam mails. I discovered this abuse only hours ago and stopped it. 
>>> But it seems that Gmail has put our servers IP (37.120.188.94) on a 
>>> Blacklist. 
>>> Our issue is solved two weeks ago, could you remove us from your blacklist? 
>>> Thank you.
>>> It seems that our IP is blocked and not only domain names. We have several 
>>> domains under one IP, all seem blocked.
>>
>> Mal sehen, ob das auch wieder so lange dauert...
>>
> 
> 
> Oh Man! Der ist immer noch geblacklistet, scheint es!
> Glücklicherweise nur die Domain, nicht die IP, unsere Kunden mit anderen
> Domains, selber IP sind daher nicht betroffen, aber es ist jetzt schon
> ein Monat her!
> Ich weiß nicht was ich machen kann.
> Das Formular habe ich schon zwei Mal ausgefüllt, da kam natürlich nie
> eine Antwort.
> 
> 
> 
> 

gmail via transport ueber ein relay leiten dessen ip nicht geblacklistet
ist...
ausserdem solltest du sicherstellen dass deine gmail empfaenger nicht
einfach eine eigene filter rule eingepflegt haben und diese noch nicht
wieder entfernt haben


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: ich werde der Spamflut nicht Herr - postfix amavis-new dovecot

[Robert Schetterer]

Am 06.04.2017 um 11:04 schrieb Christoph P.U. Kukulies:
> Sorry, hatte wohl einen falschen Adressaten angegeben. Verwechselt mit
> postfixbuch-users...
> 
> Hier mein eigenliches Anliegen:
> 
> 
> Ubuntu 16.04.2 LTS,postgrey, MX_nolisting, postfix, amavis_new, clamav,
> spamassassin, dovecot:
> 
> Ich habe immer noch das Problem, daß zu viele Mails in der Inbox landen
> und erst mein Mailclient (Thunderbird) ist dann günstigenfalls in der
> Lage, SPAM zu markieren.
> 
> Manchmal ist eine Mail dabei, die im Subj: mit *SPAM* markiert
> ist (kommt von /etc/spamassassin/local.cf), manchmal eine mit +++SPAM+++
> - so habe ich es in /etc/amavis/conf.d/20-debian_defaults eingetragen,
> damit man überhaupt mal sehen kann, wer was und ob überhaupt was macht.
> Einmal war bereits ein false positive dabei. Aber sehr sehr selten, daß
> überhaupt eine Mail getaggt wird.
> 
> Arbeiten da zwei Mechanismen "gegeneinander"?
> 
> Ich lerne dauernd noch an, indem ich den mit Flämmchen versehen
> Thunderbird junk in junk kopiere und sa_learn drüberlaufen lasse.
> Nahezu ohne Erfolg. Es kommen vor allem Emails gleichen Typus durch.
> Entweder diese BU oder Betriebshaftpflicht, KV oder die
> Frauenname, 5 Zeilen Tätigkeits- oder sonstige Merkmale und  eine Zeile
> mit einem Link.

das klingt etwas nach deutschen spam

da gibts ein paar extra rulesets

http://zmi.at/x/70_zmi_german.cf

clamav wuerde ich mit sanesecurity erweitern
razor , pyzor , dcc helfen auch
nolisting kannst du in die Tonne treten
postscreen ist nicht in deiner Aufzaehlung enthalten

> 
> 
> Grüße
> Christoph
> Am 06.04.2017 um 10:56 schrieb Christoph P.U. Kukulies:
>> TEST. Wieso kriege ich bounces von der postfix-users Liste:
>>
>>   The mail system
>>
>> <postfix-us...@listen.jpberlin.de>: host
>> mx1.jpberlin.de[91.198.250.10] said:
>> 577 5.1.1<postfix-us...@listen.jpberlin.de>: Recipient address
>> rejected:
>> undeliverable address: host ilpostino.jpberlin.de[213.203.238.6]
>> said: 550
>> 5.1.1<postfix-us...@listi.jpberlin.de>: Recipient address
>> rejected: User
>> unknown in local recipient table (in reply to RCPT TO command) (in
>> reply to
>> RCPT TO command)
>>
>>
> 



Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Verständnisproblem access restrictions

[Robert Schetterer]

Am 27.03.2017 um 07:54 schrieb Joachim Fahrner:
> Am 2017-03-27 07:40, schrieb Joachim Fahrner:
>> Ich bin gerade dabei
>> meine Regeln nochmal umzustrukturieren, alles sauber zu trennen wie es
>> sich gehört.
> 
> Mist, das wird schwieriger als gedacht. Nach dem Buch "Postfix" von Ralf
> und Patrick soll man ja die "role accounts" niemals blocken. D.h. diese
> Prüfung muss vor die Blacklistabfragen. Packt man die in die client
> restrictions (wo sie logisch ja hingehören) ist der Empfänger aber noch
> nicht bekannt.
> 
> Jochen

das stimmt, wenn man allerdings die rbls sparsam verwendet
ist das kein grosses Problem, du kannst ja eh nichts dagegen tun wenn
jemand bei spamhaus gelistet ist ,diese Info bekommt der Absender ja in
jedem Fall bei der Ablehnung , es ist also Sache des Absenders von den
rbls runter zu kommen, das gilt auch dann wenn er zu postmaster senden will.
Fuer diesen Fall konnte man auch zusaetzlich eine Website anbieten
mit einem script zum Einliefern fuer Support Mails, oder einer
alternative Adresse bei einem anderen Anbieter.
An sich ist eine so eine Website immer eine gute Idee , Nachteil ist
eigentlich nur dass man sich zusaetzlich um einen Webserver kuemmern muss.


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: SRS nur für bestimmte Mails? Oder andere Lösung?

[Robert Schetterer]

Am 23.03.2017 um 20:16 schrieb Uwe Drießen:
> Ich bin kein Freund dieser Weiterleitunggeschichten

ACK klassischer forward ist eigentlich tot
schoen waere zb mit sieve die orig Mail als Attachment weiterleiten
aber selbst das wuerde nicht alle Probleme richten, denn es besteht
immer die Gefahr Viren oder Spam weiterzuleiten das wird dann dem
Weiterleitenden angerechnet kann also grob ins Auge gehen

Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Selektives Greylisting

[Robert Schetterer]

Am 23.03.2017 um 09:27 schrieb Joachim Fahrner:
> Hallo Liste,
> ich bin wieder mal am Tuning meiner Konfiguration ;-)
> Vor einiger Zeit hatte ich mal blind Roberts selektives Greylisting
> übernommen, wie hier beschrieben:
> https://sys4.de/de/blog/2013/10/09/selektive-rbl-spf-greylisting-checks-mit-smtpd_restriction_classes/
> 
> 
> Jetzt habe ich die Beschreibung nochmal genauer gelesen, und dabei ist
> mir etwas aufgefallen:
> In smtpd_client_restrictions wird zuerst mynetworks und
> sasl_authenticated erlaubt.
> Als nächstes werden die 3 access Tabellen geprüft, und bei Treffern die
> 3 Klassen ausgeführt. Diese beginnen jeweils wieder mit
> permit_mynetworks und permit_sasl_authenticated. Ist das nicht doppelt
> gemoppelt? mynetwork und sasl_authenticated müsste doch schon ganz am
> Anfang mit permit die client_restrictions verlassen haben.
> Oder hab ich da was falsch verstanden?
> 
> Jochen
> 
> 

 doppelt moppeln verhindert dass wenn du z.b spaeter mal in
smtpd_client_restrictions drueber was einschiebst
du permit_mynetworks und permit_sasl_authenticated
unbeabsichtigt overridest

denk dran das ist kein vollstaendige config sondern soll nur
demonstrieren wie man Selektives Greylisting umsetzen "kann"
du kannst das nach belieben aendern, aus meiner sicht ist die hauptsache
dass man es etwas inteligenter macht als einfach auf alles draufzuhaun

Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Verständnisproblem access restrictions

[Robert Schetterer]

Am 20.03.2017 um 19:25 schrieb J. Fahrner:
> Am 20.03.2017 um 19:17 schrieb Robert Schetterer:
>> Am 20.03.2017 um 11:04 schrieb Marco Dickert:
>>> dass Peer Heinlein
>>> empfiehlt, alle Restrictions in die smtpd_recipient_restrictions zu packen
>> finde ich unuebersichtlich, aber vermutlich koennte man auch genau
>> andersrum argumentieren
>>
> 
> Stimmt schon, übersichtlicher ist es wenn man es trennt. Aber leider
> müssen dann viele Prüfungen redundant durchgeführt werden. Ich habe z.B.
> eine access-Liste mit Ausnahmen, die müsste ich dann zu jedem Zeitpunkt
> immer wieder prüfen. Ich hab das jetzt mal alles unter
> recipient_restrictions zusammengeführt, aber per Kommentarzeile nach den
> zeitpunkten getrennt. So bleibt die Übersicht erhalten.
> 

kannst du machen ist nicht unbedingt falsch, ich nutze haeufig
Kombinationen aus seperaten und kombinierten whitelists
oft waechst sowas ja auch historisch, real laufen setups ja manchmal
Jahre, im Betrieb aendert man dann eher weniger , wenn man dann einen
neuen Server aufsetzt baut man dann Neuerungen ein die sich woanders
schon bewaehrt haben. Allerdings ist es wirklich nicht mehr leicht immer
up2date zu sein



Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Verständnisproblem access restrictions

[Robert Schetterer]

Am 20.03.2017 um 14:57 schrieb Joachim Fahrner:
> Mit Postscreen habe ich mittlerweile ein kleines Problem: wenn ich darin
> aggressive Blacklisten verwende (z.B. Sorbs), 

ja das ist gelinde gesagt exotisch

dann wird zuviel geblockt
> und ich habe an der Stelle keine Möglichkeit bestimmte Absender zu
> whitelisten. Das könnte ich nur bei den recipient_restrictions. Ich
> überlege gerade, ob es Sinn machen würde, bei postscreen nur weniger
> aggresive Blacklists einzutragen, und in recipient_restrcitions die
> aggressiveren, und davor eine whitelist.

ich nutze nur zen.spamhaus in postscreen
Whitelist brauchts real immer

ein Vorteil der
restrictions

ist dass du relativ billig zusaetzlich selectiv separieren kannst

https://sys4.de/de/blog/2013/10/09/selektive-rbl-spf-greylisting-checks-mit-smtpd_restriction_classes/

so waere es evtl sogar vertretbar sorbs zu nutzen

Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Verständnisproblem access restrictions

[Robert Schetterer]

Am 20.03.2017 um 11:04 schrieb Marco Dickert:
> dass Peer Heinlein
> empfiehlt, alle Restrictions in die smtpd_recipient_restrictions zu packen

finde ich unuebersichtlich, aber vermutlich koennte man auch genau
andersrum argumentieren


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: ich werde der Spamflut nicht Herr - postfix amavis-new dovecot

[Robert Schetterer]

Am 15.03.2017 um 15:03 schrieb Lars Täuber:
> Hallo!
> 
> Mon, 13 Mar 2017 19:31:18 +0100
> Robert Schetterer <r...@sys4.de> ==> postfix-users@de.postfix.org :
>> Am 13.03.2017 um 16:50 schrieb Lars Täuber:
>>> Ist es unpassend für die Liste nach den Ergebnisse anderer/eurer 
>>> Spamfilterungen zu fragen?  
>>
>> clamav milter mit sanesecurity
>> spamassassin als milter ( inkl. aktuellen Regeln  ) und ansonsten
>> spamhouse rbl )
>> inklusive postfix best practice ,sollten dir den standard spam von Leib
>> halten,
> 
> Wo kann ich denn diese "best practice" nachlesen? Das habe ich nun schon des 
> öfteren gelesen, ohne dass ich wusste was es bedeutet.

das meint , "pseudo" standards beim Einrichten von Postfix die sich im
realen Umfeld bewaehrt haben

lies mal z.b

http://jimsun.linxnet.com/misc/postfix-anti-UCE.txt

> 
>> den Rest musst du dir gesondert ansehen und dann entscheiden
>> was Sinn macht.
> 
> Mir ist klar, dass jedes Unternehmen mit seiner Nutzerstruktur andere 
> Ergebnisse hat. Aber gibt es dazu Zahlen, wie gut diese Einstellungen sind?
> Bisher ging ich davon aus, dass unsere Ergebnisse ganz gut sind, und der 
> Aufwand (Manpower & Rechenpower) das noch wesentlich zu verbessern sich nicht 
> lohnt.

im subject steht, spamflut usw , d.h du willst was tun
logischerweise wird es ab einem gewissen Punkt ( nach den ueblichen
Methoden ) immer schwieriger, das geht nur ueber taegliche log analyse
Mail ist heute nichts mehr fuer Laien oder Nebenher Admins wenn man es
ernst nimmt

> 
> Wir setzen bisher nur auf:
> * greylisting auf port 10023
> 
> main.cf:
> smtpd_helo_required = yes
> smtpd_helo_restrictions =
> check_helo_access   btree:/etc/postfix/helo_access
> reject_non_fqdn_helo_hostname
> reject_invalid_helo_hostname
> permit_mynetworks
> reject_unknown_helo_hostname
> 
> 
> smtpd_sender_restrictions   =
> reject_non_fqdn_sender
> permit_mynetworks
> check_sender_access btree:/etc/postfix/sender_access
> reject_unknown_sender_domain
> check_sender_mx_access  cidr:/etc/postfix/bogon_networks.cidr
> check_sender_ns_access  cidr:/etc/postfix/bogon_networks.cidr
> reject_unverified_sender
> 
> smtpd_relay_restrictions=
> check_recipient_access  pcre:/etc/postfix/recipient_access
> reject_unknown_recipient_domain
> permit_mynetworks
> reject_unverified_recipient
> reject_unauth_destination
> check_policy_serviceinet:localhost:10023
> defer_unauth_destination
> 
> 
> zum Nutzer hin:
> * kaspersky
> * dspam
> 
> 
> Danke und Gruß
> Lars
> 

sieht erstmal gar nicht schlecht aus, ist aber sicher noch erheblich
erweiterungsfaehig


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: ich werde der Spamflut nicht Herr - postfix amavis-new dovecot

[Robert Schetterer]

Am 13.03.2017 um 16:50 schrieb Lars Täuber:
> Ist es unpassend für die Liste nach den Ergebnisse anderer/eurer 
> Spamfilterungen zu fragen?

clamav milter mit sanesecurity
spamassassin als milter ( inkl. aktuellen Regeln  ) und ansonsten
spamhouse rbl )
inklusive postfix best practice ,sollten dir den standard spam von Leib
halten, den Rest musst du dir gesondert ansehen und dann entscheiden
was Sinn macht.


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: 1&1 Spam

[Robert Schetterer]

Am 11.03.2017 um 19:33 schrieb Joachim Fahrner:
> Hallo Robert,
> 
> Am 2017-03-11 17:31, schrieb Robert Schetterer:
>> Ich kann uebrigens nicht wirklich bestaetigen das von dort mehr spam
>> kommen wuerde als von sonstwo, aber jeder hat seinen eigenen spam
> 
> das mag schon sein, aber die Situation ist halt die: ich nutze sehr
> aggressive Blacklisten, u.a. sogar sorbs.net. Das ist kein Problem
> solange die Mails aus dem Ausland kommen, da habe ich so gut wie keine
> Kontakte. Und die Server von T-Online und GMX habe ich auf einer
> Whitelist, von da kommt auch so gut wie kein Spam. Problem ist nur
> mout.kundenserver.de, das ist offenbar der MX für die 1&1 Webspaces und
> Mietserver. Anders als bei GMX und T-Online kümmert sich da wohl niemand
> darum den Misbrauch zu verhindern. Von da bekomme ich regelmässig
> Phishing-Mails. Das wäre für mich noch nicht so tragisch, ich erkenne
> die auf den ersten Blick und lösche die einfach. Mein Mailserver ist
> aber für die ganze Familie, und gerade die Kids sind da halt noch nicht
> so erfahren, und ich möchte sie vor solchen Phishing-Mails schützen. Die
> sind nämlich mittlerweile täuschend echt gemacht, manchmal muss ich
> selbst sogar rätseln ob die Mail echt ist oder ein Fake.
> 
> Gruss
> Jochen

Hallo Jochen , so wie ich das sehe ,wirst du das Problem mit vertretbaren
Aufwand auf Dauer nicht loesen koennen. Eine einfache Loesung koennte
sein alle Mails von mout.kundenserver.de auf hold zu nehmen ( mit
Alarming ) und erst nach deiner Begutachtung an andere
Familienmitglieder per Hand zuzustellen ( release from hold ).
Alternativ eine haertere Antispam Policy per User hinzufuegen aber auch
das braucht ausgiebige Pflege, ausser du verlegst dich darauf z.b an
deine Kinder gar keine Mails von 1u1 mehr zuzustellen.

Grade bei Kindern kommt es beim Filtern ( das gilt auch beim Web )
sehr auf das Alter an. Sind die Kinder klein ist es einfach
da verbietet man alles und gibt ein paar Sachen extra frei, je aelter
umso schwieriger , am Ende hilft eben nur wie bei anderen Usern auch der
Hinweis im Zweifel Papi/Admin fragen.

Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Spam über ein Maillkonto - bei GMX geblacklistet

[Robert Schetterer]

Am 11.03.2017 um 23:20 schrieb Frank Röhm:
> 
>> Am 11.03.2017 um 17:38 schrieb Robert Schetterer <r...@sys4.de>:
>>
>> Kann schon sein dass es mal eine Woche dauert, ansonsten immer wieder
>> schreiben ,mehr bleibt nicht
> 
> Dann ist noch ein großes Problem, das ich nicht verstehe: Heute, etwa 5 Tage 
> nach dem Befall, kommt erst eine Meldung von Mailer Daemon, dass  GMX ein 
> Mail vom 6. März, einen Tag nach dem Befall, abgelehnt hatte:
> 
> … status=deferred (host mx01.emig.gmx.net[212.227.17.5] refused to talk to 
> me: 554-gmx.net (mxgmx106) Nemesis ESMTP Service not available 554-No SMTP 
> service 554-IP address is black listed. 554 For explanation visit 
> http://postmaster.gmx.com/en/error-messages?ip=37.120.188.94=bip) …
> 
> 5 Tage später! Warum so eine Verzögerung? So merken die Benutzer ja lange gar 
> nicht, dass ihre Mails an GMX gar nicht ankommen. 
> Das mail.log hat über 500 MB (wg. der vielen Spammails) kann es daran liegen?
> 
> 
> 

sehr wahrscheinlich lag die Mail 5 Tage lang in einer Warteschlange,
denn 5 Tage sind die Standard Einstellung. Fuer gewoehnlich kann man
grosse Mengen Mails gar nicht so schnell loswerden an grosse
Mailprovider ( ausser man nutzt ein paar Tricks ), wenn du das genau
wissen willst musst du dein log sichten. Mail ist kein Real Zeit Medium
,5 Tage Verzoegerung sind technisch noch ok. Ich gebe zu, die
Erwartungshaltung ist eine andere.


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Spam über ein Maillkonto - bei GMX geblacklistet

[Robert Schetterer]

Am 11.03.2017 um 13:52 schrieb Frank Röhm:
> Hallo
> 
> Ich hab auf meinem root Server (Ubuntu 14 LTS) ein Postfix (Version 
> 2.11.0-1ubuntu) laufen und da ging von einem Konto dessen Passwort gehackt 
> wurde am 5. März um 14:20 etwa massenweise Spam raus.
> Der Spuk dauerte ca. eine halbe Stunde, bis ich es gemerkt hatte, da waren 
> aber wohl schon zigtausend Spammails rausgegangen, mit der Folge, dass GMX 
> unseren Server geblacklistet hat.
> 
> 1. wie krieg ich unseren Server aus der Blacklist von GMX raus? Ich hab da 
> schon über so ein Kontaktformular hingeschrieben, aber keine Antwort gekriegt 
> und noch ist er gelistet. Muss ich einfach warten?  Der Fehler ist ja erst 
> mal behoben.

Kann schon sein dass es mal eine Woche dauert, ansonsten immer wieder
schreiben ,mehr bleibt nicht

> 2. wie kann ich solche Massen an Mails auf ein Mal von vorne herein 
> verhindern, da gibt es doch sicher eine Einstellung, oder? Das braucht doch 
> keiner.

eigentlich geht es darum den Hack zu verhindern bzw zu erkennen ( hoeh
Kunst ), ansonsten kannst du eigentlich nur die Auslieferung aller Mails
verzoegern oder eine Quota bei der Einlieferung einfuehren, alles
Kruecken die meist irgendwann Aerger verursachen, eine einfach Variante
waehre wohl eine Alarming auf die Anzahl der Mails in der Warteschleife
zu setzen, das setzt aber dann auch voraus das du sehr schnell reagieren
kannst.

> 
> 
> Danke
> 
> Gruß frank Walter
> 



Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Mails kommen doppelt und dreifach an

[Robert Schetterer]

Am 11.01.2017 um 17:42 schrieb J. Fahrner:
> Hallo,
> 
> habe letzes Wochenende meinen Server von Debian Wheezy auf Devuan Jessie
> aktualisiert. Nun habe ich komische Phänomene. Kann Zufall sein, oder
> auch nicht. Ich meine jedenfalls, alles korrekt übernommen zu haben.
> 
> Manchmal bekomme ich die gleiche Mail mehrfach. Heute kam von Amazon
> eine 2 mal, und jetzt aus einem anderen Online-Shop die gleiche Mail
> sogar 3 mal! Im Log sieht das so aus als hätte der fremde Mailserver die
> wirklich 3 mal geschickt. So geht das los:
> 
> Jan 11 17:02:21 s4 postfix/postscreen[28814]: CONNECT from
> [52.58.63.0]:49380 to [172.31.1.100]:25
> Jan 11 17:02:22 s4 postfix/postscreen[28814]: CONNECT from
> [52.58.63.9]:46498 to [172.31.1.100]:25
> Jan 11 17:02:23 s4 postfix/postscreen[28814]: CONNECT from
> [52.58.63.12]:56492 to [172.31.1.100]:25
> Jan 11 17:02:27 s4 postfix/postscreen[28814]: PASS NEW [52.58.63.0]:49380
> 
> Kann das sein, dass manche Mailserver nicht damit klar kommen, dass
> Postscreen die Verbindung beim ersten Kontakt verzögert?

ja das kann sein, aber das resultat sollte dann eher sein dass eine Mail
nie ankommt, eine Verdoppelung geschieht fast immer wenn die Mail schon
angenommen wurde, durch nachgelagerte Prozesse
wenn du zb amavis als content filter verwendest ueberpruefe das nochmal,
lmtp mit sieve koennte auch sein

> 
> In diesem Fall schliesse ich Konfigurationsfehler bei mir eigentlich
> aus, denn 3 Connects von unterschiedlichen IPs innerhalb 3 Sekunden, die
> mir die gleiche Mail abliefern wollen, das kann doch nicht von meiner
> Seite verursacht sein, oder?

nun warum sollte dir die gleiche Mail nicht 3 mal von div ips zugestellt
werden..., ja der Fehler kann beim Absender liegen,
bzw ist das ein Massenproblem oder nur bei bestimmten Absendern
wenn du postscreen in Verdacht hast setzte die ips doch mal schnell in
eine Whitelist

> 
> MfG
> 
> Jochen
> 
> 




Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein