Madre de Dios!!!!
Eric, this is for me a superb Postfix lesson. Now I am at home trying to print this out, then tomorrow back in the office with this, i'll put in practice the advices here *very well* explained. Maybe tomorrow I can trim to an upper level my IMGate, and maybe post for some other question; for now it's great. Thanks again, and regards Andres ---------- Original Message ---------------------------------- From: "Cybertime Hostmaster" <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] Date: Tue, 3 Dec 2002 15:12:36 -0800 > >> postconf -n >> disable_vrfy_command =3D yes > >Why? There are many ways around that check. > >Here are my notes on VRFY from the discussion that went on about it in the >Postfix list: > ># VRFY - To Disable or Not? ># One of the widely contested commands is VRFY. ># ># The reason is simple. VRFY or Verify allows the remote host to test an ># address to see if it is valid. ># ># According to the anti-SPAM community, the VRFY command is used to harvest ># addresses. According to others, the VRFY command is required by the ># RFCs. ># ># Backing up the second point of view is the fact that there are other ways ># to harvest addresses. All you have to do is send mail and look for ># bounces. That is just one other way, and it is not the end of the chain. ># ># In fact, most spammers don't seem to care if the addresses they send to ># are valid or not. I have addresses that have been dead for over a year, ># or never even existed, that get spam almost every day! ># ># Postfix allows for a compromise. ># ># The smtpd_junk_command_limit is defined as "Limit the number of times a ># client can issue a junk command such as NOOP, VRFY, ETRN or RSET in one ># SMTP session before it is penalized with tarpit delays." ># ># This allows you to put in a trap for connections that simply VRFY ># constantly, but still have the command turned on and be RFC compliant. ># ># Setting it no higher than 10, and no lower than 2 should be safe. ># I use 5. > >disable_vrfy_command =3D no >smtpd_junk_command_limit =3D 5 > > >> delay_notice_recipient =3D [EMAIL PROTECTED] >> double_bounce_sender =3D double-bounce >> error_notice_recipient =3D [EMAIL PROTECTED] >> notify_classes =3D resource, software, >bounce, >> 2bounce, delay, policy, >> protocol > >Are you intending to spam yourself? > >If you get tired of seeing all the bounce and error messages you can trim >this down. > >This is mine: > >#notify_classes =3D resource, software, bounce, delay, policy, protocol >notify_classes =3D resource, software > >I leave the commented full one in there so I can see what the options are if >I ever want to turn them back on. > >Basically don't care to be emailed every time an email is zapped. > >I have a log analyzer for keeping track of this sort of thing. > >> mydestination =3D imgate.cotel.com.ar >> mydomain =3D cotel.com.ar >> myhostname =3D imgate.cotel.com.ar >> mynetworks =3D 200.16.193.0/24, 200.41.176.0/24, >> 200.43.255.0/24, 192.168.0.0/24 >> myorigin =3D $myhostname >> queue_directory =3D /var/spool/postfix >> relay_domains =3D $mynetworks, hash:/etc/postfix/relay_domains.map >> smtpd_banner =3D $myhostname - ESMTP - $mail_name - ATTN: UCE trespassers >> will be pursued. > >> smtpd_client_restrictions =3D permit_mynetworks, >> hash:/etc/postfix/access_ok.map, >> hash:/etc/postfix/myspamlist.map, >> hash:/etc/postfix/spamlist.map, >> check_sender_access hash:/etc/postfix/no_send.map, >> reject_non_fqdn_sender, >> reject_non_fqdn_recipient, >> reject_unknown_sender_domain, >> reject_unknown_recipient_domain, >> check_sender_access hash:/etc/postfix/maps_ok.map, >> reject_maps_rbl, reject_unauth_pipelining > >> smtpd_recipient_restrictions =3D permit_mynetworks, >> hash:/etc/postfix/unkn_users.map, >> check_relay_domains > >## NOTE None of the next set of comments is anything critical: > >Bit redundant to have permit_mynetworks under smtpd_recipient_restrictions >if you already have it under smtpd_client_restrictions. This is because a >blank smtpd_*_restrictions is the same as permit. > >All smtpd_*_restrictions must be passed or the mail is rejected. > >With the reject delay on, which is the default (so it does not show up in >postconf -n), all checks are done after the recpt to stage. > >So basically you are waiting till the recpt to, then doing permit_mynetworks >twice, which is inefficient unless you have a reason for using two maps. > >As far as I can tell, you have no reason fro using two maps. > >In your smtpd_recipient_restrictions all you are doing is rejecting old dead >users, and killing relays. > >As a matter of pure efficiency, you might want to use >reject_unauth_destination under permit_mynetworks in your >smtpd_client_restrictions, then you can remove both permit_mynetworks and >check_relay_domains from your smtpd_recipient_restrictions. > >A reordering could also squeeze out a tad more from your checks. Here is an >example. > >reject_non_fqdn_sender, reject_non_fqdn_recipient, and >reject_unauth_pipelining are all conditional checks. As in they check the >condition of the incoming mail structure. > >These sort of checks do no lookups, and therefore take the least resources. > >It is best to do your low resource checks FIRST. This kills a small >percentage of the mail for no real effort. That small percentage then saves >you resources on ever other test. > >I also do those three BEFORE permit_mynetworks because I do not want any >broken outbound mail. > >You are doing anti-relay checks separate from other checks. It works. All >of that above is only an issue if you need to squeeze a little more out of >your machine. > >If what you are doing now causes you no problems there is NO REAL NEED to >change anything! > >## END OF NOTED AREA > >> strict_rfc821_envelopes =3D yes >> transport_maps =3D hash:/etc/postfix/transport.map >> # > >As far as I can see, there is nothing that would let others use your IMGATE >server inappropriately. > >imgate01# host cotel.com.ar >cotel.com.ar mail is handled (pri=3D10) by imgate.cotel.com.ar >cotel.com.ar mail is handled (pri=3D5) by fobos.cotel.com.ar >cotel.com.ar mail is handled (pri=3D20) by mail.cotel.com.ar > >I am not sure about the other two servers. > >I bet you get a lot of direct to MX spam on the others. > >> My logs are VEEERRRRYYYYYYYYY large, any filter to add? The IP shows >> nothing. > >Things to grep for based off those headers: > >uki0094 >hughes.net >200.183.82.9 >200.204.140.10 > >Any of those should get you some nice long log lines. > >For example, here is a small bit from looking for this mailing list: > >imgate01# grep -i .meiway.com /var/log/maillog >Dec 3 07:32:44 imgate01 postfix/smtpd[9702]: connect from >ns2.meiway.com[212.73.210.72] >Dec 3 07:32:44 imgate01 postfix/smtpd[9702]: 891182587B: >client=3Dns2.meiway.com[212.73.210.72] >Dec 3 07:32:46 imgate01 postfix/qmgr[145]: 891182587B: >from=3D<[EMAIL PROTECTED]>, size=3D4428, nrcpt=3D1 (queue active) >Dec 3 07:32:46 imgate01 postfix/smtpd[9702]: disconnect from >ns2.meiway.com[212.73.210.72] >Dec 3 07:42:34 imgate01 postfix/smtpd[9703]: connect from >ns2.meiway.com[212.73.210.72] > >In all that, there is one very important piece of information for tracking >the events related to the message I was sent, 891182587B. > >>From the ID I can get the next part: > >imgate01# grep -i 891182587B /var/log/maillog >Dec 3 07:32:44 imgate01 postfix/smtpd[9702]: 891182587B: >client=3Dns2.meiway.com[212.73.210.72] >Dec 3 07:32:45 imgate01 postfix/cleanup[9715]: 891182587B: >message-id=3D<[EMAIL PROTECTED]> >Dec 3 07:32:46 imgate01 postfix/qmgr[145]: 891182587B: >from=3D<[EMAIL PROTECTED]>, size=3D4428, nrcpt=3D1 (queue active) >Dec 3 07:32:46 imgate01 postfix/smtp[9659]: 891182587B: >to=3D<[EMAIL PROTECTED]>, relay=3D216.117.209.200 [216.117.209.200], >delay=3D2, status=3Dsent (250 Message queued) > >You could grep for [EMAIL PROTECTED] and see when I tested your >anti-relay settings. Then grep for the queue ID. That way you can use my >one attempt for a sample to looking at greeping the way I just showed. > >> Also my mailq is too large, compared to days ago. > >Probably tons of fake bounces. > >Two solutions: > Trim your queue holding time. > Use a script to zap the ones related to the domain causing them. > >I don't remember the script off hand, but I bet you could google it up from >the postfix archives. Use postsuper, script and delete as keywords. > >Now I need to enter some domains. The joys of admin. > >--Eric > > > > __________________________________________________________________ Piense en Gesell todo el A=F1o... http://www.cotel.com.ar
