Re: Strange issue with reject_unverified_recipient (LMTP/Dovecot)

[A. Schulze]

Am 14.10.2017 um 23:23 schrieb Jozef Matický:
> Hello,
> 
> I've been struggling with this for about a week now.
> In smtpd_recipient_restrictions I have reject_unverified_recipient.
> For recipient address verification I'm using Dovecot's LMTP.
> Everything is working as expected when address_verify_negative_cache = yes - 
> unknown recipients are rejected with 550 (NOQUEUE: reject), for known the 
> mail is delivered.
> 
> The problem I have is when I set address_verify_negative_cache = no.
> It goes like this:
> 
> - Sender connects to Postfix
> + Postfix is checking address with Dovecot
> + Dovecot responds (almost instantly) with 550 5.1.1 User doesn't exist; 
> status=undeliverable-but-not-cached
> - Above + points are repeated as many as address_verify_poll_count times (in 
> my case 5 times, with default it happened 3 times)
> - Postfix then replies to sender with 450 Recipient address rejected: 
> unverified address: Address verification in progress.
> - After a while sender is trying to deliver the same e-mail again and the 
> same thing is happening - it is deffered with 450
> - This goes on and on and on
> 
> It looks like when there is status=undeliverable-but-not-cached Postfix is 
> trying to verify the recipient address address_verify_poll_count times and 
> doesn't understand the Dovecot's 550 reply 
> (status=undeliverable-but-not-cached), after which it should reject sender 
> with 550 (NOQUEUE: reject).
> 
> Am I doing something wrong or is this some kind of a bug?
> The reason I'm trying to turn off negative cache is due to the catch-all.
> For example, user is trying to send an email to mailbox that doesn't exist. 
> The e-mail will be rejected with 550.
> Then user creates a catch-all for the domain and will send e-mail to the same 
> address.
> Due to the negative cache it again will be rejected with 550 despite the fact 
> there now is catch-all configured.
> 
> This is with Postfix 3.2.3 which I just upgraded from 3.1.6 (on which it was 
> exactly the same). I also have unverified_recipient_reject_code = 550 set.
> If something else is needed, like logs or postconf, please let me know.
> Don't want to spam mailing list if this is a problem between the chair and 
> the keyboard.

Josef,

Could you explain why you completely disable address_verify_negative_cache?
I personally would only shorten address_verify_negative_refresh_time if caching 
would be an issue.

Andreas
> 
> Thank you.

Re: Strange issue with reject_unverified_recipient (LMTP/Dovecot)

[Jozef Matický]

Hello Andreas,

Had some users complaining about mailboxes (and catch-alls) they created 
were not accepting e-mails - Postfix, due to caching, was rejecting the 
e-mail as if the mailbox wouldn't exist (apparently due to a fact 
someone was trying to send an e-mail to that mailbox before it even 
existed - maybe spammer, maybe a legit user).


The below statement I'm not 100% sure about as I was playing with 
multiple config options, will have to check this again, however:
I believe I also played with negative_refresh_time (setting it to 1s), 
however I think what was happening was that e-mail was 450 deferred 
(address ver. in prog.) for the first time the sender connected and 
tried to deliver to already neg. cached address. Only afterwards the 
cache was refreshed - causing the e-mail to defer with 450 once.
This would have caused delays in delivery (or lost e-mails with bad 
implementations) and more complaints from users saying there is a 
problem with e-mails.


Anyways, I really believe there is a bug with 
address_verify_negative_cache = no implementation.


Thank you.

Best regards,
Jozef.


On 15. 10. 2017 12:50, A. Schulze wrote:



Am 14.10.2017 um 23:23 schrieb Jozef Matický:

Hello,

I've been struggling with this for about a week now.
In smtpd_recipient_restrictions I have reject_unverified_recipient.
For recipient address verification I'm using Dovecot's LMTP.
Everything is working as expected when address_verify_negative_cache = yes - 
unknown recipients are rejected with 550 (NOQUEUE: reject), for known the mail 
is delivered.

The problem I have is when I set address_verify_negative_cache = no.
It goes like this:

- Sender connects to Postfix
+ Postfix is checking address with Dovecot
+ Dovecot responds (almost instantly) with 550 5.1.1 User doesn't exist; 
status=undeliverable-but-not-cached
- Above + points are repeated as many as address_verify_poll_count times (in my 
case 5 times, with default it happened 3 times)
- Postfix then replies to sender with 450 Recipient address rejected: 
unverified address: Address verification in progress.
- After a while sender is trying to deliver the same e-mail again and the same 
thing is happening - it is deffered with 450
- This goes on and on and on

