On Wed, Aug 22, 2012 at 06:45:17PM +0300, David Anderson wrote:
There are no incoming mail accounts for those users. The server in question is a webserver. Every website has a unique UNIX user, for security when running scripts. You can't virtualise that. If you run all your scripts under the same UNIX user on a shared server, then it's less secure.
Sieve was complaining about the envelope *sender* address being invalid, on a piece of outgoing mail (generated by the website). It wasn't about incoming mail or maintaining accounts.
I guess what an RFC says about "email address syntax" is valid rule for both sender _and_ recipient. Mails are usually filtered to check they are valid, for example a *sender* what you mentioned as an example would not be able to send mails to our ISP since syntax of sender address are checked on the MX MTAs as well. So I don't see too much point to send mails with invalid (by RFC) sender as most mail softwares and/or MTA admin's configuration will reject it, like with your example, check the subject out of your mail. I guess it's a valid decision to reject these.
But _again_: I can be wrong here.
That's a bit academic, though. It think the main points are that:
- Many Unixes allow you to set up usernames ending in periods
- The MTAs also allow you to send and receive mail using those periods
Strictly according to the RFC, the address is invalid. But if the MTA accepts it, why should sieve reject it? Sieve is deployed to
Which MTA? Our ISP would reject those, for example. It's matter of the kind of the MTA, and also its configuration, but since according to the RFC which says that invalid, it's not so suprising that some people and/or mail related software decide not to accept. For sure, there can be softwares/configs which allows it. It clearly shows that it's better to avoid addresses which are often handled as invalid ("but not always", it depends, yes), especially if "standards" says they are invalid as well.
apply filters to mail - not to make policy decisions on valid email addresses. That's a layering violation.
Well, it's bit out of scope my intent, also I am not instered to start a flame war or so :) I just wanted to point out that it's anyway a very bad idea to use invalid addresses even if it can be said as true that sieve should not reject things if it's MTA's job ... The basic idea is the same: why do you want to use them, if there are problems with these anyway, and sooner or later you will hit a rejection, even if sieve is "fixed" not having this decision as well. Creating a system which use known to be invalid things (even if it works locally, or other similar examples) are a "good" sign to introduce "interesting" and hard-to-track-down problems later, maybe in the more far future only.
I can't say anything about sieve itself, to be honest, anyway, and your suggestion that it must be fixed or not.
Again, sorry if someone treated my mail as OT/flame/whatever.