hello!
a problémám, hogy az utóbbi pár napban másodpercenként 5-10 konnektet kapok különböző japán ipkről, nagyjából ez a szitu:
Jul 2 14:27:43 mailserver postfix/smtpd[41038]: connect from mta128.mail.tnz.yahoo.co.jp[203.216.244.135]
Jul 2 14:27:44 mailserver postfix/cleanup[40987]: 2D35A6D483: message-id=<20070702122744.2D35A6D483@en.szerverem.hu>
Jul 2 14:27:44 mailserver postfix/qmgr[40984]: 2D35A6D483: from=
, size=254, nrcpt=1 (queue active)
Jul 2 14:27:44 mailserver postfix/virtual[40989]: 2D35A6D483: to=, relay=virtual, delay=0.01, delays=0/0/0/0, dsn=5.1.1, status=undeliverable (unknown user: "syonben@endomenem.hu")
Jul 2 14:27:44 mailserver postfix/qmgr[40984]: 2D35A6D483: removed
nemtom hogy küzdjem le őket...
próbáltam ezt:
http://www.postfix.org/BACKSCATTER_README.html
nemnagyon jött össze, nemcsinál vele semmit..
guglin sem találtam érdemlegeset, csak pár oldalt, ami kb ugyanide linkel..
ha valaki már átesett ezen megköszönöm a segítségét!
- 2551 megtekintés
Hozzászólások
Nem vagy egyedül vele. Úgy tűnik, hogy most valami járvány van. A napi mail forgalmunk fele jelenleg backscatter. Éppen most tesztelek egy Barracuda-t amiből ez marha jól látszik. Szerencsére az még azelőtt blokkolja őket, mielőtt eljutnának a mail szerverünkhöz.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
"sender id" (vagy mi) nem segítene a dolgon? Ha a címzett látná, hogy nem egy felhatalmazott email szerver próbál levelet küldeni, akkor nem küldene válaszlevelet.
- A hozzászóláshoz be kell jelentkezni
nekem a 95% backscatter és végülis nem okoz kárt (feljebb kellett venni az smtp processzek számát 5->50), hiszen nem létező mail címekkel szenved, de akkoris zavaró, főleg, hogy nemtom szűrni sehogysem
- A hozzászóláshoz be kell jelentkezni
postgrey + rbl ?
- A hozzászóláshoz be kell jelentkezni
postgrey nekem sosem volt túl szimpi
rbl-el meg az a baj, hogy sok ISP mailservere is rákerül időnként, az meg kellemetlen, ha emiatt nem kap meg egy felhasználó egy fontos levelet
- A hozzászóláshoz be kell jelentkezni
Amíg nem valódi E-mail címre jön a backscatter, addig még elmegy (csak pl. bírja a log partíciód).
Majd ha valódira jön, az a keményebb dió. Általában nincs értelme ezért E-mail címet cseréltetni a felhasználóval. Inkább érdemes a backscatter lecsengéséig (2-4 hét) kiszűrni a levelei közül a null sender címrő jövő leveleket a fejébe verve, hogy ezalatt az idő alatt viszont különösen ügyeljen arra, hogy ne írja le a címzettek címeit a levelezésében.
- A hozzászóláshoz be kell jelentkezni
Ne irja el akart lenni, természetesen...
- A hozzászóláshoz be kell jelentkezni
nullsendert hogy szűrjek?
- A hozzászóláshoz be kell jelentkezni
Az smtpd_null_access_lookup_key tartalmazza a stringet (default <>), amit a Postfix null sender esetén keresőkulcsként használ. Beteszed a megfelelő táblába, és kész. Az "értéke" lehet akár egy class, amivel a címzetteket nézed meg, hogy kik számára dobod el a bounce leveleket. Példa:
/etc/postfix/null-sender-lookup:
<> filter_bounce
/etc/postfix/filter-bounce:
foo@user.hu REJECT Backscatter rejected.
bar@user.hu REJECT Backscatter rejected.
/etc/postfix/main.cf:
smtpd_restriction_classes = ... filter_bounce
smtpd_recipient_restrictions = ...
check_sender_access hash:/etc/postfix/null-sender-lookup
Mivel backscatter esetében a bounce küldője maga is áldozat, ezért érdemesebb az /etc/postfix/filter-bounce file-ban REJECT helyett DISCARD-ot használni.
- A hozzászóláshoz be kell jelentkezni
megcsináltam, ahogy írtad:
root# cat filter_bounce
user@endomenem.hu DISCARD Backscatter rejected.
root# cat null-sender-lookup
<> filter_bounce
root# postmap null-sender-lookup
main.cf-be beírtam:
check_sender_access
hash:/usr/local/etc/postfix/null-sender-lookup,
smtpd_restriction_classes = filter_bounce
filter_bounce = check_recipient_access hash:/usr/local/etc/postfix/null-sender-lookup, permit
az eredmény, hogy minden ugyanúgy megy, ahogy eddig: user@endomenem.hu-t ugyanúgy engedi, csak a címzett szar és ott ad neki "unknown user"-t
hol baszom el? :)
- A hozzászóláshoz be kell jelentkezni
Mindkét file-ra (filter_bounce-ra is) kell a "postmap" parancs.
Van bármi hibaüzenet a mail logban?
Mi van pontosan az smtpd_helo|client|sender|recipient_restrictions beállításoknál?
Teszteled valahonnan?
- A hozzászóláshoz be kell jelentkezni
mindkettőre nyomtam postmapot, hibaüzi nincs
tesztelni úgy tesztelem, hogy másodpercenként van úgy 5-10 backscatter
konfigok pedig:
smtpd_helo_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
reject_invalid_hostname,
permit
smtpd_sender_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
reject_unknown_sender_domain,
permit
smtpd_client_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
reject_unknown_sender_domain,
reject_unauth_destination
smtpd_recipient_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
reject_invalid_hostname,
reject_unauth_pipelining,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_unverified_recipient,
reject_unauth_destination,
check_sender_access
hash:/usr/local/etc/postfix/null-sender-lookup,
permit
- A hozzászóláshoz be kell jelentkezni
Ugye az smtpd_delay_reject a default 'yes' értéken van?
Mert akkor a következő történik:
kliens kapcsolódik: nincs ellenőrzés
HELO/EHLO-t mond: nincs ellenőrzés
MAIL FROM-ot mond: nincs ellenőrzés
RCPT TO-t mond: ha az smtpd_client|helo|sender_restrictions bármelyike (ebben a sorrendben) explicit beengedi vagy tiltja a levelet, akkor az az eredmény. Ha mindegyik DUNNO-t ad, akkor és csak akkor lefutnak az smtpd_recipient_restrictions ellenőrzései.
Ha smtpd_delay_reject = yes, akkor jelen pillanatban a sender és recipient szűréseid mintha ott sem lennének.
- A hozzászóláshoz be kell jelentkezni
igazad volt, yes-re volt állítva, de átállítottam no-ra és semmi nem változott, ezt kapom továbbra is:
Jul 3 10:26:07 mailserver postfix/smtpd[58624]: connect from rungw388.ritsumei.ac.jp[133.19.126.188]
Jul 3 10:26:08 mailserver postfix/cleanup[58645]: 3C71E6D401: message-id=<20070703082608.3C71E6D401@enszerverem.hu>
Jul 3 10:26:08 mailserver postfix/qmgr[58580]: 3C71E6D401: from=
, size=254, nrcpt=1 (queue active)
Jul 3 10:26:08 mailserver postfix/virtual[58646]: 3C71E6D401: to=<0520t@endomenem.hu>, relay=virtual, delay=0.02, delays=0.01/0.01/0/0.01, dsn=5.1.1, status=undeliverable (unknown user: "0520t@endomenem.hu")
Jul 3 10:26:08 mailserver postfix/qmgr[58580]: 3C71E6D401: removed
Jul 3 10:26:11 mailserver postfix/smtpd[58624]: NOQUEUE: reject: RCPT from rungw388.ritsumei.ac.jp[133.19.126.188]: 550 5.1.1 <0520t@endomenem.hu>: Recipient address rejected: undeliverable address: unknown user: "0520t@endomenem.hu"; from=<> to=<0520t@endomenem.hu> proto=ESMTP helo=
Jul 3 10:26:11 mailserver postfix/smtpd[58624]: disconnect from rungw388.ritsumei.ac.jp[133.19.126.188]
- A hozzászóláshoz be kell jelentkezni
Gondolom, "postfix reload" volt.
A reject_unverified_recipient-et az smtpd_recipient_restrictions-ban az utolsó permit elé tenném, szerintem az kapja el az ismeretlen címzetteket. (Felteszem, a
0520t@endomenem.hu
szerepel a filter_bounce file-ban.)
Tulajdonképpen miért használsz smtpd_client|helo|sender_restrictions beállításokat? Miért nem hagyod azokat üresen?
- A hozzászóláshoz be kell jelentkezni
a postmaster@endomenem.hu van a filter_bounce-ban, az a célom, hogyha vki nullsenderről, vagy postmaster@endomenem.hu-ról küld mailt, akkor azt rejectelje
- A hozzászóláshoz be kell jelentkezni
Ha csak a
postmaster@endomenem.hu
szerepel a filter_bounce file-ban, akkor miért csodálkozol, hogy a
0520t@endomenem.hu
stb számára kézbesítődni akar a bounce levél?
Ha a
postmaster@endomenem.hu
címről jövő levelekre is szűrni akarsz (Te tudod), akkor értelemszerűen tedd be a címet a megfelelő táblába.
- A hozzászóláshoz be kell jelentkezni
subscribe
- A hozzászóláshoz be kell jelentkezni
??
- A hozzászóláshoz be kell jelentkezni
Mivel semmi egyéb módja nincs a téma figyelésének, egy kommenttel feliratkoztam rá (subscribe = feliratkozni). Így megjelenik a saját friss tartalmaim közt
- A hozzászóláshoz be kell jelentkezni