It looks like when there is status=undeliverable-but-not-cached Postfix is 
trying to verify the recipient address address_verify_poll_count times and 
doesn't understand the Dovecot's 550 reply 
(status=undeliverable-but-not-cached), after which it should reject sender with 
550 (NOQUEUE: reject).

Am I doing something wrong or is this some kind of a bug?
The reason I'm trying to turn off negative cache is due to the catch-all.
For example, user is trying to send an email to mailbox that doesn't exist. The 
e-mail will be rejected with 550.
Then user creates a catch-all for the domain and will send e-mail to the same 
address.
Due to the negative cache it again will be rejected with 550 despite the fact 
there now is catch-all configured.

This is with Postfix 3.2.3 which I just upgraded from 3.1.6 (on which it was 
exactly the same). I also have unverified_recipient_reject_code = 550 set.
If something else is needed, like logs or postconf, please let me know.
Don't want to spam mailing list if this is a problem between the chair and the 
keyboard.


Josef,

Could you explain why you completely disable address_verify_negative_cache?
I personally would only shorten address_verify_negative_refresh_time if caching 
would be an issue.

Andreas


Thank you.

Re: Strange issue with reject_unverified_recipient (LMTP/Dovecot)

[Wietse Venema]

A. Schulze:
> > The problem I have is when I set address_verify_negative_cache = no.
...
> > It looks like when there is status=undeliverable-but-not-cached 

There is no such reply. In reality, the reply is that the address
probe is in progress (DEL_RCPT_STAT_TODO).

This is what happens:

1. SMTP daemon queries verify service for an address probe result.
2. There is no address probe result. This triggers a verify probe.
3. Repeat 1 until the addres probe poll count is reached.

I don't see how one would avoid this, other than by blocking the
SMTP daemon's query while a probe is in progress or until a time
limit is reached.

If you want to create accounts on the fly, don't break address
verification. 

Instead, change your local_recipient_maps, virtual_alias_maps,
relay_recipient_maps or virtual_mailbox_maps. At the end of those
maps, a tcp_table or socketmap service that handles the queries for
non-existent addresses. This service replies with 5xx if the account
should not exist, or it replies with 4xx and creates the account.

Wietse

Re: Strange issue with reject_unverified_recipient (LMTP/Dovecot)

[A. Schulze]

Am 15.10.2017 um 15:29 schrieb Jozef Matický:
> Hello Andreas,
> 
> Had some users complaining about mailboxes (and catch-alls) they created were 
> not accepting e-mails - Postfix, due to caching, was rejecting the e-mail as 
> if the mailbox wouldn't exist (apparently due to a fact someone was trying to 
> send an e-mail to that mailbox before it even existed - maybe spammer, maybe 
> a legit user).

That's a use case we where also faced years ago. We solved it by documentation. 
Also we "train" our users: whatever you configure, wait an hour!
(No matter if it' really required or not)

Then we consequently arrange our systems so every change is visible within one 
hour: address_verify_negative_refresh_time = 30m in this case.
Simple but understandable for our users

Andreas

Re: Strange issue with reject_unverified_recipient (LMTP/Dovecot)

[Wietse Venema]

Jozef Matick?:
> Hello Andreas,
> 
> Had some users complaining about mailboxes (and catch-alls) they created 
> were not accepting e-mails - Postfix, due to caching, was rejecting the 
> e-mail as if the mailbox wouldn't exist (apparently due to a fact 
> someone was trying to send an e-mail to that mailbox before it even 
> existed - maybe spammer, maybe a legit user).
> 
> The below statement I'm not 100% sure about as I was playing with 
> multiple config options, will have to check this again, however:
> I believe I also played with negative_refresh_time (setting it to 1s), 
> however I think what was happening was that e-mail was 450 deferred 
> (address ver. in prog.) for the first time the sender connected and 
> tried to deliver to already neg. cached address. Only afterwards the 
> cache was refreshed - causing the e-mail to defer with 450 once.
> This would have caused delays in delivery (or lost e-mails with bad 
> implementations) and more complaints from users saying there is a 
> problem with e-mails.

Summary: if you want to make you scheme work with address verification,
then you need a delivery agent that creates mailboxes instead of
replying with 'user unknown'. But that is not all.

Some choices are:

- The SMTP server replies with 5xx or 4xx, because the delivery
  agent replies with 'user unknown'. You don't want that.

