The Saturday 2004-11-27 at 20:23 -0500, Patrick Shanahan wrote:
* Carlos E. R.
[11-27-04 20:11]: I believe reject_unknown_sender_domain shouldn't do a reverse check, but a direct one. For example, if I send as "noname@doesnotexist.com", postfix should do a query, like the command "host doesnotexist.com". If it comes out as non existing, the domain was invented, not real. I think dyndns should work, because the name should resolve.
I have no-ip.org which is similar to dyndns and employe reject_unknown_sender_domain and do not *seem* to have any problem with any mail. I look at the logs every morning and see nothing amiss.
Yes, when suse's default MTA was sendmail, it came with the equivalent option enabled, and it worked. I wonder why they disabled it in postfix. My only worry is that it will slow my download, I use a modem and here we pay by the minute: local calls are not free as I think most of N.A. uses. That's why I'm trying with 'reject_non_fqdn_sender' first.
I sometimes get 300-400 rejects for unknown_sender_domain and for "User unknown in local recipient table".
It's just that much more that SpamAssassin does not have to filter/reject.
I'll have to consider it.
I have also noticed that /etc/postfix/access does not seem to perform as expected, but header_checks *does*.
The access check is enabled with: smtpd_sender_restrictions = hash:/etc/postfix/access And, according to postfix documentation: Sender address restrictions The smtpd_sender_restrictions parameter restricts what sender addresses this system accepts in MAIL FROM commands. I understand that means that it checks "access" against the envelope from, and not the internal from: that's why it doesn't work for me in the mixmail case. The problem with header_checks (I know it would work) is that it acts too late, when using fetchmail. The whole email gets downloaded and then fetchmail generates a bounce message. Mmm, I wonder now... oh, well, another day. -- Cheers, Carlos Robinson