Latest main.cf changes

[rbtux]

Hi there

I saw the latest main.cf changes:

Quote:smtpd_sender_restrictions = permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
reject_unauth_pipelining,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
check_policy_service inet:127.0.0.1:60000,
check_policy_service inet:127.0.0.1:12525

You can skip the sender_restrictions. They are not necessary.

The recipient restriction is not optimal. At least:
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,

should match before permit_mynetworks and permit_sasl_authenticated...

[BeNe]

You mean http://www.isp-control.net/ispcp/changeset/896 ??
So please reopen the Ticket and post your better solution.
Thanks!

Greez BeNe

[rbtux]

done

http://www.isp-control.net/ispcp/ticket/825#comment:2


PS: my 333 post ^^

[Zothos]

hm, why do we need postgrey and! policyd-weight? Im using just policyd on my own box. And ist runnig fine. Lesser spam as with postgrey

And a little idea, why dont add some random honeypots to each ispcp installation. Which will pollute our own dns black list

[rbtux]

Zothos Wrote:hm, why do we need postgrey and! policyd-weight? Im using just policyd on my own box. And ist runnig fine. Lesser spam as with postgrey

i use a combination of both...

policyd-weight on each connection and postgrey selective for known dialin ranges (or rdns entry which looks like dynamic...)

But i don't think that the majority of the users here were capable of monitoring and administer such a solution. So the main aim should be make ispcp as spamresistant as possible out of the box WITHOUT any special knowledge needed for the admins... Thats my humble opinion...

[raphael]

Quote:You can skip the sender_restrictions. They are not necessary.

they were already there; and I don't think people want anybody to use their server for sending emails

[rbtux]

the sender_restrictions has nothing to do with especially sending e-mails... the sender_restrictions restrict mails using information available after the mail from: command while recipient_restictions restrict mails based on information available after rhe rcpt: command

so within recipient restriction you can do all restrictions necessary. This is important when you add some black/whitelists. When you permit something within sender_restrictions you can't block that in the recipient_restrictions...

[bodysplit]

rbtux Wrote:so within recipient restriction you can do all restrictions necessary. This is important when you add some black/whitelists. When you permit something within sender_restrictions you can't block that in the recipient_restrictions...

I also have set only recipient restrictions, but I came to think about it after your post.

Wouldn't it speed up the mail processing if we knock out Spammers early? Wouldn't it be could to error out everyone we can, if we can, with the info we already have?

I'm just curious. I have the HELO/EHLO and the MAIL FROM. I don't need to know who the mail is for to kick out wrong HELOs or non-RFC sender-addresses.

The only point I can think of is the postmaster, who should always get mail. But on the other hand, even for a postmaster, at least the sender could check HELO and a RFC-formatted sender address.

Realy, I'm just wondering.

[rbtux]

your point is not wrong...

But thats a few bytes per mail you have to get additionally...

The main advantage of this configuration comes in play when you add some additional maps (bogus_mx / white and blacklistings for sender/recipient/clients...) you can specify them at one point in the configuration and you don't have to worry about previous permits/blocks...

I personally like as much information possible in my log files...

[bodysplit]

Thanks rbtux, I understand that now.

I just hope, sometimes in the near future I can beat up GMX and Webmail or Google/Yahoo. Then, the mail-system would realy need to perform best.

Okay, I readjust my plans on taking over the world...