- The SMTP server replies with 4xx, because the verify service
  replies with 'address verification in progress'. You don't want
  that.

- The SMTP server replies with 2xx, even though the delivery agent
  replies with 'user unknown'. The SMTP server must accept the email
  message, and delivery will fail immediately. You don't want that.

- The SMTP server replies with 2xx, because the delivery agent
  replies with 'user exists'. This means that when a mailbox does
  not exist, the delivery agent must reply AFTER the mailbox is
  created. 

Since the time to create mailboxes increases with server load, that
last variant also requires removing the loop with address_verify_poll_count
and address_verify_poll_delay, and replacing that loop with a
blocking query.

See a different response for hooking the auto-create feature into
the recipient maps for recipient validation.

Wietse

Re: recommended smtp proxy script?

[Matus UHLAR - fantomas]

On 13/10/17 10:40, Matus UHLAR - fantomas wrote:

the only important part is - you apparently should not use milter on
submission ports.



Am 13.10.2017 um 20:42 schrieb Daniele Nicolodi:

Why?



On 13/10/17 15:30, Robert Schetterer wrote:

some milters are fine to use with submission
others not, i.e clamav-milter should work, spamass-milter
on the other hand may slow down sending mail, which might lead to anger
for users, it needs time to find out spamness of an email by doing i.e
outside network operations with razor etc.
So it simply depends on what you trying to goal .,rethink of your
whole mail design , look at your logs then choose the tool or tec which
design fits best for desired task


Yes, I should have explained it. Simply said - anything that takes much time
should apparently not be used on submission ports, or you may expect your
users to complain about long mail sending delays.

OTOH, it's more effective when you want to reject mail at SMTP time,
because in that case you don't have to generate bounces. 


Just be careful that the processing is done within 10 minutes, which is the
timeout for DATA trermination phase, otherwse you can encounter data
duplication or message retransmission. It may be better to have this under 5
minutes.

On 13.10.17 16:09, Daniele Nicolodi wrote:

This is a much less categorical statement.

The possible issues you point out are not specific to milters, but apply
to all mail filtering techniques.


this applies to smtp proxy and milters, but it doesn't apply to content
filter, since that one applies after mail has been received.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Nothing is fool-proof to a talented fool. 

Blocking mail from clients who

[Gerben Wierda]

My main restrictions in main.cf are (on macOS Server)

smtpd_client_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
check_client_access 
regexp:/Library/Server/Mail/Config/postfix/rna_rbl_whitelist_clients,
reject_rbl_client zen.spamhaus.org,
permit
smtpd_delay_reject = yes
smtpd_enforce_tls = no
smtpd_helo_required = yes
smtpd_helo_restrictions =
permit_mynetworks,
reject_non_fqdn_helo_hostname,
reject_invalid_helo_hostname,
permit
smtpd_recipient_restrictions = permit_sasl_authenticated 
reject_unauth_pipelining reject_non_fqdn_recipient permit_mynetworks 
reject_unauth_destination reject_unlisted_recipient check_client_access 
regexp:/Library/Server/Mail/Config/postfix/rna_policy_whitelist_clients 
check_sender_access 
regexp:/Library/Server/Mail/Config/postfix/rna_policy_whitelist_senders 
check_policy_service unix:private/policy permit

Rbl and greylisting helps to filter out most spam attempts. I have to turn of 
greylisting for a few hours today, and a message came through that had both 
From: and To: set to my email address. This was accepted because I am the 
delivery agent for that domain.

But an outside, non SASL-authenticated client that says it wants to deliver 
mail From my domain is illegal. Apparently, that one still gets through (though 
is generally blocked by greylisting). Anyway, is there a way to block that 
without blocking legitimate mail?

Gerben Wierda
Chess and the Art of Enterprise Architecture 
Mastering ArchiMate 
Architecture for Real Enterprises 
 at InfoWorld
On Slippery Ice  at EAPJ

Re: Blocking mail from clients who

[Robert Schetterer]

