Hi Mike,
As a side note, SecurityFocus has a great Postfix/UCE article at
http://www.securityfocus.com/infocus/1593.
> -----Original Message-----
> From: Mike Vanecek
> OK. Your thought is if none of the rejects hit, then it
> defaults to permit?
>
> My approach says that if it is part of the LAN, then do not
> do the other tests? I.e., mynetworks = 192.168.1.0/24, 127.0.0.0/8.
I can appreciate that. My config is a gateway in front of internal mail
servers. Thus, I would never expect my internal LAN host, which is the
primary mail store, to send a helo greeting in a non-FQDN format. However,
every Win32 MUA never greets in FQDN format. The OS only understands the
NetBIOS name and not the DNS name. I believe this is still true for AD
clients. So in short, a gateway config is different from an internal relay.
> > # These rejects should be permanent, not soft.
> > unknown_address_reject_code = 554
> > unknown_client_reject_code = 554
> > unknown_hostname_reject_code = 554
>
> I do not know the difference between the default 450 reject
> and the 554 reject.
4xx error codes tell the client to retry later. 5xx error codes mean the
error is fatal. Ex:
554 Transaction failed
(This is the default for messages using Postfix' REJECT syntax.)
550 Requested action not taken: mailbox unavailable.
(Good for sending permanent errors.)
450 Requested mail action not taken: mailbox unavailable.
(Good for sending temporary errors.)
> > # Don't wait for RCPT TO: to reject message.
> > smtpd_delay_reject = no
>
> # You may also list any helo, sender or recipient restrictions here.
> # These will have effect only when smtpd_delay_reject=yes, so that all
> # restrictions are evaluated at the time of the RCPT TO command.
>
> This one confuses me. The doco says the restrictions have
> effect only when
> smtpd_delay_reject=yes, yet you set it to no?
No . . . that is not what it says. It says that all the restrictions, which
are order dependent, take place during the RCPT TO command when
smtpd_delay_reject=yes, which is the default. Therefore, in your
configuration you should only have smtpd_recipient_restriction and have
everything there. Ex:
smtpd_recipient_restrictions = permit_mynetworks,
reject_rbl_client dnsbl.njabl.org,
reject_rbl_client relays.osirusoft.com,
reject_rbl_client bl.spamcop.net,
reject_rbl_client list.dsbl.org,
reject_unknown_client,
reject_invalid_hostname,
reject_unknown_hostname
This is why I indicate that your second permit_mynetworks, in the
smtpd_helo_restrictions, is redundant. Postfix will never reach it as all
the restrictions will be tested sequentially during the RCPT TO command.
The documentation then indicates that in order to have the restriction take
effect as soon as possible, specify smtpd_delay_reject=no. In my config,
the client restrictions reject during IP connect, the helo restrictions
reject during the helo greeting, etc. That is why I broke it out into the
respective smtpd_*_restrictions. I don't understand why I should let the
sending client reach the RCPT TO command to reject based on an IP address.
> > check_client_access hash:/etc/postfix/access_client,
> > check_helo_access hash:/etc/postfix/access_helo,
> > check_sender_access hash:/etc/postfix/access_sender,
> > check_recipient_access hash:/etc/postfix/access_recipient,
>
> Do you use all of these access files? I assume you use
> postmap to hash them?
Yes. Primarily because I created a Webmin module to handle all of this
including Procmail, log display, quarantine, etc. Breaking out the
restrictions into separate files is much easier from an administrative/GUI
perspective. I do use hash as it is faster and I have not had enough use
for regex/pcre to justify using it. So my Webmin module has not really
supported more although I would like to be more flexible in this area. In
short, hash works best for the config.
> These smptd restrictions have cut down significantly the
> amount of spam that spamassassin must process.
I have a 25%-30% reject rate at the SMTP phase. I think that is
significant. Again, I do not like Postfix using the blackhole lists. I
very much prefer SA assuming that responsibility.
--Larry
-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0
_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
