My Dovecot issues continue. Right now I see at least two issues: first, my logs consistently show non-users trying (and failing) to log in, and I'm still unable to log in from my email client (Evolution or Roundcube, either one).
I'll post about the second issue later; right now I wonder why I'm getting so many non-users trying to log in. Am I the subject of concerted hacking attacks, or is there something else going on? Some of the attempted logins are more-or-less random names claiming to be @mydomain, but at least one is a username that's really on my server, to wit:
Jan 7 22:52:01 grace dovecot: lmtp(776281): Error: lmtp-server: conn unix:pid=776262,uid=117 [3]: rcpt www-data@mydomain.com: Failed to lookup user www-data@mydomain.com: Internal error occurred. Refer to server log for more information.
(Another quick question: which server log should I check?)
So, if anyone can tell me what's going on with all these logins, I'd be much obliged!
Ken
On 1/7/22 11:24 PM, Ken Wright wrote:
My Dovecot issues continue. Right now I see at least two issues: first, my logs consistently show non-users trying (and failing) to log in, and I'm still unable to log in from my email client (Evolution or Roundcube, either one).
I'll post about the second issue later; right now I wonder why I'm getting so many non-users trying to log in. Am I the subject of concerted hacking attacks, or is there something else going on? Some of the attempted logins are more-or-less random names claiming to be @mydomain, but at least one is a username that's really on my server, to wit:
Jan 7 22:52:01 grace dovecot: lmtp(776281): Error: lmtp-server: conn unix:pid=776262,uid=117 [3]: rcpt www-data@mydomain.com: Failed to lookup user www-data@mydomain.com: Internal error occurred. Refer to server log for more information.
(Another quick question: which server log should I check?)
So, if anyone can tell me what's going on with all these logins, I'd be much obliged!
I see them all the time on the mail servers I run. Typical kids trying to mess with other peoples' stuff. I run fail2ban to catch those log entries and block the source IP address for a month on the first failed login. At any one time I have between 12,000 and 15,000 addresses in my blocked list for IMAP.
-Dave
-- Dave McGuire, AK4HZ New Kensington, PA
On Fri, 2022-01-07 at 23:27 -0500, Dave McGuire wrote:
On 1/7/22 11:24 PM, Ken Wright wrote:
My Dovecot issues continue. Right now I see at least two issues: first, my logs consistently show non-users trying (and failing) to log in, and I'm still unable to log in from my email client (Evolution or Roundcube, either one).
I'll post about the second issue later; right now I wonder why I'm getting so many non-users trying to log in. Am I the subject of concerted hacking attacks, or is there something else going on? Some of the attempted logins are more-or-less random names claiming to be @mydomain, but at least one is a username that's really on my server, to wit:
Jan 7 22:52:01 grace dovecot: lmtp(776281): Error: lmtp-server: conn unix:pid=776262,uid=117 [3]: rcpt www-data@mydomain.com: Failed to lookup user www-data@mydomain.com: Internal error occurred. Refer to server log for more information.
(Another quick question: which server log should I check?)
So, if anyone can tell me what's going on with all these logins, I'd be much obliged!
I see them all the time on the mail servers I run. Typical kids trying to mess with other peoples' stuff. I run fail2ban to catch those log entries and block the source IP address for a month on the first failed login. At any one time I have between 12,000 and 15,000 addresses in my blocked list for IMAP.
Dave, that's exactly the kind of answer I was looking for. Fail2ban, huh? I'll have to check that out. Thanks again!
Ken
As Dave mentioned, Fail2ban.
You'll likely want to set up graduated responses with fail2ban so the more they try, the longer it takes for them to get off the ban list.
Best
N
On 1/7/22 20:35, Ken Wright wrote:
On Fri, 2022-01-07 at 23:27 -0500, Dave McGuire wrote:
My Dovecot issues continue. Right now I see at least two issues: first, my logs consistently show non-users trying (and failing) to log in, and I'm still unable to log in from my email client (Evolution or Roundcube, either one).
I'll post about the second issue later; right now I wonder why I'm getting so many non-users trying to log in. Am I the subject of concerted hacking attacks, or is there something else going on? Some of the attempted logins are more-or-less random names claiming to be @mydomain, but at least one is a username that's really on my server, to wit:
Jan 7 22:52:01 grace dovecot: lmtp(776281): Error: lmtp-server: conn unix:pid=776262,uid=117 [3]: rcpt www-data@mydomain.com: Failed to lookup user www-data@mydomain.com: Internal error occurred. Refer to server log for more information.
(Another quick question: which server log should I check?)
So, if anyone can tell me what's going on with all these logins, I'd be much obliged! I see them all the time on the mail servers I run. Typical kids
On 1/7/22 11:24 PM, Ken Wright wrote: trying to mess with other peoples' stuff. I run fail2ban to catch those log entries and block the source IP address for a month on the first failed login. At any one time I have between 12,000 and 15,000 addresses in my blocked list for IMAP. Dave, that's exactly the kind of answer I was looking for. Fail2ban, huh? I'll have to check that out. Thanks again!
Ken
On 1/7/22 11:35 PM, Ken Wright wrote:
My Dovecot issues continue. Right now I see at least two issues: first, my logs consistently show non-users trying (and failing) to log in, and I'm still unable to log in from my email client (Evolution or Roundcube, either one).
I'll post about the second issue later; right now I wonder why I'm getting so many non-users trying to log in. Am I the subject of concerted hacking attacks, or is there something else going on? Some of the attempted logins are more-or-less random names claiming to be @mydomain, but at least one is a username that's really on my server, to wit:
Jan 7 22:52:01 grace dovecot: lmtp(776281): Error: lmtp-server: conn unix:pid=776262,uid=117 [3]: rcpt www-data@mydomain.com: Failed to lookup user www-data@mydomain.com: Internal error occurred. Refer to server log for more information.
(Another quick question: which server log should I check?)
So, if anyone can tell me what's going on with all these logins, I'd be much obliged!
I see them all the time on the mail servers I run. Typical kids trying to mess with other peoples' stuff. I run fail2ban to catch those log entries and block the source IP address for a month on the first failed login. At any one time I have between 12,000 and 15,000 addresses in my blocked list for IMAP.
Dave, that's exactly the kind of answer I was looking for. Fail2ban, huh? I'll have to check that out.
I run it under Solaris (SmartOS), but it's available on most platforms now.
Thanks again!
I'm happy to be of assistance. Good luck.
-Dave
-- Dave McGuire, AK4HZ New Kensington, PA
On Fri, 7 Jan 2022, Ken Wright wrote:
On Fri, 2022-01-07 at 23:27 -0500, Dave McGuire wrote:
On 1/7/22 11:24 PM, Ken Wright wrote:
So, if anyone can tell me what's going on with all these logins, I'd be much obliged!
I see them all the time on the mail servers I run. Typical kids trying to mess with other peoples' stuff. I run fail2ban to catch those log entries and block the source IP address for a month on the first failed login. At any one time I have between 12,000 and 15,000 addresses in my blocked list for IMAP.
Dave, that's exactly the kind of answer I was looking for. Fail2ban, huh? I'll have to check that out. Thanks again!
Yup, these SMTP AUTH BFD attempts come in thick and heavy.
Another resource to preempt these attacks is Spamhaus's XBL blacklist. At my site, there was a 99.2% hit rate and very low false positives. Even those FPs led to some useful discoveries that the client had a malware they didn't know about.
http://www.blocklist.de/en/index.html also run a DBS RBL list and I've had zero FPs after years of use. I think you can even get Fail2ban report to your attackers to this site to add to the crowdsourcing.
Joseph Tam jtam.home@gmail.com
Am 08.01.22 um 05:27 schrieb Dave McGuire:
trying to mess with other peoples' stuff. I run fail2ban to catch those log entries and block the source IP address for a month on the first failed login. At any one time I have between 12,000 and 15,000
well, I don't know how _your_ users are connected to the internet, but in germany most people has at least daily changing IPs out of larger pools (when connected via xDSL) or even sometimes shares ip-addresses with others (when connected via tv-cable or mobile - having a private network-address, which is natted), so it's possible to get/use an IP, which was used before by some script-kiddies...
so everyone, who's blocking such requests for more than some minutes/hours should be aware of maybe blocking legitimate user-logins...
btw.: setting up a new mail-client and making any mistake by reading it from old install or writing it into new install also leads to a months-blocking with above restrictive handling... (any may drive this user mad)
so anyone, who has no experience with blocking should be really careful with it.
d.
On 08/01/2022 14:26, dc-ml@dvl.werbittewas.de wrote:
Am 08.01.22 um 05:27 schrieb Dave McGuire:
trying to mess with other peoples' stuff. I run fail2ban to catch those log entries and block the source IP address for a month on the first failed login. At any one time I have between 12,000 and 15,000 well, I don't know how _your_ users are connected to the internet, but in germany most people has at least daily changing IPs out of larger pools (when connected via xDSL) or even sometimes shares ip-addresses with others (when connected via tv-cable or mobile - having a private network-address, which is natted), so it's possible to get/use an IP, which was used before by some script-kiddies...
so everyone, who's blocking such requests for more than some minutes/hours should be aware of maybe blocking legitimate user-logins...
btw.: setting up a new mail-client and making any mistake by reading it from old install or writing it into new install also leads to a months-blocking with above restrictive handling... (any may drive this user mad)
so anyone, who has no experience with blocking should be really careful with it.
d.
yes, blocking on the first wrong password sounds like overkill. But it does depend on user base. For a small mail server with few known users it could be workable.
But even on small servers I'd recommend blocking for a small time (like up to an hour) after a small number of failures (example 3). Then if this pattern repeats (for example 3 times) within a longer period (for example up to a day), blocking for a longer period (example 1 week) using the recidive jail.
Mileage will vary depending on user base and number of support requests generated.
The point about fail2ban is that it slows down attackers stopping infinite and fast repeating attacks from the same ip. That should be in combination with a good password policy which reduces the probability of any single attack guessing the password. It doesn't necessarily have to zero out attacks. As Dave has experimented, to bypass fail2ban all the attacker has to do is use a different ip. 10-15K blocks in place at any time seem very high compared to the few attacks I see.
I'd hazard a guess that the restrictive fail2ban policy is causing the attacker(s) to try immediately from a new ip and isn't generating a great deal more security than a slightly less restrictive policy which lures the attacker into trying a few times more from the same ip with longer intervals between the attempts.
John
On 1/8/22 8:57 AM, John Fawcett wrote:
yes, blocking on the first wrong password sounds like overkill. But it does depend on user base. For a small mail server with few known users it could be workable.
It may be overkill for your network, but it's not overkill for mine.
But even on small servers I'd recommend blocking for a small time (like up to an hour) after a small number of failures (example 3). Then if this pattern repeats (for example 3 times) within a longer period (for example up to a day), blocking for a longer period (example 1 week) using the recidive jail.
My mail server is a small one with about 135 users, a corporate network. NONE of them actually type their password when they're checking their mail. They type it exactly once when they set up the account in their mail client(s), like everyone else in the world for the past decade or more.
Mileage will vary depending on user base and number of support requests generated.
The point about fail2ban is that it slows down attackers stopping infinite and fast repeating attacks from the same ip. That should be in combination with a good password policy which reduces the probability of any single attack guessing the password. It doesn't necessarily have to zero out attacks. As Dave has experimented, to bypass fail2ban all the attacker has to do is use a different ip. 10-15K blocks in place at any time seem very high compared to the few attacks I see.
Sigh.
I don't "experiment" with production networks. I set up a banning policy that works for the attack patterns that I see in my logs, and that work with my user base. As I explained to the other guy who decided that how I run my network is wrong, I'm not new at this.
Any attack mitigation strategy has to begin with observation and rational thought. Network security is no place for guesswork or assumptions.
I'd hazard a guess that the restrictive fail2ban policy is causing the attacker(s) to try immediately from a new ip and isn't generating a great deal more security than a slightly less restrictive policy which lures the attacker into trying a few times more from the same ip with longer intervals between the attempts.
I wasn't asking for a critique of my configuration; I explained my approach to a new user who came here looking for help.
Which is the last time I'll do THAT on this list, by the way.
But since you brought it up, the attack pattern that I see most frequently is a single IP address trying different, obviously algorithmically-generated usernames at long intervals, many seconds to many hours, and in some cases a day or more. This started around 2014 or so, and has persisted and grown. The approach that you describe above seems to make sense on the surface, but looking at actual logs doesn't support the idea.
The "attackers" in this case are almost exclusively little programs thrown together by kids and run from zombie Windows boxes on clueless users' home networks organized as botnets. This pattern is visible when the same sequences of generated usernames start appearing from different IP addresses within hours of each other.
Some of the more advanced stuff has the adaptive behaviors that you describe, but not many. These script k1ddiez are trolling for low-hanging fruit to get bank account info etc out of peoples' mail accounts. These are almost never focused attacks from one motivated, knowledgeable person trying hard to get into one user's mail.
So, hazard all the guesses you like, I will continue to develop banning strategies for my servers which fit the attacks that I observe through direct analysis of my logs.
Now, please don't misunderstand, I actually do appreciate the thought and intention behind your unsolicited advice. But, for future reference, don't assume that someone doesn't know what they're doing just because their approach differs from either your approach for your own network, or your guesses about theirs.
-Dave, pre-coffee
-- Dave McGuire, AK4HZ New Kensington, PA
On Sat, 2022-01-08 at 11:22 -0500, Dave McGuire wrote:
I wasn't asking for a critique of my configuration; I explained my approach to a new user who came here looking for help.
Which is the last time I'll do THAT on this list, by the way.
Dave, on behalf of all the n00bs who come here seeking help, I ask you to please reconsider this. Quite simply, we (I) need all the help we can get!
Ken
On 08/01/2022 17:22, Dave McGuire wrote:
On 1/8/22 8:57 AM, John Fawcett wrote:
yes, blocking on the first wrong password sounds like overkill. But it does depend on user base. For a small mail server with few known users it could be workable.
It may be overkill for your network, but it's not overkill for mine.
But even on small servers I'd recommend blocking for a small time (like up to an hour) after a small number of failures (example 3). Then if this pattern repeats (for example 3 times) within a longer period (for example up to a day), blocking for a longer period (example 1 week) using the recidive jail.
My mail server is a small one with about 135 users, a corporate network. NONE of them actually type their password when they're checking their mail. They type it exactly once when they set up the account in their mail client(s), like everyone else in the world for the past decade or more.
Mileage will vary depending on user base and number of support requests generated.
The point about fail2ban is that it slows down attackers stopping infinite and fast repeating attacks from the same ip. That should be in combination with a good password policy which reduces the probability of any single attack guessing the password. It doesn't necessarily have to zero out attacks. As Dave has experimented, to bypass fail2ban all the attacker has to do is use a different ip. 10-15K blocks in place at any time seem very high compared to the few attacks I see.
Sigh.
I don't "experiment" with production networks. I set up a banning policy that works for the attack patterns that I see in my logs, and that work with my user base. As I explained to the other guy who decided that how I run my network is wrong, I'm not new at this.
Any attack mitigation strategy has to begin with observation and rational thought. Network security is no place for guesswork or assumptions.
I'd hazard a guess that the restrictive fail2ban policy is causing the attacker(s) to try immediately from a new ip and isn't generating a great deal more security than a slightly less restrictive policy which lures the attacker into trying a few times more from the same ip with longer intervals between the attempts.
I wasn't asking for a critique of my configuration; I explained my approach to a new user who came here looking for help.
Which is the last time I'll do THAT on this list, by the way.
But since you brought it up, the attack pattern that I see most frequently is a single IP address trying different, obviously algorithmically-generated usernames at long intervals, many seconds to many hours, and in some cases a day or more. This started around 2014 or so, and has persisted and grown. The approach that you describe above seems to make sense on the surface, but looking at actual logs doesn't support the idea.
The "attackers" in this case are almost exclusively little programs thrown together by kids and run from zombie Windows boxes on clueless users' home networks organized as botnets. This pattern is visible when the same sequences of generated usernames start appearing from different IP addresses within hours of each other.
Some of the more advanced stuff has the adaptive behaviors that you describe, but not many. These script k1ddiez are trolling for low-hanging fruit to get bank account info etc out of peoples' mail accounts. These are almost never focused attacks from one motivated, knowledgeable person trying hard to get into one user's mail.
So, hazard all the guesses you like, I will continue to develop banning strategies for my servers which fit the attacks that I observe through direct analysis of my logs.
Now, please don't misunderstand, I actually do appreciate the thought and intention behind your unsolicited advice. But, for future reference, don't assume that someone doesn't know what they're doing just because their approach differs from either your approach for your own network, or your guesses about theirs.
-Dave, pre-coffee
Dave
no one is telling you how to run your server or offering you unsolicited advice but on a public mailing list there can be multiple points of view about a topic and there may be not be a single right way to do something. There is no reason then to take this as someone telling you that how you run your network is wrong or to avoid participating in future.
John
On 1/8/22 12:12 PM, John Fawcett wrote:
On 08/01/2022 17:22, Dave McGuire wrote:
On 1/8/22 8:57 AM, John Fawcett wrote:
yes, blocking on the first wrong password sounds like overkill. But it does depend on user base. For a small mail server with few known users it could be workable.
It may be overkill for your network, but it's not overkill for mine.
But even on small servers I'd recommend blocking for a small time (like up to an hour) after a small number of failures (example 3). Then if this pattern repeats (for example 3 times) within a longer period (for example up to a day), blocking for a longer period (example 1 week) using the recidive jail.
My mail server is a small one with about 135 users, a corporate network. NONE of them actually type their password when they're checking their mail. They type it exactly once when they set up the account in their mail client(s), like everyone else in the world for the past decade or more.
Mileage will vary depending on user base and number of support requests generated.
The point about fail2ban is that it slows down attackers stopping infinite and fast repeating attacks from the same ip. That should be in combination with a good password policy which reduces the probability of any single attack guessing the password. It doesn't necessarily have to zero out attacks. As Dave has experimented, to bypass fail2ban all the attacker has to do is use a different ip. 10-15K blocks in place at any time seem very high compared to the few attacks I see.
Sigh.
I don't "experiment" with production networks. I set up a banning policy that works for the attack patterns that I see in my logs, and that work with my user base. As I explained to the other guy who decided that how I run my network is wrong, I'm not new at this.
Any attack mitigation strategy has to begin with observation and rational thought. Network security is no place for guesswork or assumptions.
I'd hazard a guess that the restrictive fail2ban policy is causing the attacker(s) to try immediately from a new ip and isn't generating a great deal more security than a slightly less restrictive policy which lures the attacker into trying a few times more from the same ip with longer intervals between the attempts.
I wasn't asking for a critique of my configuration; I explained my approach to a new user who came here looking for help.
Which is the last time I'll do THAT on this list, by the way.
But since you brought it up, the attack pattern that I see most frequently is a single IP address trying different, obviously algorithmically-generated usernames at long intervals, many seconds to many hours, and in some cases a day or more. This started around 2014 or so, and has persisted and grown. The approach that you describe above seems to make sense on the surface, but looking at actual logs doesn't support the idea.
The "attackers" in this case are almost exclusively little programs thrown together by kids and run from zombie Windows boxes on clueless users' home networks organized as botnets. This pattern is visible when the same sequences of generated usernames start appearing from different IP addresses within hours of each other.
Some of the more advanced stuff has the adaptive behaviors that you describe, but not many. These script k1ddiez are trolling for low-hanging fruit to get bank account info etc out of peoples' mail accounts. These are almost never focused attacks from one motivated, knowledgeable person trying hard to get into one user's mail.
So, hazard all the guesses you like, I will continue to develop banning strategies for my servers which fit the attacks that I observe through direct analysis of my logs.
Now, please don't misunderstand, I actually do appreciate the thought and intention behind your unsolicited advice. But, for future reference, don't assume that someone doesn't know what they're doing just because their approach differs from either your approach for your own network, or your guesses about theirs.
-Dave, pre-coffee
Dave
no one is telling you how to run your server or offering you unsolicited advice but on a public mailing list there can be multiple points of view about a topic and there may be not be a single right way to do something. There is no reason then to take this as someone telling you that how you run your network is wrong or to avoid participating in future.
Well thanks for that, but perhaps you should re-read what you sent that prompted my (admittedly rather sour) reply.
-Dave
-- Dave McGuire, AK4HZ New Kensington, PA
Am 08.01.22 um 17:22 schrieb Dave McGuire:
I wasn't asking for a critique of my configuration; I explained my approach to a new user who came here looking for help.
huh?
well, I don't think that anyone wanted to say anything about _your_ configuration, but wanted to supplement, that your configuration is maybe good for _your_ systems, but other systems may need other approaches.
especially if answering to someone, who experiences new things and asking for help, it should be normal, that someone even pick answers from others and supplement things from their own view.
this has nothing to do with blaming the author of the answer, but should show the asking person, that the answer given maybe incomplete (not wrong!) for the concrete situation, because it only shows a single view to a problem.
Which is the last time I'll do THAT on this list, by the way.
this would be bad in my opinion.
we're all doing something within our own world and if we have the possibility to look at other worlds and how people solve problems there, the knowlegde gets better and even if then someone asks us in a private situation with no additonal listeners, we can refer to solutions, which are different from our own one.
at least newbies should see: there's nearly nowhere one answer.
d.
On 1/8/22 8:26 AM, dc-ml@dvl.werbittewas.de wrote:
trying to mess with other peoples' stuff. I run fail2ban to catch those log entries and block the source IP address for a month on the first failed login. At any one time I have between 12,000 and 15,000
well, I don't know how _your_ users are connected to the internet, but in germany most people has at least daily changing IPs out of larger pools (when connected via xDSL) or even sometimes shares ip-addresses with others (when connected via tv-cable or mobile - having a private network-address, which is natted), so it's possible to get/use an IP, which was used before by some script-kiddies...
Obviously. However, my users are nearly all on static IP addresses.
btw.: setting up a new mail-client and making any mistake by reading it from old install or writing it into new install also leads to a months-blocking with above restrictive handling... (any may drive this user mad)
Again, "obviously". May mail server is not new; I was not the OP on this thread who came here looking for help.
so anyone, who has no experience with blocking should be really careful with it.
That's good advice for everything, not just blocking. My first experience with blocking was on a Cisco AGS in 1994, buddy. Not a n00b.
-Dave
-- Dave McGuire, AK4HZ New Kensington, PA
Ken, Both of my production servers see the exact same problem. What was worse I was seeing around 100K failed attempts to login to my root user. A bit of research and now my firewall ignores any attempt from PRC.
Sort of a cost of doing business
Steve Hanselman
Sent from my iPad
On Jan 7, 2022, at 20:24, Ken Wright daddywarlock@gmail.com wrote:
My Dovecot issues continue. Right now I see at least two issues: first, my logs consistently show non-users trying (and failing) to log in, and I'm still unable to log in from my email client (Evolution or Roundcube, either one).
I'll post about the second issue later; right now I wonder why I'm getting so many non-users trying to log in. Am I the subject of concerted hacking attacks, or is there something else going on? Some of the attempted logins are more-or-less random names claiming to be @mydomain, but at least one is a username that's really on my server, to wit:
Jan 7 22:52:01 grace dovecot: lmtp(776281): Error: lmtp-server: conn unix:pid=776262,uid=117 [3]: rcpt www-data@mydomain.com: Failed to lookup user www-data@mydomain.com: Internal error occurred. Refer to server log for more information.
(Another quick question: which server log should I check?)
So, if anyone can tell me what's going on with all these logins, I'd be much obliged!
Ken
On Fri, 7 Jan 2022, Ken Wright wrote:
[...]
I'll post about the second issue later; right now I wonder why I'm getting so many non-users trying to log in. Am I the subject of concerted hacking attacks, or is there something else going on? Some of the attempted logins are more-or-less random names claiming to be @mydomain, but at least one is a username that's really on my server, to wit:
Jan 7 22:52:01 grace dovecot: lmtp(776281): Error: lmtp-server: conn unix:pid=776262,uid=117 [3]: rcpt www-data@mydomain.com: Failed to lookup user www-data@mydomain.com: Internal error occurred. Refer to server log for more information.
(Another quick question: which server log should I check?)
So, if anyone can tell me what's going on with all these logins, I'd be much obliged!
Further to what others have replied, I find it odd that invalid e-mail addresses (in your case, www-data@mydomain.com) manage their way to your LMTP server (dovecot).
Normally, your MTA (postfix, I presume) should reject e-mails to invalid addresses (i.e. not existing in your system -> dovecot), so that only e-mails to existing addresses reach LMTP at all.
So you should check your postfix configuration, and in particular virtual_mailbox_maps, etc.
Cheers.
On 2022-01-09 11:11, Bernardo Reino wrote:
Further to what others have replied, I find it odd that invalid e-mail addresses (in your case, www-data@mydomain.com) manage their way to your LMTP server (dovecot).
+1
Normally, your MTA (postfix, I presume) should reject e-mails to invalid addresses (i.e. not existing in your system -> dovecot), so that only e-mails to existing addresses reach LMTP at all.
postfix will reject if its not in mynetworks
So you should check your postfix configuration, and in particular virtual_mailbox_maps, etc.
it will work if dovecot do the alias to mailbox mapping in lmtp, but this is just a dream :=)
postfix can do alias mapping before sending to dovecot lmtp, so all local alias do work aswell
hope www-data stays local system user, that is not usable from outside of postfix mynetworks
mydomain must not be a virtual domain in postfix here
mydomain should be a realm in postfix/dovecot
all the best
participants (9)
-
Benny Pedersen
-
Bernardo Reino
-
Dave McGuire
-
dc-ml@dvl.werbittewas.de
-
John Fawcett
-
Joseph Tam
-
Ken Wright
-
N
-
Stephen Hanselman