Am 15.10.2017 um 18:34 schrieb Gerben Wierda:
> My main restrictions in main.cf are (on macOS Server)
> 
> smtpd_client_restrictions =
> permit_mynetworks,
> permit_sasl_authenticated,
> check_client_access
> regexp:/Library/Server/Mail/Config/postfix/rna_rbl_whitelist_clients,
> reject_rbl_client zen.spamhaus.org ,
> permit
> smtpd_delay_reject = yes
> smtpd_enforce_tls = no
> smtpd_helo_required = yes
> smtpd_helo_restrictions =
> permit_mynetworks,
> reject_non_fqdn_helo_hostname,
> reject_invalid_helo_hostname,
> permit
> smtpd_recipient_restrictions = permit_sasl_authenticated
> reject_unauth_pipelining reject_non_fqdn_recipient permit_mynetworks
> reject_unauth_destination reject_unlisted_recipient check_client_access
> regexp:/Library/Server/Mail/Config/postfix/rna_policy_whitelist_clients
> check_sender_access
> regexp:/Library/Server/Mail/Config/postfix/rna_policy_whitelist_senders
> check_policy_service unix:private/policy permit
> 
> Rbl and greylisting helps to filter out most spam attempts. I have to
> turn of greylisting for a few hours today, and a message came through
> that had both From: and To: set to my email address. This was accepted
> because I am the delivery agent for that domain.
> 
> But an outside, non SASL-authenticated client that says it wants to
> deliver mail From my domain is illegal. Apparently, that one still gets
> through (though is generally blocked by greylisting). Anyway, is there a
> way to block that without blocking legitimate mail?
> 
> Gerben Wierda
> Chess and the Art of Enterprise Architecture 
> Mastering ArchiMate 
> Architecture for Real Enterprises
>  at
> InfoWorld
> On Slippery Ice  at EAPJ
> 

are you informed about dkim,spf,dmarc ?
Do you relay for third party ?


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

n00b To The Mechanics

[cacook]

I've run Linux on all my machines for 18 years, but have never needed to
understand the workings of email, as I've always used shared hosting and
cPanel.  Now I'm setting up my own server and I'd like to understand the
actual mechanics of email.

I've read several Postfix docs including
http://www.postfix.org/OVERVIEW.html and still don't get it.

It seems that Postfix is only an SMTP server;  it only listens on 25. 
If I understand, it listens on 25 for incoming mail, processes it, then
saves it in a flat file.

- If someone sends me an email to char...@example1.com,  example1.com
resolves to some IP which finds my Postfix server on 25.  That email is
then stored at /var/spool/mail/charles right?

- What if I want to receive email in the name of someone who does not
have a passwd account on that machine?  How does that work and how would
I set it up?

- If someone then sends an email to me at charles@example*2*.com, how
can I differentiate that email from the one to example1.com?

- So these emails are now stored on my mail server.  How do I get them
to my workstation, and where would they go?  Or would my mail client in
my workstation fetch them directly from the mail server, and if so how?

- If this is how things work, what role does pop3 or imap play?  I've
always used Thunderbird as a mail client, and I've always set it to
fetch from mail.example1.com.  How would my workstation and the DNS
system know where mail.example1.com is?  There's nowhere to set it in
Postfix, and there doesn't seem to be a virtual hosts function.

- I have never been able to make Thunderbird fetch local mail from
/var/spool/mail.  Is there some trick, or a better way?  I'm not wedded
to Thunderbird but it does store email where I want it and in a
flat-file, unlike a number of other clients, and it is easy to use.





0x946C680E.asc
Description: application/pgp-keys

Re: Blocking mail from clients who

[Dominic Raferd]

On 15 October 2017 at 17:34, Gerben Wierda  wrote:

> My main restrictions in main.cf are (on macOS Server)
>
> smtpd_client_restrictions =
> permit_mynetworks,
> permit_sasl_authenticated,
> check_client_access regexp:/Library/Server/Mail/Config/postfix/rna_rbl_
> whitelist_clients,
> reject_rbl_client zen.spamhaus.org,
> permit
> smtpd_delay_reject = yes
> smtpd_enforce_tls = no
> smtpd_helo_required = yes
> smtpd_helo_restrictions =
> permit_mynetworks,
> reject_non_fqdn_helo_hostname,
> reject_invalid_helo_hostname,
> permit
> smtpd_recipient_restrictions =
> ​​
> permit_sasl_authenticated reject_unauth_pipelining
> reject_non_fqdn_recipient permit_mynetworks reject_unauth_destination
> reject_unlisted_recipient check_client_access regexp:/Library/Server/Mail/
> Config/postfix/rna_policy_whitelist_clients check_sender_access
> regexp:/Library/Server/Mail/Config/postfix/rna_policy_whitelist_senders
> check_policy_service unix:private/policy permit
>
> Rbl and greylisting helps to filter out most spam attempts. I have to turn
> of greylisting for a few hours today, and a message came through that had
> both From: and To: set to my email address. This was accepted because I am
> the delivery agent for that domain.
>
> But an outside, non SASL-authenticated client that says it wants to
> deliver mail From my domain is illegal. Apparently, that one still gets
> through (though is generally blocked by greylisting). Anyway, is there a
> way to block that without blocking legitimate mail?
>

