Blokkeren empty sender adres in Postfix

[Verwijderd]

Ik wil het null sender adres in Postfix blokkeren dus met het from field leeg.

Ik heb overal gezocht maar kan het gewoon nergens vinden in Google. Het lijkt wel of Postfix dit niet kan. Ik krijg regelmatig spam berichten die verstuurd worden vanuit mijn Postfix server met het adres from=<>

Ik heb bij de smtpd_recipient_restrictions deze regel er tussen staan:

check_sender_access hash:/etc/postfix/sender_checks

Waarin het bestand sender_checks het volgende staat:

[e-mail] OK
[e-mail] OK
[e-mail] OK
onsdomein.nl REJECT

Uiteraard ook een postmap hash:/etc/postfix/sender_checks gedaan.

Dan zou je verwachten dat mail met het null sender adres niet toegelaten wordt of heb ik het mis

Heeft iemand een idee hoe ik het alsnog kan blokkeren of kan dit gewoon niet

[moto-moi]

Ik denk dat je eens goed naar http://www.rfc-ignorant.org/letter-dsn-en-US.php moet gaan kijken voordat je beslist of je dit RFC brekende gedrag echt wel wilt implementeren

Er zijn zat andere manieren om spam te stoppen

[Verwijderd]

Ik krijg regelmatig spam berichten die verstuurd worden vanuit mijn Postfix server

Ik moet zeggen dat ik waarschijnlijk niet snap wat je hiermee bedoelt... Begrijp ik het nu goed en heb je een open relay server staan?? Kan iedereen zomaar mail verzenden via jou server??? dat is zowiezo niet echt handig he..... Maar misschien begrijp ik je verkeerd.

[Verwijderd]

Nou ik heb het probleem al aangepakt. Dit heb ik toegevoegd in de main.cf:

smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/sender_checks

Wat in de sender_checks staat staat in mijn eerste reactie. Wat een gekloot ben er lang mee bezig geweest een paar uur maar eindelijk heb ik mijn postfix servertje redelijk dicht gezet. Het is eigenlijk een relay voor een Exchange server voor alleen mail verkeer naar buiten

NOQUEUE: reject: RCPT from unknown[192.168.1.4]: 554 5.7.1 <>: Sender address rejected: Access denied; from=<> to=<[e-mail]> proto=ESMTP helo=<"onze mail server">

Dit soort rommel komt binnen door de Exchange server maar daar ga ik nu naar kijken naar de source van de spam

[CyBeR]

'<>' blokkeren is een slecht idee, dat zijn bounces.

[smesjz]

Verwijderd schreef op woensdag 07 november 2007 @ 15:49:
Nou ik heb het probleem al aangepakt. Dit heb ik toegevoegd in de main.cf:

smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/sender_checks

Wat in de sender_checks staat staat in mijn eerste reactie. Wat een gekloot ben er lang mee bezig geweest een paar uur maar eindelijk heb ik mijn postfix servertje redelijk dicht gezet. Het is eigenlijk een relay voor een Exchange server voor alleen mail verkeer naar buiten

NOQUEUE: reject: RCPT from unknown[192.168.1.4]: 554 5.7.1 <>: Sender address rejected: Access denied; from=<> to=<[e-mail]> proto=ESMTP helo=<"onze mail server">

Dit soort rommel komt binnen door de Exchange server maar daar ga ik nu naar kijken naar de source van de spam

Exchange stuurt bounce mails voor onbekende adressen i.p.v. ze bij de RCPT TO: al te weigeren. Dit heet dus back-scatter. Het mooiste zou zijn als jouw Postfix doos voor die Exchange machine komt te draaien en een lijst met toegestane recipients heeft (en evt. via LDAP uit de AD plukt), maar ik weet niet of je dit mogelijk kan maken.

Je moet bij de bron al die spam filteren. En dit soort bounces moet je in een goede set up al langs zien komen:
Bestaat een adres niet: weigeren na een RCPT TO.
Bevat een mail spam of een virus: afhankelijk van de policy droppen of afleveren, maar nooit bouncen.

[Creepy]

CyBeR schreef op woensdag 07 november 2007 @ 15:54:
'<>' blokkeren is een slecht idee, dat zijn bounces.

Daarnaast zijn er providers die checken met deze afzender of het reply adres bestaat en zo niet de e-mail weigeren. De null afzender weigeren is dus inderdaad niet slim.

[smesjz]

Creepy schreef op woensdag 07 november 2007 @ 16:22:
[...]

Daarnaast zijn er providers die checken met deze afzender of het reply adres bestaat en zo niet de e-mail weigeren. De null afzender weigeren is dus inderdaad niet slim.

Sender address verification in bijv. Postfix gebruikt standaard het postmaster adres en niet <>. Maar de TS lost hiermee z'n probleem natuurlijk niet op.