I do not. I see no point whatsoever in returning mail to someone who did not send it (1). I do not want to be part of an NDN attack (2). Nor do I want to accept badly-addressed mail in the first place! I thought SME7 was supposed to reject it by default?
It does and this explains the behaviour on your system. The wording on the panel is now inaccurate with the changes in SME7 (which has previously been raised, but has not yet been corrected). It should say "rejected" rather than "returned". And I have ensured that a bug is raised for that wording change:
http://bugs.contribs.org/show_bug.cgi?id=2291Mail for unknown users in SME7 is rejected by default during the SMTP transaction. SME6 returned the mail (qmail backscatter). This change was a specific design goal of SME7 and works as advertised and is in line with the recommendations in your links. It was one of my primary goals for the SME7 mail system changes.
However, you have asked it to not reject mail for unknown users, so you get everything addressed to local domains. That mail defaults to delivery to admin, but you could, for example, send it to a 'deadletter' user which you can check from time to time (if you like wading through spam for misdirected mail).
If you ask for recipient filtering, you get it (and that is the default). If you want everything for a domain, you can have that too (the option you have chosen).
Some people find this useful, particularly in new installs. Most people switch back to the dedault of full recipient filtering/rejection once they've checked that all looks o.k.
In Debian I just have to do an apt-get to change mail server.
And then write the configuration. Installing the new MTA is the easy part. The hard part is the configuration changes which need to be made to support all of the features of the SME Server (e.g. pseudonyms, group aliases, mailing list support addons, etc). We do a lot of qmail configuration, and would have to do a similar amount of configuration for any other MTA. Templates actually ease that work, but it still has to be done, and has to be tested.
As I stated in the threads I linked to from devinfo, most of the work has been done for Postfix support, but there are some difficult upgrade issues and a lot of testing time required. That "last 10%" is the expensive part of most development tasks.
My estimate is that there is at least two weeks fulltime for a senior developer to complete the conversion and deal with the upgrade issues. That's not a trivial amount of work, which is why we haven't done it. And I expect a number of contribs to break after the conversion.
Oh. You did not pickup on the speed issue. Sometimes the response is so slow that the next mail goes to the backup MX - which spoils the whole idea and lets anything in. This was less of a prob with 6.
Then raise it in the bug tracker so we can deal with it.
Similarly with the response messages - raise them in the bug tracker so that we can deal with them.
28 Replies
6026 Views