​You could add your domain to
/Library/Server/Mail/Config/postfix/rna_policy_whitelist_senders as a
reject:

/.*@mydomain.tld/ REJECT

Any sender purporting to be from your domain but not authenticated should
be blocked by this. Authenticated senders will not be touched by this
because they are already approved by ​permit_sasl_authenticated.

Re: Strange issue with reject_unverified_recipient (LMTP/Dovecot)

[Jozef Matický]

Hello Wietse,

Not sure I understand.
The problem I have is when I have address_verify_negative_cache = no. 
Postfix is then deferring sender with 450 Address verification in 
progress despite the fact Dovecot (LMTP) is replying to Postfix with 550 
User doesn't exists (with smtpd_recipient_restrictions = 
reject_unverified_recipient as I don't want to generate backscatter).
I assumed when Dovecot replies with 550, then Postfix should reject the 
email, not to deffer the delivery.
This is the reason I'm not able to turn address_verify_negative_cache 
off as e-mail for users that don't exist will be deferred instead of 
rejected, thus it will be floating somewhere between the servers for 
couple of days after which sender will be notified that there is a 
problem with delivery (and not because user doesn't exists but because 
recipient's server is doing address verification for multiple days now).


When I set address_verify_negative_cache = yes, then all is working as 
expected - Postfix rejects the sender with 550 when Dovecot's LMTP 
replies with 550 User doesn't exists.

When Dovecot replies User does exists then mail is taken for delivery.

Thank you.

Best regards,
Jozef.


On 15. 10. 2017 16:31, Wietse Venema wrote:

A. Schulze:

The problem I have is when I set address_verify_negative_cache = no.

...

It looks like when there is status=undeliverable-but-not-cached


There is no such reply. In reality, the reply is that the address
probe is in progress (DEL_RCPT_STAT_TODO).

This is what happens:

1. SMTP daemon queries verify service for an address probe result.
2. There is no address probe result. This triggers a verify probe.
3. Repeat 1 until the addres probe poll count is reached.

I don't see how one would avoid this, other than by blocking the
SMTP daemon's query while a probe is in progress or until a time
limit is reached.

If you want to create accounts on the fly, don't break address
verification.

Instead, change your local_recipient_maps, virtual_alias_maps,
relay_recipient_maps or virtual_mailbox_maps. At the end of those
maps, a tcp_table or socketmap service that handles the queries for
non-existent addresses. This service replies with 5xx if the account
should not exist, or it replies with 4xx and creates the account.

Wietse

Re: Blocking mail from clients who

[Bill Shirley]

> /.*@mydomain.tld/ REJECT

The leading .* is not needed.  You should escape the period before tld (\.).  
You can
also send a message:
/@.*example\.com$/    REJECT You are not me (40,000).
This works for me.  Note: I'm using pcre instead of regexp.

Bill

On 10/15/2017 1:04 PM, Dominic Raferd wrote:



On 15 October 2017 at 17:34, Gerben Wierda mailto:gerben.wie...@rna.nl>> wrote:

My main restrictions in main.cf  are (on macOS Server)

smtpd_client_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
check_client_access 
regexp:/Library/Server/Mail/Config/postfix/rna_rbl_whitelist_clients,
reject_rbl_client zen.spamhaus.org ,
permit
smtpd_delay_reject = yes
smtpd_enforce_tls = no
smtpd_helo_required = yes
smtpd_helo_restrictions =
permit_mynetworks,
reject_non_fqdn_helo_hostname,
reject_invalid_helo_hostname,
permit
smtpd_recipient_restrictions =
​​
permit_sasl_authenticated reject_unauth_pipelining 
reject_non_fqdn_recipient permit_mynetworks reject_unauth_destination
reject_unlisted_recipient check_client_access 
regexp:/Library/Server/Mail/Config/postfix/rna_policy_whitelist_clients
check_sender_access 
regexp:/Library/Server/Mail/Config/postfix/rna_policy_whitelist_senders 
check_policy_service
unix:private/policy permit

Rbl and greylisting helps to filter out most spam attempts. I have to turn 
of greylisting for a few hours today, and a
message came through that had both From: and To: set to my email address. 
This was accepted because I am the delivery
agent for that domain.

But an outside, non SASL-authenticated client that says it wants to deliver 
mail From my domain is illegal. Apparently,
that one still gets through (though is generally blocked by greylisting). 
Anyway, is there a way to block that without
blocking legitimate mail?


​You could add your domain to 
/Library/Server/Mail/Config/postfix/rna_policy_whitelist_senders as a reject:

/.*@mydomain.tld/ REJECT

Any sender purporting to be from your domain but not authenticated should be blocked by this. Authenticated senders will not 
be touched by this because they are already approved by ​permit_sasl_authenticated.

Re: Strange issue with reject_unverified_recipient (LMTP/Dovecot)

[Wietse Venema]

Jozef Matick?:
> Hello Wietse,
> 
> Not sure I understand.
> The problem I have is when I have address_verify_negative_cache = no. 
> Postfix is then deferring sender with 450 Address verification in 
> progress despite the fact Dovecot (LMTP) is replying to Postfix with 550 
> User doesn't exists (with smtpd_recipient_restrictions = 
> reject_unverified_recipient as I don't want to generate backscatter).

When a mailbox needs to be created on-demand, you don't want the
4xx response (verification in progress) before the mailbox is
created, but you want the 5xx response (mailbox does not exist)
which causes the message to be returned as undeliverable.

If you really want that, just set a short expire time for negative
verification results.

Wietse

Re: n00b To The Mechanics

[Anvar Kuchkartaev]

  Understanding how emails works in linux is a wide and difficult question:https://en.m.wikipedia.org/wiki/Email(see the operation part of the page)The postfix in linux systems is a application who transmits emails or receives them and stores them into files. It does not help you to read or manage your emails. When you send email from your client application from u...@mydomain.com to us...@example.com first your client application connects to postfix instance with your credentials and sends email from client application to ‎us...@example.com and uses remote postfix server as proxy in the middle of your email client application and us...@example.com (this type of operations are required because if we imagine working email server with correct configurations only your remote postfix instance is verified and authorized to send emails as the name of the domain mydomain.com and your client application might change networks (especially for mobile clients) but emails will not get into spam boxes). Then when email reaches to remote postfix instance first it checks if you are authorized to send by using u...@mydomain.com and then it queries dns record type MX to check address of email server of domain example.com, then it connects using smtp protocol to remote server and pushes email to it. Remote server also does the same type of verifications when receives email from your postfix instance. In order to read the emails from your inbox (which postfix received and stored in files) you have to use completely different services. You might use dovecot, cyrus-imapd. It is a really complex system (even configuring postfix also a very complex). I rather recommend getting a courses of how email systems works, advanced configurations of postfix, handling email in linux, or hire a professional (in my opinion email in linux is more difficult than the rest of the system except kernel). Anvar Kuchkartaev an...@anvartay.com From: cac...@quantum-equities.comSent: domingo, 15 de octubre de 2017 07:02 p.m.To: postfix-users@postfix.orgSubject: n00b To The Mechanics
  


  
  
I've run Linux on all my machines for 18 years, but have never
  needed to understand the workings of email, as I've always used
  shared hosting and cPanel.  Now I'm setting up my own server and
  I'd like to understand the actual mechanics of email.
I've read several Postfix docs including
  http://www.postfix.org/OVERVIEW.html and still don't get it.
It seems that Postfix is only an SMTP server;  it only listens on
  25.  If I understand, it listens on 25 for incoming mail,
  processes it, then saves it in a flat file.
- If someone sends me an email to char...@example1.com, 
  example1.com resolves to some IP which finds my Postfix server on
  25.  That email is then stored at /var/spool/mail/charles right?
- What if I want to receive email in the name of someone who does
  not have a passwd account on that machine?  How does that work and
  how would I set it up?
- If someone then sends an email to me at charles@example2.com,
  how can I differentiate that email from the one to example1.com?
- So these emails are now stored on my mail server.  How do I get
  them to my workstation, and where would they go?  Or would my mail
  client in my workstation fetch them directly from the mail server,
  and if so how?

- If this is how things work, what role does pop3 or imap play? 
  I've always used Thunderbird as a mail client, and I've always set
  it to fetch from mail.example1.com.  How would my workstation and
  the DNS system know where mail.example1.com is?  There's nowhere
  to set it in Postfix, and there doesn't seem to be a virtual hosts
  function.

- I have never been able to make Thunderbird fetch local mail
  from /var/spool/mail.  Is there some trick, or a better way?  I'm
  not wedded to Thunderbird but it does store email where I want it
  and in a flat-file, unlike a number of other clients, and it is
  easy to use.