[Help] Postscreen let zombies to pass through
.641323+02:00 03as postfix/smtpd[16634]: connect from unknown[84.15.191.254] 2012-07-26T14:26:51.972631+02:00 03as postfix/smtpd[16634]: ED6BA596F3A: client=unknown[84.15.191.254] 2012-07-26T14:26:52.408466+02:00 03as amavis[18028]: (18028-08) Checking: MFeWLMK8XN0s [84.15.191.254] -> 2012-07-26T14:26:52.489638+02:00 03as postfix/smtpd[16634]: disconnect from unknown[84.15.191.254] 2012-07-26T14:26:53.018148+02:00 03as amavis[18028]: (18028-08) Blocked SPAM, [84.15.191.254] [84.15.191.254] , quarantine: MFeWLMK8XN0s[30], Message-ID: , ma il_id: MFeWLMK8XN0s, Hits: 10.429, size: 3464, pt: 30, 662 ms [...] Why did this happens? The postscreen conf is the same on all MX servers: [root@01as ]# postconf -n | grep postscreen postscreen_access_list = permit_mynetworks, cidr:/etc/postfix /postscreen_access.cidr postscreen_bare_newline_action = enforce postscreen_bare_newline_enable = yes postscreen_blacklist_action = drop postscreen_cache_map = memcache:/etc/postfix/memcache-postscreen.cf postscreen_dnsbl_action = enforce postscreen_dnsbl_reply_map = texthash:/etc/postfix/postscreen-dnsbl-reply-map postscreen_dnsbl_sites = zen.dnsbl*2 bl.spamcop.net*1 b.barracudacentral.org*1 dnsbl.sorbs.net*1 psbl.surriel.com*1 ubl.unsubscore.com*1 dnsbl-1.uceprotect.net*1 dnsbl-2.uceprotect.net*1 dnsbl-3.uceprotect.net*2 postscreen_dnsbl_threshold = 2 postscreen_greet_action = enforce postscreen_greet_banner = ucas.csi.it ESMTP $mail_name. I don't remember of you, I'll check your mind! postscreen_greet_ttl = 7d postscreen_non_smtp_command_enable = yes postscreen_pipelining_enable = yes mail_version = 2.9.1 This is the content of memcache-postscreen.cf, identical on all MX servers: [root@01as ]# cat /etc/postfix/memcache-postscreen.cf memcache = inet:01as:11211 backup = btree:/var/lib/postfix/postscreen_cache # TTL if you don't use backup ttl = 2592000 # Remember # postscreen_cache_cleanup_interval = 0 # on ALL instances if you DON'T use backup. Thank you very much for every hints. Regards Marco
Re: [Help] Postscreen let zombies to pass through
Wietse Venema porcupine.org> writes: > Please show the problem without logs from other servers. I'm sorry for word wrap and mix. This is an example: https://docs.google.com/open?id=0B-09bt7bbY_0MHU4bGduZTFWeGc Thanks again Marco
norig_rcpt logs
Hello, Postfix logs to syslog the number of recipients in the "nrctp" field. The nrcpt field reports the number of recipient after the expansion (ie: by virtual table). A field reporting the number of recipients written by the client (number of "RCTP TO") could be very useful too, to perform data analysis. If this is already possible, I would ask an help to configure Postfix in order to obtain this log. Otherwise, I thank you very much if you could consider to add this feature in future. Today, I can obtain this information grouping all logs with the same queue_id and counting the different "orig_to" fields, where they are present. So it is possible, but the operation is quite complex. Many thanks Cheers Marco
header_checks
Hello all. I'm using postfix since at least 20 years and I could always find a satisfactory solution to my problems. However I have an now an issue with the filtering of the mail headers, as I want to use the headers_check functionality only for e-mails sent to external/Internet addresses. This without the need of creating a number of roles depending from the internal sender, IP, ecc as I have found as hints by googling today (I do support several IPs, domains, ecc). I have one VM dedicated to Postfix and it seems that the only general solution is to create a new Posfix VM, define this as the relayhost and apply the headers_check in this VM that will be used only for Internet outgoing traffic. Is there any other solution that will not need a new VM? Tnx Marco
Re: header_checks
Il 29. 10. 15 14:38, Wietse Venema ha scritto: > Marco: >> Hello all. >> >> I'm using postfix since at least 20 years and I could always find a >> satisfactory solution to my problems. >> >> However I have an now an issue with the filtering of the mail headers, >> as I want to use the headers_check functionality only for e-mails sent >> to external/Internet addresses. This without the need of creating a >> number of roles depending from the internal sender, IP, ecc as I have >> found as hints by googling today (I do support several IPs, domains, ecc). >> >> I have one VM dedicated to Postfix and it seems that the only general >> solution is to create a new Posfix VM, define this as the relayhost and >> apply the headers_check in this VM that will be used only for Internet >> outgoing traffic. >> >> Is there any other solution that will not need a new VM? > For external deliveries, Postfix has smtp_header_checks (default: > empty) which provide a subset of functionality (for example they > cannot change the delivery with redirect, defer, reject, filter, > but they can modify content with replace, prepend, ignore, warn). > > If you need the defer, reject, filter functionality then that > requires ordinary header_checks which are available only while > Postfix receives mail. > > Options: > > - Re-implement header_checks with a Milter, and apply them only for > external destinations. > > - Use header_checks in a second Postfix instance (or Postfix in a > VM) for delivering external mail (see MULTI_INSTANCE_README, but > beware that some distros have broken multi-instance support). > > Wietse Tnx for the input. I will explore the multi instance option, even it is really not unlikely I will create a new VM as this seems to be easier after a first diagonal reading of the MULTI_INSTANCE_README (and the other problems you mentioned). A Milter could be also an option in the future, with the target of "sanitizing" the mails by replacing the original header with a new one, ensuring no internal information leakage (i.e. including the bi-directional mapping of the internal message ID created by the internal mail clients "public" message IDs). I'm aware that someone is flagging this type of protection as "security by obscurity". In my opinion this is partially false as this is not a direct security measure (where security by obscurity is for sure wrong) , instead just a prudent way to make attacks more difficult. I have seen this type of approach in some commercial products (E-mail gateways, etc) and I'm surprised I have never seen this applied to Postfix.
Re: header_checks
Il 29. 10. 15 17:33, Wietse Venema ha scritto: > Marco: >> A Milter could be also an option in the future, with the target of >> "sanitizing" the mails by replacing the original header with a new one, >> ensuring no internal information leakage (i.e. including the >> bi-directional mapping of the internal message ID created by the > smtp_header_checks has a replace option. The issue I have is that smtp_header_checks is unable to distinguish between mail sent to internal destinations (the VMsrunning the services) and the Internet. I could implement more "precise" roles, however my objective is to avoid this type of header check rules that will have to be changed/updated depending on the internal setup and are prone to get wrong after some time. > >> internal mail clients "public" message IDs). I'm aware that someone is >> flagging this type of protection as "security by obscurity". In my >> opinion this is partially false as this is not a direct security measure >> (where security by obscurity is for sure wrong) , instead just a prudent >> way to make attacks more difficult. I have seen this type of approach in >> some commercial products (E-mail gateways, etc) and I'm surprised I have >> never seen this applied to Postfix. > If you are concerned about leaking client details, then there are > other leaks besides the message ID header. Simple transformations > can be done with the smtp_header_checks "replace" action. For more > complex transformations, use the same interfaces as content filters. Yes, that's exactly what I'm currently doing, i.e. I'm already removing all headers containing information about the internal domains, user-agent and mailer types, virus checking, internal path of mails, etc etc This is solving most of the leakage risks, however this is still not perfect, i.e. the message ID header masking requires a mapping table that can be implemented only in a Milter. > > Wietse Marco
Re: header_checks
Il 29. 10. 15 18:09, Wietse Venema ha scritto: > Wietse: >> smtp_header_checks has a replace option. > Marco: >> The issue I have is that smtp_header_checks is unable to distinguish >> between mail sent to intranet destinations (the VMsrunning the services) >> and the Internet. > Yes, it can: > > /etc/postfix/transport: >example.com intranet: >.example.com intranet: >localhostintranet: > > /etc/postfix/master.cf: > intranet unix - - n - - smtp > smtp unix - - n - - smtp > -o smtp_header_checks=whatever > > This assumes "default_transport = smtp" which is the default. OK, tnx for the hint, this is really the piece of the puzzle I was missing. > Wietse Marco
Re: SV: SV: SV: SV: Blocking TLDs
Hello all. In some countries e-mails are subject to the same rules as physical mail, and the destruction or non-delivery is a criminal offence. Just to mention there are i.e. countries in which you need the authorization of a judge to access the mailbox of an user, or you are not authorized to track the e-mail traffic of an enterprise unless evidence of a misuse is available. And so on and so forth, e-mail rules are really country related. The only common rule, in all laws I have seen, is related to the detection of a risk, that allows everywhere a protective attitude. This means that mails can be not delivered, but this does not implies they can be destroyed, as some countries do require a complete logging of the e-mail traffic (I'm for the FLAME ON with the regulators that did take this decision, don't blame me...) There is no valid general statement concerning this question, it really depends from where your servers are located. Marco Il 20. 02. 16 15:01, Sebastian Nielsen ha scritto: > I readed that on wikipedia, and readed the sources, and one thing I can say, > is that the source is heavily misinterpreted. They refer to physical mail, > and telecommunication, where a set of rules apply to physical mail, and some > other set apply to telecommunication. > Of course, you are not allowed to tamper with third-party communication, but > if you run a mail server, then you are "in the loop" and are permitted to do > whatever you want. Nobody forces you to accept whatever you don't want into > your network. If you want to toss all HTML mail destined for your company > into /dev/null, its up to you. > This provided that you didn't unauthorizedly insert yourself into the loop. > If a end user select to use you as mail service, they have to abide by your > rules, including that some mails might get tossed away. But if you force > somebody, which aren't using your network, to use your mail service, for > example via ARP spoofing or fake Wifi AP's, then its computer intrusion. > > Also, the law does not make any difference on reject or discard, either you > are allowed to block, and then it will apply to both reject and discard, or > you are not allowed to block, and then it apply to both reject and discard. > Theres no difference in rejecting or discarding, its still considered > distruption, if you do it in the wrong situation. > > If I receive a call from somebody asking me to forward information to person > D, even if I say "yes, I will do", its not illegal to ignore that and not > forward the phone call. Its my phone, if someone calls my phone, they have > to abide to my rules. > > Note the wording "electronic communication", which also apply to website > traffic and such. The ruling is more aiming on hackers, for example > "distrupting communications between 2 parties" is meant to target DoS, not > someone blocking certain email traffic into their network. > > What I have understand, E-mail does not have any special catering, not > either in german law or swedish law. Maybe some single EU country does pay > special attention to E-mails, but normally, E-mail is same as website > traffic is same as for example Skype, and is just TCP/IP packets over the > internet. And TCP/IP packets its up to you if you want to accept, reject, or > drop packets destined for your network. > > Simple as this: The mail server you run for a company, or for some user or > whatever, can be seen as your post-box outside the house. Of course, even if > you receive physical mail for other people in same house, you are fully > permitted to regulate that mail and toss mail you don't want, even if its > adressed to someone else at that adress. Compare with for example a parent > that toss away porn magazines adressed for their child, without telling > either the magazine company or the child. > > > Of course, a ISP mailserver is bound by much more strict rules, and here it > might be regulation prohibiting when you are allowed to reject's/discard's, > but I suspect none on this mailing list are running a ISP mailserver. (An > ISP is defined as someone who runs a access network of a specific minimum > size, wired, wireless or cellular, that people can access for a fee, where > no prior internet access is required - so VPNs don't count. A hotel wifi > wont count, it must be something larger, and being a ISP requires a special > license from the government, like a bank, because being a ISP is a community > service and must meet some minimum quality standards) > > > So to put it short, if you block mail in the wrong situation, it don't > matter if its reject or discard. Either you may block, then reject=allowed, > discard=allowed, or you may not block, and t
Host name in the 250 answers to an ehlo
Hello. I have a small security concern with my external SMTP server: >220 mail.marcobaldo.ch ESMTP 250-iprovider.dmz.marcobaldo.ch >250-PIPELINING >250-SIZE >250-ETRN >250-STARTTLS >250-ENHANCEDSTATUSCODES >250-8BITMIME >250 DSN As you see smtpd_banner has been changed to reflect the MX records. Is there any way of changing the host name sent in the 250 ehlo answer without having to modify the definition of "myhostname", I would prefer to keep identical to the internal DNS name? Tnx for the answer and have a nice day Marco
Re: Host name in the 250 answers to an ehlo
Hello. Tnx for the prompt answer. I already have a bastion MTA and an internal mailhub, hosted on separate VMs. I'm also preparing an additional VM that will handle only the outgoing traffic, in order to apply specific headers filtering as we discussed some time ago. The issue I have is with the naming convention I'm using, as the VM hosting the bastion MTA is in a specific virtual LAN, and is also used as bastion for other exposed services. So I did want to use a generic host name inside this DNS zone. It seems that the simplest solution is to replicate in the public DNS the internal name of the bastion host, pointing to an external address, and change the MX record accordlying. Tnx and have a nice day Marco Il 29. 02. 16 19:27, Wietse Venema ha scritto: > Marco: >> Hello. >> >> I have a small security concern with my external SMTP server: >> >>> 220 mail.marcobaldo.ch ESMTP >> >> 250-iprovider.dmz.marcobaldo.ch >>> 250-PIPELINING >>> 250-SIZE >>> 250-ETRN >>> 250-STARTTLS >>> 250-ENHANCEDSTATUSCODES >>> 250-8BITMIME >>> 250 DSN >> As you see smtpd_banner has been changed to reflect the MX records. Is >> there any way of changing the host name sent in the 250 ehlo answer >> without having to modify the definition of "myhostname", I would prefer >> to keep identical to the internal DNS name? > Postfix names, as seen on the external network, should be consistent > with the external world's view of DNS. > - The MTA name in Postfix SMTP server responses (banner, ehlo, etrn, quit, > ...) > - The MTA name in Postfix SMTP client EHLO commands > - The MTA name in Postfix delivery status notifications. > - Whatever else leaks the MTA name. > > You can add per-daemon overrides in master.cf, but it gets complicated, > and it breaks some of the loop detection safety mechanisms. > > It may be easier to use a separate MTAs for separate roles: one > "bastion" MTA that is exposed to the outside, one "mailhub" MTA > that is exposed to the inside, with mail forwarding between them. > Standard firewall setup. > > Wietse
understanding postscreen_dnsbl_whitelist_threshold
Hello,
could you help me to understand this behavior in postcreen?
I see:
2016-05-20T15:49:13.988843+02:00 mx postfix/postscreen[32210]: PASS NEW
[157.56.110.148]:29046
2016-05-20T15:49:13.828110+02:00 mx postfix/postscreen[32210]: NOQUEUE:
reject: RCPT from [157.56.110.148]:29046: 450 4.3.2 Service currently
unavailable; from=, to=, proto=ESMTP,
helo=
2016-05-20T15:49:07.392420+02:00 mx postfix/dnsblog[8434]: addr
157.56.110.148 listed by domain list.dnswl.org as 127.0.3.0
2016-05-20T15:49:07.384799+02:00 mx postfix/dnsblog[1304]: addr
157.56.110.148 listed by domain wl.mailspike.net as 127.0.0.17
2016-05-20T15:49:07.369300+02:00 mx postfix/postscreen[32210]: CONNECT
from [157.56.110.148]:29046 to [158.102.109.83]:25
I configured
postscreen_dnsbl_whitelist_threshold = -2
so I expect that if a client get a rank of -2 should not be disconnected.
[root@mx etc]# postconf | grep postscreen_
postscreen_access_list = permit_mynetworks,
cidr:/etc/postfix/postscreen_access.cidr
postscreen_bare_newline_action = enforce
postscreen_bare_newline_enable = yes
postscreen_bare_newline_ttl = 30d
postscreen_blacklist_action = drop
postscreen_cache_cleanup_interval = 12h
postscreen_cache_map = memcache:/etc/postfix/memcache-postscreen.cf
postscreen_cache_retention_time = 7d
postscreen_client_connection_count_limit =
$smtpd_client_connection_count_limit
postscreen_command_count_limit = 20
postscreen_command_filter =
postscreen_command_time_limit = ${stress?{10}:{300}}s
postscreen_disable_vrfy_command = $disable_vrfy_command
postscreen_discard_ehlo_keyword_address_maps =
$smtpd_discard_ehlo_keyword_address_maps
postscreen_discard_ehlo_keywords = $smtpd_discard_ehlo_keywords
postscreen_dnsbl_action = enforce
postscreen_dnsbl_max_ttl =
${postscreen_dnsbl_ttl?{$postscreen_dnsbl_ttl}:{1}}h
postscreen_dnsbl_min_ttl = 60s
postscreen_dnsbl_reply_map = pcre:/etc/postfix/postscreen-dnsbl-reply-map
postscreen_dnsbl_sites = zen.dnsbl*4 bl.spamcop.net*1
b.barracudacentral.org*1 dnsbl.sorbs.net*1 psbl.surriel.com*1
ubl.unsubscore.com*1 bl.score.senderscore.com*1 dnsbl-1.uceprotect.net*1
dnsbl-2.uceprotect.net*1 dnsbl-3.uceprotect.net*1 bl.mailspike.net*1
list.dnswl.org=127.[0..255].[0..255].[0..2]*-1
list.dnswl.org=127.[0..255].[0..255].[3..254]*-2 whiteip.rbl.csi.it*-3
wl.mailspike.net=127.0.0.[18..20]*-1
postscreen_dnsbl_threshold = 2
postscreen_dnsbl_timeout = 10s
postscreen_dnsbl_whitelist_threshold = -2
postscreen_enforce_tls = $smtpd_enforce_tls
postscreen_expansion_filter = $smtpd_expansion_filter
postscreen_forbidden_commands = $smtpd_forbidden_commands
postscreen_greet_action = enforce
postscreen_greet_banner = mx.example.com ESMTP $mail_name. I don't
remember of you, I'll check your mind!
postscreen_greet_ttl = 7d
postscreen_greet_wait = ${stress?{2}:{6}}s
postscreen_helo_required = $smtpd_helo_required
postscreen_non_smtp_command_action = drop
postscreen_non_smtp_command_enable = yes
postscreen_non_smtp_command_ttl = 30d
postscreen_pipelining_action = enforce
postscreen_pipelining_enable = yes
postscreen_pipelining_ttl = 30d
postscreen_post_queue_limit = $default_process_limit
postscreen_pre_queue_limit = $default_process_limit
postscreen_reject_footer = $smtpd_reject_footer
postscreen_tls_security_level = $smtpd_tls_security_level
postscreen_upstream_proxy_protocol =
postscreen_upstream_proxy_timeout = 5s
postscreen_use_tls = $smtpd_use_tls
postscreen_watchdog_timeout = 10s
postscreen_whitelist_interfaces = static:all
mail_version = 3.1.0
Thank you very much
Best Regards
Marco
Re: understanding postscreen_dnsbl_whitelist_threshold
Il 23/05/2016 10:42, Marco ha scritto: 2016-05-20T15:49:07.384799+02:00 mx postfix/dnsblog[1304]: addr 157.56.110.148 listed by domain wl.mailspike.net as 127.0.0.17 Ah, I understood. wl.mailspike.net as 127.0.0.17 doesn't match the rule: wl.mailspike.net=127.0.0.[18..20]*-1 but dnsblog logs the result also if different. I didn't see that the result doesn't match ;) Best Regards Marco
Re: How to restrict encrypted email
Hello Michael.
It is a near impossible task, as i.e. encrypted data can easily be
transferred as uuencode text in a plain text message, and you will not
notice this in the headers.
And also trying to actively detected whether or not the body or the
attachments of a message are encrypted is quite tricky, and also
potentially prone to a number of positive false detections.
If this is not enough steganography and other methodologies can be used
to hide encrypted data, making the task really complex even for high-end
organizations
More, you could maybe have some form of binding agreement with the
ham-radio operators, prohibiting the usage of encryption. However you
will be not able to have a such legal protection with all other Internet
users sending mails to the ham-radio users.
This means you have to decide whether or not you want to take the risk,
and if yes, maybe, minimize it with some filtering for the obvious cases
as you propose.
Have a nice day
Marco
Il 16. 07. 16 07:25, Michael Fox ha scritto:
> I'd like to be able to reject mail that contains encrypted content. This is
> to satisfy US FCC rules against encrypted content on amateur radio
> frequencies. Some of our clients may connect via amateur radio.
>
> I'd like to be able to restrict it only for certain clients. But, as I
> understand it, header checks can only be applied globally, to all mail.
>
> Sorry if this is a dumb question. But, unfortunately, I don't have any
> experience with encrypted mail. From what I've read, I'm thinking I need:
>
> main.cf:
>
> mime_header_checks = pcre:${config_directory}/mime_header_checks.pcre
>
>
> mime_header_checks.pcre:
>
> # Block encrypted mail
> /^Content-Type\:.*multipart\/encrypted/ REJECT Encrypted
> content not allowed
>
>
>
> Is that sufficient?
> Any better ideas or other issues to consider?
>
> Thanks,
> Michael
>
>
disable routed mail sender
Hi all, checking the logs of a mailserver we found a bounce to an external sender with "routed sender", a sender with double @ like user@domain1@domain2 . Postfix 2.10.3 is configured to deliver the mail to a local Cyrus with the deliver command and the problem is that postfix pipe process bounced cause to "data format error. Command output: root: Bad protocol". The problem is that cyrus is not expecting user@domain1@domain2 like senders but investigating further i founded rfc 2822. According to rfc2822 Appendix B: Routes in addresses not allowed Routes in return path not allowed I searched in the mans and documentation but i didn't find a solution; is it possible to deny routed senders like user@domain1@domain2? Is it right that user@domain1@domain2 is not syntactically correct and the correct syntax is "@ONEdomain,@TWOdoamin:JOE@THREEdomain" ? Thanks Marco
null envelope and reject_authenticated_sender_login_mismatch
Hello,
I have the following problem.
I configured Postfix 3.0.1 to force SASL auth and permit only a set of
envelope sender addresses for each login
(reject_authenticated_sender_login_mismatch).
I would like to understand why the null envelope sender address ("<>")
is always permitted for all logins, even if it doesn't match the
smtpd_sender_login_maps table.
reject_authenticated_sender_login_mismatch works as expected for all
other envelopes.
Could you help me to know why?
Thank you very much
Marco
2bounce_notice_recipient = a...@example.com
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
anvil_rate_time_unit = 5m
append_at_myorigin = no
append_dot_mydomain = no
bounce_queue_lifetime = 1d
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
compatibility_level = 3
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd
$daemon_directory/$process_name $process_id & sleep 5
default_recipient_limit = 1
delay_warning_time = 3h
disable_vrfy_command = yes
enable_long_queue_ids = yes
error_notice_recipient = a...@example.com
hopcount_limit = 50
html_directory = no
inet_interfaces = $myhostname
inet_protocols = all
mail_name =
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
maximal_queue_lifetime = 1d
message_size_limit = 10485760
meta_directory = /usr/share/postfix
mydestination =
mynetworks =
newaliases_path = /usr/bin/newaliases.postfix
parent_domain_matches_subdomains =
proxy_interfaces = DD.DD.DD.DD
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-3.0.1/README_FILES
relay_domains =
sample_directory = /usr/share/doc/postfix-3.0.1/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
shlib_directory = no
smtp_helo_name = .example.com
smtp_helo_timeout = 30
smtp_mail_timeout = 30
smtp_quit_timeout = 30
smtpd_banner = $myhostname ESMTPSA $mail_name Welcome to Mail Submit
Agent!
smtpd_client_connection_rate_limit = 40
smtpd_client_message_rate_limit = 600
smtpd_client_recipient_rate_limit = 3000
smtpd_client_restrictions = permit_mynetworks,
permit_sasl_authenticated, reject
smtpd_error_sleep_time = 20
smtpd_etrn_restrictions = reject
smtpd_helo_required = yes
smtpd_helo_restrictions = reject_invalid_helo_hostname
smtpd_milters = unix:/run/clamav-milter/clamav-milter.socket
unix:/run/rate-limit/rate-limit.sock
smtpd_recipient_limit = 1
smtpd_recipient_restrictions = reject_non_fqdn_recipient,
reject_unknown_recipient_domain, permit
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sender_login_maps = ldap:/etc/postfix/ldap-loginmap.cf
smtpd_sender_restrictions = reject_non_fqdn_sender,
reject_unknown_sender_domain, reject_authenticated_sender_login_mismatch,
smtpd_tls_CAfile = /etc/postfix/certs/CA.crt
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/postfix/certs/.pem
smtpd_tls_key_file = /etc/postfix/certs/.privkey.pem
smtpd_tls_loglevel = 2
smtpd_tls_mandatory_ciphers = high
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:$data_directory/smtpd_scache
unknown_local_recipient_reject_code = 550
master.cf
submission inet n - n - - smtpd
pickup unix n - n 60 1 pickup
cleanupunix n - n - 0 cleanup
qmgr unix n - n 300 1 qmgr
tlsmgr unix - - n 1000? 1 tlsmgr
rewriteunix - - n - - trivial-rewrite
bounce unix - - n - 0 bounce
defer unix - - n - 0 bounce
trace unix - - n - 0 bounce
verify unix - - n - 1 verify
flush unix n - n 1000? 0 flush
proxymap unix - - n - - proxymap
proxywrite unix - - n - 1 proxymap
smtp unix - - n - - smtp
relay unix - - n - - smtp
showq unix n - n - - showq
error unix - - n - - error
retry unix - - n - - error
discardunix - - n - - discard
local unix - n n - - local
virtualunix - n n - - virtual
lmtp unix - - n - - lmtp
anvil unix - - n - 1 anvil
scache unix - - n - 1 scache
policyd_spf
Hello. Is there any way of having in the log the debugging info for the policyd_spf? I have been using for a test smtp -v in master.cf, but this is producing an enormous quantity of data, and policyd_spf -d in master.cf fails with errors. My target is to have a first impression after the installation, and then collect the policyd_spf answers to verify the efficieny of SPF for my sites (currently I see a lot of DONNO even for Google) Tnx Marco
Re: policyd_spf
Hello. Tnx, however I'm not using the python version but the compiled one, and there is nowhere a policyd-spd.conf file nor a man page. Marco Il 10. 05. 17 16:49, Dominic Raferd ha scritto: On 10 May 2017 at 15:27, marco <mailto:marco.brign...@marcobaldo.ch>> wrote: Is there any way of having in the log the debugging info for the policyd_spf? I have been using for a test smtp -v in master.cf <http://master.cf>, but this is producing an enormous quantity of data, and policyd_spf -d in master.cf <http://master.cf> fails with errors. My target is to have a first impression after the installation, and then collect the policyd_spf answers to verify the efficieny of SPF for my sites (currently I see a lot of DONNO even for Google) Look in man policyd-spf.conf LOGGING section.
Re: split up mail
Hello. I have been supporting for years no-profit organizations, that have been sending a number of mails to 1 and more recipients at the same time. After similar initial problems the solution never giving any major issue was *default_destination_concurrency_limit = 1* *default_destination_recipient_limit = 25 * Of course this slows down the delivery, however it is not a big problem unless all the recipients are handled by a restricted number of MX (and this is not usual) I'm now running less intensive mail servers, so maybe some tuning is need in this phase. Marco Il 19. 05. 17 13:39, Wietse Venema ha scritto: richard lucassen: Hello list, For a few reasons I use an outgoing postfix as smarthost. The source mailserver is an exchange. Before the postfix server was in use, sending mail to a bunch of recipients at a domain which is hosted by outlook.com was no problem. When the mail passes through postfix, mail to many recipients at a domain hosted by outlook.com is delayed and this is the message I see in the queue: -Queue ID- --Size-- Arrival Time -Sender/Recipient--- EA57C5F8D9 7094 Mon May 15 14:41:09 u...@example.com (host 358619467.mail.outlook.com[213.199.154.106] said: 452 4.5.3 Too many recipients (AS780090) [AM5EUR03FT055.eop-EUR03.prod.protection.outlook.com] (in reply to RCPT TO command)) Searching a bit I found this setting: smtp_destination_recipient_limit This defaults to 50. Is this the right parameter to adjust? Maybe. In the fight against spam, mail server operators are not exactly famous for providing accurate error messages. The SMTP standard says the server should accept 100 or more recipients in the same MAIL FROM transaction, and it specifies no limit on the number of MAIL FROM transactions in the same SMTP session. Mail operators on the other hand may do all kinds of arbitrary things. Working around this may involve a combination of Postfix rate_delay and other settings. Donate your eyeballs to your preferred search engine to find out what other people do. My domain is too small to provide meaningful experience in this respect. Wietse
Re: split up mail
Il 19. 05. 17 15:27, richard lucassen ha scritto: On Fri, 19 May 2017 07:39:37 -0400 (EDT) wie...@porcupine.org (Wietse Venema) wrote: Searching a bit I found this setting: smtp_destination_recipient_limit This defaults to 50. Is this the right parameter to adjust? Maybe. In the fight against spam, mail server operators are not exactly famous for providing accurate error messages. So if I understand the docs correctly, setting this parameter to e.g.default_destination_concurrency_limit = 1 25 has the following result: 1 message sent to 100 rcpt's -> postfix -> 4 messages to 25 rcpt's Note: 100 rcpt's at the same domain of course. Right or wrong? R. Correct, however 25 was a good number only if default_destination_concurrency_limit is set to 1, as i.e. if you have 2 you can have 2*25 recipients delivered in parallel and some servers have been not happy with this. Marco
Re: split up mail
My setup was default_destination_concurrency_limit = 1 default_destination_recipient_limit = 25 I never had major problems with this, it was only a little bit slow with gmail, yahoo and other big mail accounts providers, anyway never a real issue. This setup is probably not perfect if you have a lot of mail users, as one single mail with a lot of recipients will slow-down the delivery until all the "sub-deliveries" are handled for a specific server. Marco Il 19. 05. 17 16:02, richard lucassen ha scritto: On Fri, 19 May 2017 15:52:05 +0200 marco wrote: So if I understand the docs correctly, setting this parameter to e.g.default_destination_concurrency_limit = 1 25 has the following result: 1 message sent to 100 rcpt's -> postfix -> 4 messages to 25 rcpt's Note: 100 rcpt's at the same domain of course. Right or wrong? Correct, however 25 was a good number only if default_destination_concurrency_limit is set to 1, as i.e. if you have 2 you can have 2*25 recipients delivered in parallel and some servers have been not happy with this. Ah, that might be the issue then, when I leave these parameters set to their defaults, it would mean that the maximum Postfix will send at once is 20 mails containing 50 recipients? So, according to you I should add: smtp_destination_concurrency_limit = 1 to main.cf. R.
masquerade_domains map?
Hello Postfix users, while "masquerade_exceptions" supports "type:table" patterns, "masquerade_domains" supports only a static list of domain names in main.cf. http://www.postfix.org/ADDRESS_REWRITING_README.html#masquerade For me, it could be useful to manage also these domains in a file, mysql, tcp or ldap... It should be nice if a future release of Postfix could support "type:table" on "masquerade_domains". Thank you very much Marco
Re: masquerade_domains map?
On 15/06/2018 12:58 CEST, Wietse Venema wrote: [...] And here is an example from several other Postfix features: Specify a list of [things], "/file/name" or "type:table" patterns, separated by commas and/or whitespace. The list is matched left to right, and the search stops on the first match. A "/file/name" pattern is replaced by its contents; a "type:table" lookup table is matched when a name matches a lookup key (the lookup result is ignored). Con- tinue long lines by starting the next line with whitespace. Specify "!pattern" to exclude a name from the list. Would that work for you? Yes, of course. Many thanks for considering this. Marco
MAILER DAEMON email address question
Hello, I have configured postfix with local domains mydestination = ldap:/etc/postfix/ldap-localdomain.cf and to check local recipients: local_recipient_maps = ldap:/etc/postfix/ldap-localrecipient.cf smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination smtpd_recipient_restrictions = reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_unlisted_recipient, permit There are no aliases: alias_maps = hash:/etc/postfix/aliases alias_database = hash:/etc/postfix/aliases and "aliases" is an empty file. There are no canonical or masquerade domains. Postfix works as I like for all recipients: existing recipients are accepted and non existing recipients (no results in ldap-localrecipient.cf) are rejected. The only exception is the recipient "mailer-dae...@example.com", where let suppose example.com is a local domain. For instance: telnet mail.example.com 25 Trying 10.10.40.50... Connected to mail.example.com. Escape character is '^]'. 220 mail.example.com ESMTP MAIL Welcome ehlo example.com 250-mail.example.com 250-PIPELINING 250-SIZE 10485760 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN mail from: 250 2.1.0 Ok rcpt to: 250 2.1.5 Ok rcpt to: 550 5.1.1 : Recipient address rejected: User unknown in local recipient table quit # postmap -q mailer-dae...@example.com ldap:/etc/postfix/ldap-localrecipient.cf has no result, like dsfsd...@example.com. But mailer-dae...@example.com is accepted. Could you help me to understand why? It seems that the recipients "MAILER-DAEMON@" are always accepted. I would like to know if there is some specification to always accept these recipients, or if I made some mistakes in my conf. mail_version = 3.3.2 Thank you very much Marco
Re: MAILER DAEMON email address question
Il 03/04/2019 15:12, Matus UHLAR - fantomas ha scritto: does "such" mean null recipient here? does empty_address_recipient affect both the address in From: of bounces and address for which mail is always accepted? Do I have to alias MAILER-DAEMON (or what empty_address_recipient is set to) to direct mail to postmaster account? And if I don't, will I get double-bounce? Interesting! In my environment I verified that empty_address_recipient is not related to the MAILER-DAEMON recipient address behavior. The only always accepted recipient address still remains MAILER-DAEMON@, even if you change the empty_address_recipient. As you suggest, I think I have to define some transport for MAILER-DAEMON recipient address. Otherwise I get double-bounce. Warm Regards Marco
local_recipient_maps with LDAP
Hello Everybody I wan't to have my local recipeints checked against my Active Directory. So I have created the .cf file with the LDAP parameters: bind_dn = u...@domain.local bind_pw = ** server_host = 192.168.8.254 #Global Catalog port server_port = 3268 search_base = DC=domain, DC=local query_filter = proxyAddresses=*%s* and changed the main.cf file: local_recipient_maps = ldap:/etc/postfix/local_recipient_maps.cf unix:passwd.byname If i do this now: postmap -v -q 'u...@domain.ch' ldap:/etc/postfix/local_recipient_maps.cf It tells me "Search found 1 match(es)". But If i try to deliver a message with the same address postfix tells me "User not known in local recipient maps" How can i figure out whats wrong ? Thanks
AW: local_recipient_maps with LDAP
Ok... I changed some things now... Since this Mailsystem has the fqdn mx-rel.domain1.ch and therefore is set as mydestination, I have to make sure that messages to addresses to domain1.ch are found in the local_recipient_maps. Right ? /etc/postfix/main.cf Local_recipient_maps = ldap:/etc/postfix/local_recipient_maps.cf unix:passwd.byname /etc/postfix/local_recipient_maps.cf bind_dn = u...@domain.local bind_pw = ** server_host = 192.168.8.254 #Global Catalog port server_port = 3268 search_base = DC=domain, DC=local query_filter = proxyaddresses=...@domain1.ch* The other 2 domains are not local: /etc/postfix/main.cf Virtual_alias_domains = domain2.ch domain3.ch Virtual_alias_maps = ldap:/etc/postfix/virtual.cf /etc/postfix/virtual.cf bind_dn = u...@domain.local bind_pw = ** server_host = 192.168.8.254 #Global Catalog port server_port = 3268 search_base = DC=domain, DC=local query_filter = proxyAddresses=*%s* Is this right ?? Guess not, since it doesn't work :-/ -Ursprüngliche Nachricht- Von: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] Im Auftrag von Patrick Ben Koetter Gesendet: Samstag, 28. August 2010 18:25 An: Postfix Users Betreff: Re: local_recipient_maps with LDAP * Marco Rebsamen : > I see > If i got multiple domains, what do i do ? > Something like this ? > query_filter = (proxyaddresses...@%d) Only one domain can be your local domain. All other domains are virtual domains. Create two ldap query files. Local domain: query_filter = (proxyaddresses...@domain.local) Virtual domains: query_filter = (proxyAddresses=%s) > > -Ursprüngliche Nachricht- > Von: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] > Im Auftrag von Patrick Ben Koetter > Gesendet: Samstag, 28. August 2010 17:56 > An: postfix-users@postfix.org > Betreff: Re: local_recipient_maps with LDAP > > * Marco Rebsamen : > > I wan't to have my local recipeints checked against my Active Directory. > > So I have created the .cf file with the LDAP parameters: > > > > bind_dn = u...@domain.local > > bind_pw = ** > > server_host = 192.168.8.254 > > #Global Catalog port > > server_port = 3268 > > search_base = DC=domain, DC=local > > query_filter = proxyAddresses=*%s* > > > > and changed the main.cf file: > > > > local_recipient_maps = ldap:/etc/postfix/local_recipient_maps.cf > > unix:passwd.byname > > > > If i do this now: > > postmap -v -q 'u...@domain.ch' ldap:/etc/postfix/local_recipient_maps.cf > > > > It tells me "Search found 1 match(es)". But If i try to deliver a > > message with the same address postfix tells me "User not known in local > > recipient maps" > > > > How can i figure out whats wrong ? > > %s is replaced by the input key, but you need to search for %u somewhat like > %this: > > query_filter = (proxyaddresses...@domain.local) > > Why? In context of local recipient maps the domain part is already known to > Postfix and it doesn't search for it. With local_recipient_maps Postfix only > looks for the localpart of an email address. > > p...@rick > > > -- > All technical questions asked privately will be automatically answered on the > list and archived for public access unless privacy is explicitely required and > justified. > > saslfinger (debugging SMTP AUTH): > <http://postfix.state-of-mind.de/patrick.koetter/saslfinger/> -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563
AW: local_recipient_maps with LDAP
Ok, I'm really confused about that LDAP lookup stuff :-/ What I want to do is to check if an address to which a message is addressed really exists. I'm currently using this script for local receipient checks: bind_dn = j...@hive.loc bind_pw = server_host = 192.168.8.254 #Global Catalog port server_port = 3268 search_base = DC=hive, DC=loc query_filter = proxyAddresses=smtp:*...@unimatrix0.ch result_attribute = proxyAddresses the result is the complete list of all addresses a user has. But I'm not sure if this is right. I delivered a test message by hand through telnet and somehow it got delivered to any address in the result even in the system. So I guess I really missed something... :-/ -Ursprüngliche Nachricht- Von: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] Im Auftrag von Victor Duchovni Gesendet: Montag, 30. August 2010 17:17 An: postfix-users@postfix.org Betreff: Re: local_recipient_maps with LDAP On Mon, Aug 30, 2010 at 04:58:48PM +0200, Patrick Ben Koetter wrote: > * Victor Duchovni : > > > Is "smtp:%s" sufficient? IIRC the main mail address is noted as > > > "SMTP:%s". A > > > query that catches those too would be this: > > > > The proxyAddresses field is matched case-insensitively. No fancy gymnastics > > required: > > > > > query_filter = (|(proxyAddresses=smtp:%s)(proxyAddresses=SMTP:%s)) > > > > The first string matches both. > > Case-insensitive because the matching rule for proxyAddresses is > case-insensitive? Yes, naturally. The case of the "smtp" prefix only matters when it is used as a result value, not when it is a lookup key. -- Viktor.
AW: local_recipient_maps with LDAP
-Ursprüngliche Nachricht- Von: Victor Duchovni [mailto:victor.ducho...@morganstanley.com] Gesendet: Montag, 30. August 2010 21:18 An: Marco Rebsamen Cc: postfix-users@postfix.org Betreff: Re: local_recipient_maps with LDAP On Mon, Aug 30, 2010 at 08:50:33PM +0200, Marco Rebsamen wrote: > > Ok, I'm really confused about that LDAP lookup stuff :-/ > What I want to do is to check if an address to which a message is addressed > really exists. > > I'm currently using this script for local receipient checks: > > bind_dn = j...@hive.loc > bind_pw = > server_host = 192.168.8.254 > > #Global Catalog port > server_port = 3268 > > search_base = DC=hive, DC=loc > query_filter = proxyAddresses=smtp:*...@unimatrix0.ch > result_attribute = proxyAddresses What is that pesky "*" doing in your query filter!!! It's a damn wildcard! I thought I would need it because when I tried to find the right parameters for this LDAP request I could not find find anything until I used this star! Why is "proxyAddresses" the right result attribute. I would use "mail". I don't know ?! Is it not ?! from where should I know that ?! Why do I need an email address as return anyway ?! I would say the address is already written in the message ? It makes no sense to me to return an email address maybe I just don't understand the whole thing and someone should tell me what I should do?! Report problems accurately with supporting "postconf -n" output, table definitions AND logs! ...same as above -- Viktor.
AW: local_recipient_maps with LDAP
Ok I removed that * now from the request an used "mail" as result_attribute. This works now for the local domain but not for the others. I added all the non-local domains to the parameter virtual_alias_domains and set virtual_alias_maps to ldap:/etc/postfix/virtual.cf I tested it with postmap -q nad it worked. But if I send a message to that domain I get the message back: User unknown in virtual alias table As you wished... Postconf -n: alias_maps = hash:/etc/aliases biff = no canonical_maps = hash:/etc/postfix/canonical command_directory = /usr/sbin config_directory = /etc/postfix content_filter = daemon_directory = /usr/lib/postfix data_directory = /var/lib/postfix debug_peer_level = 2 debug_peer_list = 192.168.8.111 defer_transports = delay_warning_time = 1h disable_dns_lookups = no disable_mime_output_conversion = no header_checks = regexp:/etc/postfix/header_checks html_directory = /usr/share/doc/packages/postfix-doc/html inet_protocols = all local_recipient_maps = ldap:/etc/postfix/local_recipient_maps.cf unix:passwd.byname mail_owner = postfix mail_spool_directory = /var/mail mailbox_command = mailbox_size_limit = 0 mailbox_transport = cyrus mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man masquerade_classes = envelope_sender, header_sender, header_recipient masquerade_domains = masquerade_exceptions = root message_size_limit = 0 message_strip_characters = \0 mydestination = $myhostname, localhost, $mydomain myhostname = mx-rel.unimatrix0.ch mynetworks = 192.168.8.0/24, 127.0.0.0/8 newaliases_path = /usr/bin/newaliases queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/packages/postfix-doc/README_FILES relay_domains = $mydestination, hash:/etc/postfix/relay relayhost = smtp.hispeed.ch relocated_maps = hash:/etc/postfix/relocated sample_directory = /usr/share/doc/packages/postfix-doc/samples sender_canonical_maps = hash:/etc/postfix/sender_canonical sendmail_path = /usr/sbin/sendmail setgid_group = maildrop smtp_enforce_tls = no smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_tls_session_cache_database = btree:/var/lib/postfix/smtpd_tls_session_cache smtp_tls_session_cache_timeout = 3600s smtp_use_tls = yes smtpd_client_restrictions = smtpd_helo_required = no smtpd_helo_restrictions = smtpd_recipient_restrictions = permit_mynetworks,reject_unauth_destination smtpd_sasl_auth_enable = no smtpd_sender_restrictions = hash:/etc/postfix/access smtpd_use_tls = no strict_8bitmime = no strict_rfc821_envelopes = no transport_maps = hash:/etc/postfix/transport unknown_local_recipient_reject_code = 550 virtual_alias_domains = sinus-elektro.ch spinsch.ch virtual_alias_maps = ldap:/etc/postfix/virtual.cf And the content of virtual.cf bind_dn = j...@hive.loc bind_pw = * server_host = 192.168.8.254 #Global Catalog port server_port = 3268 search_base = DC=hive, DC=loc query_filter = proxyAddresses=smtp:%s result_attribute = mail -Ursprüngliche Nachricht- Von: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] Im Auftrag von Victor Duchovni Gesendet: Montag, 30. August 2010 21:54 An: postfix-users@postfix.org Betreff: Re: local_recipient_maps with LDAP On Mon, Aug 30, 2010 at 09:46:26PM +0200, Marco Rebsamen wrote: > > > search_base = DC=hive, DC=loc > > > query_filter = proxyAddresses=smtp:*...@unimatrix0.ch > > > result_attribute = proxyAddresses > > > > What is that pesky "*" doing in your query filter!!! > > It's a damn wildcard! I thought I would need it because when I tried > to find the right parameters for this LDAP request I could not find find > anything until I used this star! Get rid of it. With the "smtp:" prefix properly set to match the actual data in Microsoft's AD, you no longer need the "*" and using it lowers performance and creates backscatter when you accept invalid names that are prefixes of valid names. > > Why is "proxyAddresses" the right result attribute. I would use "mail". > > I don't know ?! Is it not ?! from where should I know that ?! By understanding what you are doing... :-( > Why do I need an email address as return anyway ?! You need some non-empty attribute as a result, ideally a single-valued one that keeps the result-set small. Using "mail" makes sense. -- Viktor.
AW: local_recipient_maps with LDAP
>> I added all the non-local domains to the parameter virtual_alias_domains >> and set virtual_alias_maps to ldap:/etc/postfix/virtual.cf > Do you understand what virtua alias domains are for? I thought I would... >> I tested it with postmap -q and it worked. > What does "worked" mean? I got the same address back as I searched for... >> But if I send a message to that domain I get the message back: >> User unknown in virtual alias table > > That means that the recipient address did NOT get rewritten into > a real (not virtual alias) domain. > >> message_size_limit = 0 > Generally unwise. > >> mydestination = $myhostname, localhost, $mydomain >> myhostname = mx-rel.unimatrix0.ch >> relay_domains = $mydestination, hash:/etc/postfix/relay >> relayhost = smtp.hispeed.ch > > >> sender_canonical_maps = hash:/etc/postfix/sender_canonical > Generally unwise to use sender_canonical_maps. Use smtp_generic_maps > instead to rewrite outbound email. > >> smtp_enforce_tls = no > Obsolete. > >> smtp_use_tls = yes >> smtpd_use_tls = no > Obsolete, use > smtp_tls_security_level = may > smtpd_tls_security_level = none Well... I thought that the guys from opensuse did a good job with the out of the box settings. Obviously they didn't... >> transport_maps = hash:/etc/postfix/transport >> virtual_alias_domains = sinus-elektro.ch spinsch.ch >> virtual_alias_maps = ldap:/etc/postfix/virtual.cf > > These domains can't host real recipients, all recipients > must be rewritten to a real domain. > > And the content of virtual.cf > > search_base = DC=hive, DC=loc > query_filter = proxyAddresses=smtp:%s > result_attribute = mail > > Probably "mail" is the original address in most cases. Where is > such mail routed? If to another server, these are "relay" domains, > not virtual alias domains, unless you rewrite the address in transit... The Messages should be forwarded to the MS Exchange Server from which I request the LDAP information. I had this working on an older system. What I did there was, adding the domains "sinus-elektro.ch" and "spinsch.ch" to "relay_domains" and then I had a perl-script which updated the "local_receipient_maps" table. If I now add these domains to relay_domains, postfix just delivers every message to one of these domains to the exchange without checking if the address realy exists... > -- > Viktor.
AW: local_recipient_maps with LDAP
Hm, looks like some things changed since I set up the last system. I mean why did it work before ? I guess i buy the newest version of Peer Heinlein's book :-P Anyway, it works now the way I wanted it. Thank you for your patience. -Ursprüngliche Nachricht- Von: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] Im Auftrag von Victor Duchovni Gesendet: Dienstag, 31. August 2010 21:29 An: postfix-users@postfix.org Betreff: Re: local_recipient_maps with LDAP On Tue, Aug 31, 2010 at 08:07:52PM +0200, Marco Rebsamen wrote: > > Probably "mail" is the original address in most cases. Where is > > such mail routed? If to another server, these are "relay" domains, > > not virtual alias domains, unless you rewrite the address in transit... > > The Messages should be forwarded to the MS Exchange Server from which I > request the LDAP information. Then these are relay domains not virtual alias domains, unless you rewrite the address to an internal domain specific to Exchange in transit. > I had this working on an older system. What I did there was, adding the > domains "sinus-elektro.ch" and "spinsch.ch" to "relay_domains" Which was the right thing to do. > and then I had a perl-script which updated the "local_receipient_maps" > table. Which is the wrong thing to do, since for relay domains, the validation table is "relay_recipient_maps" not "local_recipient_maps". You can use LDAP and skip the need to generate flat file tables, unless you want to protect AD from the query load... > If I now add these domains to relay_domains, postfix just > delivers > every message to one of these domains to the exchange without checking > if the address realy exists... Because you are not setting relay_recipient_maps. http://www.postfix.org/ADDRESS_CLASS_README.html -- Viktor.
sender check
I have a barracuda server that receives mails, filter them and forward to a linux system running postfix. Both machine have a public IP (static). The linux system is configured to be used as SMTP for sasl authenticated users as well, besides to be used as SMTP for the people on $mynetworks (permit_mynetworks in the smtpd_recipient_restrictions). Unfortunatley, some spammers, have found it and use to spam local recipients using the linux machine, avoiding so to be filtered through the barracuda system. I'm wondering if there is a way to allow OLNY local users or users belonging to the domains hosted by the linux server to use SMTP. Thanks MG
Re: sender check
* Wietse Venema [2009-11-26 12:20:19 -0500]: > Marco Giardini: > > I have a barracuda server that receives mails, filter them and forward to a > > linux system running postfix. > > > > Both machine have a public IP (static). > > > > The linux system is configured to be used as SMTP for sasl authenticated > > users as well, besides to be used as SMTP for the people on $mynetworks > > (permit_mynetworks in the smtpd_recipient_restrictions). > > > > Unfortunatley, some spammers, have found it and use to spam local recipients > > using the linux machine, avoiding so to be filtered through the barracuda > > system. > > > > I'm wondering if there is a way to allow OLNY local users or users belonging > > to the domains hosted by the linux server to use SMTP. > > To permit only local systems (incl. barracuda box), or users that > have a relationship with your server: > > smtpd_recipient_restrictions = > permit_mynetworks permit_sasl_authenticated reject > > Wietse i do use: smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination but it seems from the log that spammer still send me and to other local users spam mails. Humm...strange mg
virtual vacation with mysql
Hi, I'm trying to configure virtual vacation on my server. In documentation I see which I do insert similary value in transport vacation:[autoreply.mydomain.com] What is the autoreply.mydomain.com? It's same of mx record? Thank you
virtual vacation
Hi,
I have configured virtual vacation like this:
In master.cf:
--
vacationunix - n n - - pipe
flags=Rq user=vacation argv=/var/spool/postfix/vacation/vacation.pl -f
${sender} -- ${recipient}
--
In main.cf:
--
transport_maps = mysql:/etc/postfix/mysql_transport.cf
--
File mysql_transport.cf:
--
user = postfix
password = postfix
dbname = postfix
table = domain
select_field = transport
where_field = domain
additional_conditions = and active=1
--
In mysql table domain
--
domain=test.it
trasport=vacation:[autoreply.test.it]
active=1
--
config postfixadmin:
--
$CONF['vacation'] = 'YES';
$CONF['vacation_domain'] = 'autoreply.test.it';
--
When I add a vacation message (from postfixadmin for mailbox a...@test.it) it
insert in alias table this record:
--
address=a...@test.it
goto=a#test...@autoreply.test.it
domain=test.it
--
and in table vacation this record
--
email=a...@test.it
subject=reply test
body=reply test
domain=test.it
--
When I send one email from send@sender to a...@test.it postfix report "loops
back to myself" :
--
amavis[20123]: (20123-19) Passed CLEAN, [] ->
, queued_as: ED259280D9C, 102 ms
postfix/smtp[27733]: C92D8280CF1: to=,
orig_to=, relay=127.0.0.1[127.0.0.1]:10024, status=sent (250
2.0.0 from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as ED259280D9C)
postfix/pipe[27738]: ED259280D9C: to=,
relay=spamassassin,status=sent (delivered via spamassassin service)
postfix/smtp[28751]: 28378280EBB: to=, relay=none,
status=bounced (mail for autoreply.test.it loops back to myself)
--
Anyone can help me?
mail transport unavailable for email in the queue
Greetings. I just moved to Centos 6 a postfix/dovecot email server previously (left for a long time, alas...) on Centos 4. Right now: the dkim configuration on the old server was not working with the new versions of postfix etc.. So I temporarily disabled it (commented out all relevant lines in master.cf) email from the outside is received correctly, and delivered to the right maildirs outgoing email sent via webmail (with roundcube in case it matters) is delivered but if I try to flush the queue after restarting postfix I get one error like this (even if dkim is now disabled): postfix/qmgr[3601]: warning: connect to transport private/dksign: Connection refused and many errors like this, all from, AFAICT, messages in the queue: postfix/error[3640]: D7C00A4E96D: to=, relay=none, delay=144677, delays=144677/0.01/0/0.14, dsn=4.3.0, status=deferred (mail transport unavailable) The relevant lines of master.cf, and the output of postconf -n are below. Any help to figure out what happened/is still happening and fix it is very welcome, thanks. Marco [root@newvps postfix]# grep smtp master.cf | grep -v '^#' smtp inet n - n - - smtpd submission inet n - n - - smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject smtps inet n - n - - smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject smtp unix - - n - - smtp relay unix - - n - - smtp POSTCONF -N alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix debug_peer_level = 2 disable_vrfy_command = yes html_directory = /usr/share/doc/postfix-2.4.3-documentation/html inet_interfaces = all mail_owner = postfix mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man mydestination = $myhostname, localhost mydomain = $myhostname myhostname = a.mx.example.com mynetworks = 127.0.0.0/8, ip.1, ip.2 (THESE ARE FIXED IPS OF TWO MACHINES THAT USE THIS ONE AS THEIR RELAY) myorigin = $mydomain newaliases_path = /usr/bin/newaliases.postfix queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.4.3-documentation/readme relay_domains = relayhost = sample_directory = /etc/postfix sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtpd_helo_required = yes smtpd_helo_restrictions = smtpd_recipient_restrictions = reject_invalid_hostname, reject_non_fqdn_hostname,reject_non_fqdn_sender, reject_non_fqdn_recipient,reject_unknown_sender_domain, reject_unknown_recipient_domain, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination,check_helo_access hash:/etc/postfix/reject_own_helo smtpd_sasl_auth_enable = yes smtpd_sasl_path = /var/spool/postfix/private/auth smtpd_sasl_type = dovecot smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/myssl/mycert.pem smtpd_tls_key_file = /etc/myssl/mycert.pem smtpd_tls_loglevel = 1 smtpd_tls_security_level = may strict_rfc821_envelopes = yes unknown_address_reject_code = 554 unknown_client_reject_code = 554 unknown_hostname_reject_code = 554 unknown_local_recipient_reject_code = 550 virtual_alias_maps = hash:/etc/postfix/mymaps/valias.map virtual_gid_maps = static:5000 virtual_mailbox_base = /var/mail/mymail_storage virtual_mailbox_domains = /etc/postfix/mymaps/vhosts.map virtual_mailbox_maps = hash:/etc/postfix/mymaps/vmailboxes.map virtual_transport = procmail virtual_uid_maps = static:5000
Re: mail transport unavailable for email in the queue
in addition to what I just wrote, I realized only in this instant that an email from one of two IPs in mynetworks: mynetworks = 127.0.0.0/8, ip.1, ip.2 (THESE ARE FIXED IPS OF TWO is rejected with this message in the log: master.cf.orig:smtp inet n - n - - smtpd Jul 28 10:35:24 newvps postfix/smtpd[3800]: NOQUEUE: reject: RCPT from...[ip.2]: 554 5.7.1 <[ip.2]>: Client host rejected: Access denied; from= to= proto=ESMTP helo=
Re: mail transport unavailable for email in the queue
> And, you configured the dksign service as a content filter? In that case "postsuper -r ALL" (or postsuper -r queue_id). Yes and no. the old (centos 4 +postfix 2.whatever it was) **had** dksign configured in that way. Then I got this brand new cento6 server with postfix 2.6.6. While configuring it, I did a mistake: I ran it for an hour or so with the **old** master.cf file, and without dksign. So messages were not relayed because not signed. Then I figured out the mistake and fixed (I think) the master.cf. But the message previously stuck in the queue remained there until this sugggetion of yours. "postsuper -r ALL" worked fine, thanks. So the issue was that those messages had been stucked in a particolar queue that ONLY postsuper can flush, did I get this right? OK. So this seems settled, thanks again. Of course, any comment on the postconf -n output I posted at the beginning of the thread, to improve the setup, is still very welcome, if anybody feels like it! Marco
Rewrite from based on source IP address
Hi everybody, I posted on r/postfix but it seems not to be so active any longer :-( I know this might sound as a quite complicated question but here you go: I need to setup a mail gateway to allow a certain amount of hosts in a LAN to send out mails and still pass SPF/DKIM/DMARC checks. Also, not all hosts in the LAN will be authorized to send mails and I want to keep some sort of traceability for the end user. My idea is to control who is authorized via `mynetworks` and up to here is all fine. The second thing I want to do is rewrite the from address based on the source ip, e.g. 10.1.1.1 -> FROM: j...@test.co.uk 10.1.1.2 -> FROM: m...@test.co.uk I saw many things going around filters and the check_client_access but I didn't get if it's possible or not. Appreciate any help! Thank you :-) All the best, Marco
VERP logging
Hi all, I have successfully configured VERP to work with my Postfix instance. I see the logs and I effectively see [truncated] /smtpd[999]: unknown[x.x.x.x]: replacing command "MAIL FROM:" with "MAIL FROM: XVERP" I know it worked also because I can indeed see, on the receiving side, the VERP-ed address in the return-path field. My issue is that in the log lines following "XVERP" I can only see the original MAIL FROM address... My question is about whether there is a way to log the VERP-ed MAIL FROM, so to be sure about which translation happened. Thank you very much in advance Marco
Re: VERP logging
Hello Wietse, On Tue, Apr 20, 2021 at 5:48 PM Wietse Venema wrote: > Marco Pizzoli: > > Hi all, > > I have successfully configured VERP to work with my Postfix instance. > > > > I see the logs and I effectively see > > [truncated] /smtpd[999]: unknown[x.x.x.x]: replacing command "MAIL > > FROM:" with "MAIL FROM: XVERP" > > > > I know it worked also because I can indeed see, on the receiving side, > the > > VERP-ed address in the return-path field. > > Indeed. With VERP, every Postfix delivery agent generates a > per-recipient envelope sender address. > > > My issue is that in the log lines following "XVERP" I can only see the > > original MAIL FROM address... > > The delivery agent does not log the sender address. > > The Postfix queue manager logs the sender address, but it is not > practical to log every VERPed address, because there could be > thousands of them. > > The queue manager could be updated to log that VERP was turned on. > Would that help? > > postfix/qmgr[12345]: 987654321: from=, > size=12345, nrcpt=543 verp=+= (queue active) > This would really be a useful addition. Thanks for considering it > > Wietse > Marco
Re: Specific DNS server
Hello, +1 for this Request for Improvement. I also faced this need. Changing the machine solver was, unfortunately, not an option. Thanks Marco On Thu, Apr 22, 2021 at 12:21 PM Simon Wilson wrote: > Is there a way to make Postfix/postscreen use a specific DNS server? > > Reason for the question: > My network has an internal (non-ISP forwarding) DNS server for both > internal and external resolution, and that is default nameserver > across the network including for the mail server. That DNS server > includes a broad set of applied RPZ restrictions (which remove the > vast majority of ads and trackers - a very popular addition). The RPZ > zone has though on very rare occasions resulted in Postfix getting > SERVFAIL and rejecting domains (reject_unknown_sender_domain), which > could be classed as false positives - not for critical emails, but > occasionally for retail mail-outs etc. > > I provide a fully "clean and complete" DNS for spamassassin DNSBL > lookups by running a recursive caching nameserver on-localhost (SA has > an defined option to specify a DNS server). As noted above the mail > server as a whole does not use this - it uses the network-wide local > nameserver, ensuring that it can resolve local As CNAMEs etc as needed. > > Note: I realise one option is that I could probably add local domain > resolution to the localhost nameserver and use it as the default for > the mail server... but my first question is whether postfix has or > could have ability to have a specific nameserver (as Spamassassin > does), or if this would be a Bad Idea (TM) for reasons unknown to me. > > Simon. > > -- > Simon Wilson > M: 0400 12 11 16 > >
Re: Specific DNS server
On Thu, Apr 22, 2021 at 4:37 PM Benny Pedersen wrote: > On 2021-04-22 12:58, Marco Pizzoli wrote: > > Hello, > > +1 for this Request for Improvement. > > I also faced this need. > > > > Changing the machine solver was, unfortunately, not an option. > > we all love 127.0.0.1 > > solution is to not have spamasassin running on same host as postfix, or > tell spamassassin to use external trusted nameserver where rpz zones can > live safely > > if rpz affact postfix its not a postfix isssue to fix > > hopefully people messing with dns do know how dns works > I am afraid you did not get my point. I needed to have Postfix to solve Internet DNS names, for obvious reasons. At the same time, I needed to be able to solve Intranet DNS names: monitoring server, backup server, etc... Due also to some other constraints, I ended up relying on static entries in /etc/hosts. It was at that time my best bad option.
Re: Specific DNS server
On Thu, Apr 22, 2021 at 5:21 PM Benny Pedersen wrote: > On 2021-04-22 16:44, Marco Pizzoli wrote: > > > I am afraid you did not get my point. > > i dont know your solution then > > rpz and qname can be problematic > > https://labs.ripe.net/author/wouter_de_vries/making-the-dns-more-private-with-qname-minimisation/ > > > I needed to have Postfix to solve Internet DNS names, for obvious > > reasons. > > bind9 can have split dns views > > > At the same time, I needed to be able to solve Intranet DNS names: > > monitoring server, backup server, etc... > > dns split views is your frind there > > > Due also to some other constraints, I ended up relying on static > > entries in /etc/hosts. > > this file is only for when real dns server is down, not used when dns > server is up > > > It was at that time my best bad option. > > if you like more help please post more info on the real problem > I appreciate your effort to help, really, but we would probably go off-topic here. I just can add that the environment in which I was working had the original sin to use the same "internet" dns domain for both internet and intranet names. So a simple forwarder dns was not sufficient. We would end up creating N forward-zones, one for every server. The /etc/hosts solution was the short-term solution for just the Postfix setup. Months later we mitigated the corporate issue by making use of static rpz-zones, via BIND. I am aware of DNS views, but my understanding of them is to create a separate view of the DNS world based on the client submitting the request... So how would I discriminate a request coming from Postfix in comparison to another coming from my backup agent? Both of them are exiting from the same network-interface of the same server, via the same IP address. Isn'it?
email duplicates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I do have a combination of postfix and mailman and use postfix as a relayhost. I get all the mails for mailman via fetchmail. The whole system is Debian 8 with its packages for postfix (2.11.3-1) and mailman (2.1.18-2). Now to the problem: Since several months emails sometimes are duplicated (recipients got them twice ore more) when they were sent to the members of the mailing lists. The problem does occur, after mailman has handled the incoming mail and has handed it over to postfix. The problem is somehow sporadicly and I didn't find a solution so far. Does anyone have suggestion where I should dig deaper? This is the output form postconf -n: alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases append_dot_mydomain = no biff = no config_directory = /etc/postfix inet_interfaces = all inet_protocols = all mailbox_command = procmail -a "$EXTENSION" mailbox_size_limit = 0 message_size_limit = 5120 mydestination = hostname.local, localhost.local, localhost myhostname = hostname.local mynetworks = 127.0.0.0/8 [::1]/128 myorigin = /etc/mailname readme_directory = no recipient_delimiter = relayhost = [smtp.myhost.de] smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl/sasl_passwd smtp_sasl_security_options = noanonymous smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) What information should I provide here further? BR Marco -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWJrECAAoJEC1y3OsA+e10WWoP/RBpg/MXno/INZU1mYi6inFc dQH1PDute8fLQNnwgqOoNv0+RABzyt6HwINF0Sm3elIk6o2JRBiR8xO2CohM4Drm Bo4dEw9qI4Vd56h9cKvFya9k38BBY/ZP33xR6SNY3DzaPUPoCqqieSsw/uJPGlKP Kr6g5N54wDgxsFJfCDESrx28EO8MyfFZnKmxcnJ8qlo2YMFWTMHzRISI5hOloxyq HZyMl8N6jQLDIX0+WyMHbLoXXhYvhQ8FdJ+TUhORMs9ApxXC3U1bbLelhrNSTj2e 8fexa5lOo+TNhLiZfDgDoNY4f75SFbDhPLUE9cl72WtbItC8ecNULZtQcGHi/EZa vxdK4o3HrH3SRW66mhLRwFu4Mdb1zKn9gRjFs8ZUoW/JWzQFwOMGkb5aK0tcfnR5 Kg9/7i7Z6WR+x/6n3HbFpYQ5kAhOg6xG8vgxSDug6qvfKaOXB2gGrk7EpaEofNY4 L+EKLVkgEjishpdmnDniCvzeHCwPV+Mu3w6jYzZwown+GRfUcB2kMOsGnAkQEvvX SYu1+wEGJnrWWEYUx85Dx9afJ/MLyKLzJCYyWv5nrBsukTUmwXm701fYxrZsnOIh /QPB4mjE6NT7IxE6GPWet6bLIt6dwC3D2nhJpllI9dn48FGDI4Br4o9hMiguLUJP cp4Uk7cb3Y++wfhG6A+j =4S0O -END PGP SIGNATURE-
Re: email duplicates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/20/2015 11:31 PM, k...@rice.edu wrote: > Hi Marco, > > What do your postfix logs say for one of the duplicated > deliveries? I've attached the piece of the mail.info where the duplicate occurs > When I have seen duplicate deliveries in the past, they were > caused by connection problems that prevented the final SMTP > handshake from being completed, which would acknowledge the receipt > of the message. Then postfix dutifully and correctly resent the > message. > > Regards, Ken > > On Tue, Oct 20, 2015 at 11:24:18PM +0200, Marco Stoecker wrote: > Hi, > > I do have a combination of postfix and mailman and use postfix as > a relayhost. I get all the mails for mailman via fetchmail. The > whole system is Debian 8 with its packages for postfix (2.11.3-1) > and mailman (2.1.18-2). > > Now to the problem: Since several months emails sometimes are > duplicated (recipients got them twice ore more) when they were sent > to the members of the mailing lists. The problem does occur, after > mailman has handled the incoming mail and has handed it over to > postfix. The problem is somehow sporadicly and I didn't find a > solution so far. > > Does anyone have suggestion where I should dig deaper? > > This is the output form postconf -n: > > alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases > append_dot_mydomain = no biff = no config_directory = /etc/postfix > inet_interfaces = all inet_protocols = all mailbox_command = > procmail -a "$EXTENSION" mailbox_size_limit = 0 message_size_limit > = 5120 mydestination = hostname.local, localhost.local, > localhost myhostname = hostname.local mynetworks = 127.0.0.0/8 > [::1]/128 myorigin = /etc/mailname readme_directory = no > recipient_delimiter = relayhost = [smtp.myhost.de] > smtp_sasl_auth_enable = yes smtp_sasl_password_maps = > hash:/etc/postfix/sasl/sasl_passwd smtp_sasl_security_options = > noanonymous smtpd_banner = $myhostname ESMTP $mail_name > (Debian/GNU) > > What information should I provide here further? > > BR Marco > > >> -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWJsaeAAoJEC1y3OsA+e10irQP/Awm0OwtD2XXz9ybvVqrNd+4 2X1VZDbt6aoQC5x9ZVRKgqzrktbYE/gxlEk/HtzHJSGqL+c3neaiCYmZ8r0VkwLh Q5ALOqj+i0LF/TOdVWYO/6Ty6tGRwYIGyg4rssEHz48j8rElW4LAr0FFYTO2tBht yzRBm5d45IjgPiJk1CNeX0RipB6eoiqgkgWIP0uOIz6a/ToQmJ1EFItZhhdh6//h A+nTc/AnfXjJi7wvM3uUS0vPZBpR+4U5Wugh0gLsFAWWFMNaWVoG9tnxHAWgNkv7 OKnCSjXa+AYo1QHwI2W+NNcViEuzoDvszyfSJb/JN1CZt0/uF/621sAO8f03Jpyd Gnh35+gSeGhKmgahjdjd9ACxO28ECDHEh4pCcGbrz2vYQY0WKSS2Qu2ta29/z/9v RF7wv3uieG5uuf848X7GrIXRtj8LH3c+rUXa23ZrEkRzx/tnTAjeOsJAgH3zPzhH tRJoTB4WnGlRFsRmnxPznJRtER1Gl9ayEpG6LLvl0tqSoK1Q+uWWeAfQ8hcamb/H udFhgUJCXqBWjnO3v+lwUHGOdfS6R9qP38QhFppRtEKaxnO3xRCOZvJMCBUufmDm ZHYh9fIiWR9k4gJjyL2DsxJyRiFTCF9uVhty1fpCQE8EJ96jQ+/XLpQoknfRkK2+ 85H7FcAPRp3hvYw9bohI =TbKL -END PGP SIGNATURE- mail.info Description: application/info
Re: email duplicates
On 10/20/2015 11:31 PM, wie...@porcupine.org wrote: Marco Stoecker: -- Start of PGP signed section. Hi, I do have a combination of postfix and mailman and use postfix as a relayhost. I get all the mails for mailman via fetchmail. The whole system is Debian 8 with its packages for postfix (2.11.3-1) and mailman (2.1.18-2). Now to the problem: Since several months emails sometimes are duplicated (recipients got them twice ore more) when they were sent to the members of the mailing lists. The problem does occur, after mailman has handled the incoming mail and has handed it over to postfix. The problem is somehow sporadicly and I didn't find a solution so far. How does mailman submit mail into Postfix? Perhaps the submission fails (times out) and mailman sends again, resulting in duplicates. All the evidence that you need is logged by Postfix and mailman: track down a duplicate delivery back to the source and look for delivery errors. Will do a double-check of all the logfiles again. Maybe I have overseen something. As I'm not the 'expert' in those things, I'd like to come back with questions ;) Any suggestions what are the most important postfix logfiles I should have a look into? I did look into mail.info and mail.log while mail.err does not show anything when the duplicates occur. Wietse This is the output form postconf -n: I provide here further? BR Marco -- End of PGP signed section, PGP failed!
Re: email duplicates
On 10/21/2015 12:51 PM, Wietse Venema wrote: > Marco Stoecker: >>> All the evidence that you need is logged by Postfix and mailman: >>> track down a duplicate delivery back to the source and look for >>> delivery errors. >> >> Will do a double-check of all the logfiles again. Maybe I have overseen >> something. As I'm not the 'expert' in those things, I'd like to come >> back with questions ;) >> Any suggestions what are the most important postfix logfiles I should >> have a look into? > > Turn off verbose logging (no "-v" daemon options in master.cf). > > You need to find the records where the same message is delivered > more than once to the same recipient, then look for all the records > with the same Postfix QUEUE ID. That will show if the duplication > happened BEFORE Postfix or INSIDE Postfix.S It may not matter for > the recipient, but it matters for the solution. Here is an entry beginning where an email was sent 5 times Oct 22 10:40:10 hostname postfix/local[4909]: BF9AD1C94: to=... Is BF9AD1C94 the Postfix QUEUE ID? If so, than each mail that was sent 5 times have 5 different QUEUE ID's. Is that an indicator that the duplication happend earlier (maybe by mailman?) in the chain? Thx Marco > > Wietse >
Re: email duplicates
On 10/23/2015 01:26 AM, Wietse Venema wrote: > Marco Stoecker: >>> You need to find the records where the same message is delivered >>> more than once to the same recipient, then look for all the records >>> with the same Postfix QUEUE ID. That will show if the duplication >>> happened BEFORE Postfix or INSIDE Postfix.S It may not matter for >>> the recipient, but it matters for the solution. >> >> Here is an entry beginning where an email was sent 5 times >> >> Oct 22 10:40:10 hostname postfix/local[4909]: BF9AD1C94: to=... >> >> Is BF9AD1C94 the Postfix QUEUE ID? > > Yes. > >> If so, than each mail that was sent 5 times have 5 different QUEUE ID's. > > Then Postfix received 5 different messages. > >> Is that an indicator that the duplication happend earlier (maybe by >> mailman?) in the chain? > > You need to search for the logfile records where these 5 messages > were received. Usually that will be smtpd records for SMTP mail, > or pickup records for mail received with /usr/sbin/sendmail. > > Wietse > So I got new information, because I also posted in the related mailman list. Here is the log, where postfix got the original message (which was sent to 5 mailing lists) and handed over to mailman (which is done 5 times with different postfix ID's). So mailman got 5 times a message to 5 lists, so each member got 5 times the same message. I'm just curious about the message-id=<008b01d10ca4$eb5fd0b0$c21f7210$@de>, this is always the same, but the postfix ID differ. Any glue? Oct 22 10:40:05 wakis02 postfix/smtpd[4898]: connect from localhost[::1] Oct 22 10:40:05 wakis02 postfix/smtpd[4898]: BF9AD1C94: client=localhost[::1] Oct 22 10:40:05 wakis02 postfix/cleanup[4901]: BF9AD1C94: message-id=<008b01d10ca4$eb5fd0b0$c21f7210$@de> Oct 22 10:40:10 wakis02 postfix/qmgr[1304]: BF9AD1C94: from=, size=312694, nrcpt=5 (queue active) Oct 22 10:40:10 wakis02 postfix/smtpd[4898]: ADDE72652: client=localhost[::1] Oct 22 10:40:10 wakis02 postfix/cleanup[4901]: ADDE72652: message-id=<008b01d10ca4$eb5fd0b0$c21f7210$@de> Oct 22 10:40:10 wakis02 postfix/local[4903]: BF9AD1C94: to=, relay=local, delay=5.2, delays=4.9/0.03/0/0.3, dsn=2.0.0, status=sent (delivered to command: /var/lib/mailman/mail/mailman post beisitz) Oct 22 10:40:10 wakis02 postfix/local[4909]: BF9AD1C94: to=, relay=local, delay=5.3, delays=4.9/0.11/0/0.29, dsn=2.0.0, status=sent (delivered to command: /var/lib/mailman/mail/mailman post vorstand) Oct 22 10:40:10 wakis02 postfix/local[4907]: BF9AD1C94: to=, relay=local, delay=5.3, delays=4.9/0.07/0/0.33, dsn=2.0.0, status=sent (delivered to command: /var/lib/mailman/mail/mailman post kollegium) Oct 22 10:40:10 wakis02 postfix/local[4905]: BF9AD1C94: to=, relay=local, delay=5.3, delays=4.9/0.05/0/0.36, dsn=2.0.0, status=sent (delivered to command: /var/lib/mailman/mail/mailman post gruppensprecher) Oct 22 10:40:10 wakis02 postfix/local[4902]: BF9AD1C94: to=, relay=local, delay=5.3, delays=4.9/0.02/0/0.39, dsn=2.0.0, status=sent (delivered to command: /var/lib/mailman/mail/mailman post ak-leiter) Oct 22 10:40:11 wakis02 postfix/qmgr[1304]: BF9AD1C94: removed Oct 22 10:40:12 wakis02 postfix/smtpd[4920]: connect from localhost[::1] Oct 22 10:40:12 wakis02 postfix/smtpd[4920]: 2AFF52697: client=localhost[::1] Oct 22 10:40:12 wakis02 postfix/cleanup[4921]: 2AFF52697: message-id=<008b01d10ca4$eb5fd0b0$c21f7210$@de> Oct 22 10:40:21 wakis02 postfix/qmgr[1304]: ADDE72652: from=, size=312704, nrcpt=5 (queue active) Oct 22 10:40:21 wakis02 postfix/local[4909]: ADDE72652: to=, relay=local, delay=11, delays=11/0.01/0/0.35, dsn=2.0.0, status=sent (delivered to command: /var/lib/mailman/mail/mailman post vorstand) Oct 22 10:40:21 wakis02 postfix/local[4905]: ADDE72652: to=, relay=local, delay=11, delays=11/0/0/0.35, dsn=2.0.0, status=sent (delivered to command: /var/lib/mailman/mail/mailman post gruppensprecher) Oct 22 10:40:21 wakis02 postfix/local[4903]: ADDE72652: to=, relay=local, delay=11, delays=11/0/0/0.35, dsn=2.0.0, status=sent (delivered to command: /var/lib/mailman/mail/mailman post ak-leiter) Oct 22 10:40:21 wakis02 postfix/local[4902]: ADDE72652: to=, relay=local, delay=11, delays=11/0/0/0.36, dsn=2.0.0, status=sent (delivered to command: /var/lib/mailman/mail/mailman post beisitz) Oct 22 10:40:21 wakis02 postfix/local[4907]: ADDE72652: to=, relay=local, delay=11, delays=11/0.01/0/0.36, dsn=2.0.0, status=sent (delivered to command: /var/lib/mailman/mail/mailman post kollegium) Oct 22 10:40:21 wakis02 postfix/smtpd[4898]: 8010E3A: client=localhost[::1] Oct 22 10:40:21 wakis02 postfix/cleanup[4901]: 8010E3A: message-id=<008b01d10ca4$eb5fd0b0$c21f7210$@de> Oct 22 10:40:21 wakis02 postfix/qmgr[1304]: ADDE72652: removed Oct 22 10:40:23 wakis02 postfix/qmgr[1304]: 2AFF52697: from=, size=314124, nrcpt=1 (queue active) Oct
Re: email duplicates
On 10/27/2015 05:06 PM, Viktor Dukhovni wrote: On Tue, Oct 27, 2015 at 08:45:20AM +0100, Marco Stoecker wrote: Here is the log, where postfix got the original message (which was sent to 5 mailing lists) and handed over to mailman (which is done 5 times with different postfix ID's). No, the logs show 5 incoming messages (from [::1]) each to the same 5 recipients. Any bifurcation is upstream. Perhaps a misconfigured content_filter? I'm just curious about the message-id=<008b01d10ca4$eb5fd0b0$c21f7210$@de>, this is always the same, but the postfix ID differ. Any glue? The clue is that 5 messages arrived, so Postfix delivered all 5 messages. I've "collated" the logs below. You need to look at the "Received" headers of one of the messages to determine how it got to "[::1]". ... I do need some assistance, as this is very new for me. Thx in advance. So this is the "Received" header of 5 out of 5 messages. I can't see where the duplication happend :-( message1: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) by metaxa.loswebos.de (Postfix) with ESMTPS id 623A33A8C005 for ; Thu, 22 Oct 2015 10:45:05 +0200 (CEST) Received: from wakis02.local ([92.211.6.209]) by mrelayeu.kundenserver.de (mreue104) with ESMTPA (Nemesis) id 0LbJZC-1aDlg63wBm-00kvH9; Thu, 22 Oct 2015 10:45:05 +0200 Received: from wakis02.local (localhost [IPv6:::1]) by wakis02.local (Postfix) with ESMTP id B25442678; Thu, 22 Oct 2015 10:44:55 +0200 (CEST) X-Original-To: vorstand@localhost Delivered-To: vorstand@localhost Received: from wakis02.local (localhost [IPv6:::1]) by wakis02.local (Postfix) with ESMTP id 98DC6269A; Thu, 22 Oct 2015 10:40:43 +0200 (CEST) Received: from imap.1und1.de [212.227.15.188] by wakis02.local with IMAP (fetchmail-6.3.26) Thu, 22 Oct 2015 10:40:43 +0200 (CEST) Received: from [212.227.15.41] ([212.227.15.41]) by mx.kundenserver.de (mxeue002) with ESMTPS (Nemesis) id 0M1foo-1aeGtV2fLW-00tjIT for ; Thu, 22 Oct 2015 10:37:47 +0200 Received: from mout.web.de ([212.227.15.3]) by mx.kundenserver.de (mxeue002) with ESMTPS (Nemesis) id 0MVE1V-1a1cd42azt-00YP1m for ; Thu, 22 Oct 2015 10:37:47 +0200 Received: from Klamotten ([84.168.195.183]) by smtp.web.de (mrweb003) with ESMTPSA (Nemesis) id 0MTh7A-1Zy14E1g36-00QRsw; Thu, 22 Oct 2015 10:37:47 +0200 message2: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) by metaxa.loswebos.de (Postfix) with ESMTPS id F24F23962117 for ; Thu, 22 Oct 2015 10:43:36 +0200 (CEST) Received: from wakis02.local ([92.211.6.209]) by mrelayeu.kundenserver.de (mreue004) with ESMTPA (Nemesis) id 0LouWl-1aRIN61viN-00gqgL; Thu, 22 Oct 2015 10:43:35 +0200 Received: from wakis02.local (localhost [IPv6:::1]) by wakis02.local (Postfix) with ESMTP id EA2772652; Thu, 22 Oct 2015 10:43:25 +0200 (CEST) X-Original-To: vorstand@localhost Delivered-To: vorstand@localhost Received: from wakis02.local (localhost [IPv6:::1]) by wakis02.local (Postfix) with ESMTP id 8251C2697; Thu, 22 Oct 2015 10:40:32 +0200 (CEST) Received: from imap.1und1.de [212.227.15.188] by wakis02.local with IMAP (fetchmail-6.3.26) Thu, 22 Oct 2015 10:40:32 +0200 (CEST) Received: from [212.227.15.41] ([212.227.15.41]) by mx.kundenserver.de (mxeue002) with ESMTPS (Nemesis) id 0MfQUM-1a9cy92XG6-00OoOD for ; Thu, 22 Oct 2015 10:37:47 +0200 Received: from mout.web.de ([212.227.15.3]) by mx.kundenserver.de (mxeue002) with ESMTPS (Nemesis) id 0M4zk6-1ajnCX2Rpe-00zFbN for ; Thu, 22 Oct 2015 10:37:47 +0200 Received: from Klamotten ([84.168.195.183]) by smtp.web.de (mrweb003) with ESMTPSA (Nemesis) id 0MTh7A-1Zy14E1g36-00QRsw; Thu, 22 Oct 2015 10:37:47 +0200 message3: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) by metaxa.loswebos.de (Postfix) with ESMTPS id A70E73A8C005 for ; Thu, 22 Oct 2015 10:43:20 +0200 (CEST) Received: from wakis02.local ([92.211.6.209]) by mrelayeu.kundenserver.de (mreue005) with ESMTPA (Nemesis) id 0Ll22r-1aPcc22d41-00ao9V; Thu, 22 Oct 2015 10:43:19 +0200 Received: from wakis02.local (localhost [IPv6:::1]) by wakis02.local (Postfix) with ESMTP id B25AD2678; Thu, 22 Oct 2015 10:43:09 +0200 (CEST) X-Original-To: vorstand@localhost Delivered-To: vorstand@localhost Received: from wakis02.local (localhost [IPv6:::1]) by wakis02.local (Postfix) with ESMTP id 8010E3A; Thu, 22 Oct 2015 10:40:21 +0200 (CEST) Received: from imap.1und1.de [212.227.15.188] by wakis02.local with IMAP (fetchmail-6.3.26) Thu, 22 Oct 2015 10:40:21 +0200 (CEST) Received: from [212.227.15.41] ([212.227.15.41]) by mx.kundenserver.de (mxeue002) with ESMTPS (Nemesis) id 0M2Uth-1ahI6Q2nfZ-00sLaU for ; Thu, 22 Oct 2015 10:37:47 +0200 Received: from mout.web.de ([212.227.15.3]) by mx.kundenserver.de (mxeue002) with ESMTPS (Nemesis) i
Re: email duplicates
On 10/27/2015 06:10 PM, Bill Cole wrote: On 27 Oct 2015, at 12:40, Marco Stoecker wrote: [...] I do need some assistance, as this is very new for me. Thx in advance. So this is the "Received" header of 5 out of 5 messages. I can't see where the duplication happend :-( Maybe this abridgment will help, reducing each to the first & second Received headers: message1: [...] Received: from mout.web.de ([212.227.15.3]) by mx.kundenserver.de (mxeue002) with ESMTPS (Nemesis) id 0MVE1V-1a1cd42azt-00YP1m for ; Thu, 22 Oct 2015 10:37:47 +0200 Received: from Klamotten ([84.168.195.183]) by smtp.web.de (mrweb003) with ESMTPSA (Nemesis) id 0MTh7A-1Zy14E1g36-00QRsw; Thu, 22 Oct 2015 10:37:47 +0200 message2: [...] Received: from mout.web.de ([212.227.15.3]) by mx.kundenserver.de (mxeue002) with ESMTPS (Nemesis) id 0M4zk6-1ajnCX2Rpe-00zFbN for ; Thu, 22 Oct 2015 10:37:47 +0200 Received: from Klamotten ([84.168.195.183]) by smtp.web.de (mrweb003) with ESMTPSA (Nemesis) id 0MTh7A-1Zy14E1g36-00QRsw; Thu, 22 Oct 2015 10:37:47 +0200 message3: [...] Received: from mout.web.de ([212.227.15.3]) by mx.kundenserver.de (mxeue002) with ESMTPS (Nemesis) id 0MIWPn-1ZovKO2jl9-004F6W for ; Thu, 22 Oct 2015 10:37:47 +0200 Received: from Klamotten ([84.168.195.183]) by smtp.web.de (mrweb003) with ESMTPSA (Nemesis) id 0MTh7A-1Zy14E1g36-00QRsw; Thu, 22 Oct 2015 10:37:47 +0200 message4: [...] Received: from mout.web.de ([212.227.15.3]) by mx.kundenserver.de (mxeue002) with ESMTPS (Nemesis) id 0M1Oy9-1adzmM2xGD-00tS34 for ; Thu, 22 Oct 2015 10:37:47 +0200 Received: from Klamotten ([84.168.195.183]) by smtp.web.de (mrweb003) with ESMTPSA (Nemesis) id 0MTh7A-1Zy14E1g36-00QRsw; Thu, 22 Oct 2015 10:37:47 +0200 message5: [...] Received: from mout.web.de ([212.227.15.3]) by mx.kundenserver.de (mxeue002) with ESMTPS (Nemesis) id 0MKz7Q-1ZpBNb35bE-0006Vb for ; Thu, 22 Oct 2015 10:37:47 +0200 Received: from Klamotten ([84.168.195.183]) by smtp.web.de (mrweb003) with ESMTPSA (Nemesis) id 0MTh7A-1Zy14E1g36-00QRsw; Thu, 22 Oct 2015 10:37:47 +0200 In short: a machine using the IP address 84.168.195.183 and claiming to have the bogus name 'Klamotten ' passed a single message to a mail server calling itself both 'smtp.web.de' and 'mrweb003' for which the server used the id '0MTh7A-1Zy14E1g36-00QRsw' and which was then passed to to the mail server mx.kundenserver.de by a mail system claiming to be mout.web.de *FIVE DIFFERENT TIMES*, each time with one of *FIVE DIFFERENT RECIPIENTS* This gives the impression that the user of "Klamotten" (apparently a DTAG residential customer) addressed that single message to 5 different recipients and the *.web.de mail complex split the single message into 5 discrete but mostly identical messages (except for the ensuing Receives headers) for onward transport. That's inefficient, but not formally wrong. It may be that the server mx.kundenserver.de refuses to accept multi-recipient messages and so the split was imposed upon, rather than being chosen by, the mout.web.de server. As I understand now, the mail from the sender (machine Klamotte) is delivered to the smtp server from web.de which than is delivered to 1und1 (mx.kundenserver). From there fetchmail is getting it and delivered it to my postfix server, which than delivered it to mailman. After mailman handled it, it is than sending to the mailing list recipients vie postfix again. If postfix already gets 5 messages, than I will check then handover from fetchmail to postfix and also the message, before it gets to fetchmail. BR Marco
Re: email duplicates
On 10/28/2015 01:09 AM, Viktor Dukhovni wrote: On Tue, Oct 27, 2015 at 05:40:35PM +0100, Marco Stoecker wrote: message1: Delivered-To: vorstand@localhost Received: from wakis02.local (localhost [IPv6:::1]) by wakis02.local (Postfix) with ESMTP id 98DC6269A; Thu, 22 Oct 2015 10:40:43 +0200 (CEST) Received: from imap.1und1.de [212.227.15.188] by wakis02.local with IMAP (fetchmail-6.3.26) Thu, 22 Oct 2015 10:40:43 +0200 (CEST) Received: from [212.227.15.41] ([212.227.15.41]) by mx.kundenserver.de (mxeue002) with ESMTPS (Nemesis) id 0M1foo-1aeGtV2fLW-00tjIT for ; Thu, 22 Oct 2015 10:37:47 +0200 Received: from mout.web.de ([212.227.15.3]) by mx.kundenserver.de (mxeue002) with ESMTPS (Nemesis) id 0MVE1V-1a1cd42azt-00YP1m for ; Thu, 22 Oct 2015 10:37:47 +0200 Received: from Klamotten ([84.168.195.183]) by smtp.web.de (mrweb003) with ESMTPSA (Nemesis) id 0MTh7A-1Zy14E1g36-00QRsw; Thu, 22 Oct 2015 10:37:47 +0200 This message was incorrectly expanded to 5 header recipients, even though it was delivered upstream to just 1. Your fetchmail is incorrectly resending mail to recipients found in the "To:" header. You have a botched fetchmail installation, and possible lack of upstream multi-drop support. This is a very valid point I did not consider fetchmail as root cause so far. As since debian 7 fetchmail does not log time stamp information, it is somehow difficult for me to check, but will see what I can do here now. Thx Marco
Re: email duplicates
On 10/28/2015 11:04 PM, Bill Cole wrote: > On 28 Oct 2015, at 15:06, Viktor Dukhovni wrote: > >> On Wed, Oct 28, 2015 at 02:51:43PM -0400, Bill Cole wrote: >> >>> From that point onward there are 5 distinct messages. >>> >>> If those are 5 different mailing lists, subscribers to multiple lists >>> will >>> receive multiple copies. >> >> Not on properly configured systems. We're not talking about >> subscribers who are on multiple lists. Rather each list received >> 5 copies. If some subscriber was on two lists, that subscriber >> would have received 10 copies. > > I am very sorry, you are absolutely correct. I see from a more careful > reading of the rest of the thread that I definitely misinterpreted the > problem description. Thank you for pointing it out. > >>> This seems to me like it was entirely the work of the *sender* of that >>> message. A single message was sent to 5 mailing list addresses and it >>> got >>> delivered to the subscribers of each of 5 mailing lists. This is a >>> highly >>> predictable (i.e.: perfectly normal) pattern of behavior by Mailman & >>> Postfix. >> >> No, cross-posting is perfectly fine and is not the sender's fault. >> What's misconfigured is the interaction of the upstream multi-drop >> mailbox and fetchmail. >> >>> If you want the duplication to stop, get the sender to stop sending to >>> multiple lists. >> >> Please don't mislead the OP, he's got a difficult enough problem >> to address. > > Indeed, and I *THINK* (for what little that may be worth...) that it may > be addressed here: http://www.fetchmail.info/fetchmail-FAQ.html#M7 > > Fetchmail is retrieving messages that have 3 existing Received headers > like these on "message5" of the post dated "Tue, 27 Oct 2015 17:40:35 > +0100" > (Numbering and blank lines between them added for clarity): > > 1: Received: from [212.227.15.41] ([212.227.15.41]) by mx.kundenserver.de > (mxeue002) with ESMTPS (Nemesis) id 0MPww6-1Zu9SD394E-0054aD for > ; Thu, 22 Oct 2015 10:37:47 > +0200 > > 2: Received: from mout.web.de ([212.227.15.3]) by mx.kundenserver.de > (mxeue002) > with ESMTPS (Nemesis) id 0MKz7Q-1ZpBNb35bE-0006Vb for > ; Thu, 22 Oct 2015 10:37:47 +0200 > > 3: Received: from Klamotten ([84.168.195.183]) by smtp.web.de (mrweb003) > with > ESMTPSA (Nemesis) id 0MTh7A-1Zy14E1g36-00QRsw; Thu, 22 Oct 2015 10:37:47 > +0200 > > > Headers 1 & 2 are a quirky pair: both added by nominally the same server > delivering to 2 different envelope recipients. #1 has the address > "mailmanser...@waldorfkindergarten-erlangen.de" as it does in all 5 > messages in that set (which also have identical line #3's, indicating > they were sent as one). Line #2 has the address that needs to be > detected by fetchmail: beis...@waldorfkindergarten-erlangen.de. However, > the Fetchmail FAQ and man page say only that the first Received header > is examined, implying strongly that no others will be checked if that > fails, falling back to the inherently broken scanning of To/Cc headers. > > Based on that and the Fetchmail docs, it seems to me (imperfect as my > analysis has proven to be...) that a likely solution is for the OP to > add the directive "envelope 1 Received" to the relevant stanza of his > .fetchmailrc file, telling fetchmail to skip the first Received header > in fetched messages. > Thx Bill and Viktor! as I discussed this topic in parallel in the mailman mailinglist, we came there today also to the conclusion, that fetchmail is the root cause, due to missing envelope information/maildrop capabilities. Based on the Fetchmail docs 'envelope 1 Received' is only half of the solution. I have to set an alias for the postfix mailserver in addition cause fetchmail.log shows 'fetchmail: line rejected, mx.kundenserver.de is not an alias of the mailserver' How do I set the alias for the mailserver? BR Marco
Re: email duplicates
On 10/29/2015 01:07 AM, Viktor Dukhovni wrote: > On Thu, Oct 29, 2015 at 12:26:20AM +0100, Marco Stoecker wrote: > >> Thx Bill and Viktor! >> as I discussed this topic in parallel in the mailman mailinglist, we >> came there today also to the conclusion, that fetchmail is the root >> cause, due to missing envelope information/maildrop capabilities. >> >> Based on the Fetchmail docs 'envelope 1 Received' is only half of the >> solution. I have to set an alias for the postfix mailserver in addition >> cause fetchmail.log shows 'fetchmail: line rejected, mx.kundenserver.de >> is not an alias of the mailserver' >> How do I set the alias for the mailserver? > > This is a fetchmail question. There may be some fetchmail experts > here, but the duplication happens upstream of Postfix, so this is > not really the right list for this. If anyone here knows the > answer, that's fine to post of course, but you may be better off > asking on a list for fetchmail if there is one. > I already posted to the fetchmail-users list 10 minutes ago :-) I thought "alias for mailserver" is a postfix configuration issue. Thx for clarification. Marco
Re: email duplicates
On 10/28/2015 11:04 PM, Bill Cole wrote: > On 28 Oct 2015, at 15:06, Viktor Dukhovni wrote: > >> On Wed, Oct 28, 2015 at 02:51:43PM -0400, Bill Cole wrote: >> >>> From that point onward there are 5 distinct messages. >>> >>> If those are 5 different mailing lists, subscribers to multiple lists >>> will >>> receive multiple copies. >> >> Not on properly configured systems. We're not talking about >> subscribers who are on multiple lists. Rather each list received >> 5 copies. If some subscriber was on two lists, that subscriber >> would have received 10 copies. > > I am very sorry, you are absolutely correct. I see from a more careful > reading of the rest of the thread that I definitely misinterpreted the > problem description. Thank you for pointing it out. > >>> This seems to me like it was entirely the work of the *sender* of that >>> message. A single message was sent to 5 mailing list addresses and it >>> got >>> delivered to the subscribers of each of 5 mailing lists. This is a >>> highly >>> predictable (i.e.: perfectly normal) pattern of behavior by Mailman & >>> Postfix. >> >> No, cross-posting is perfectly fine and is not the sender's fault. >> What's misconfigured is the interaction of the upstream multi-drop >> mailbox and fetchmail. >> >>> If you want the duplication to stop, get the sender to stop sending to >>> multiple lists. >> >> Please don't mislead the OP, he's got a difficult enough problem >> to address. > > Indeed, and I *THINK* (for what little that may be worth...) that it may > be addressed here: http://www.fetchmail.info/fetchmail-FAQ.html#M7 > > Fetchmail is retrieving messages that have 3 existing Received headers > like these on "message5" of the post dated "Tue, 27 Oct 2015 17:40:35 > +0100" > (Numbering and blank lines between them added for clarity): > > 1: Received: from [212.227.15.41] ([212.227.15.41]) by mx.kundenserver.de > (mxeue002) with ESMTPS (Nemesis) id 0MPww6-1Zu9SD394E-0054aD for > ; Thu, 22 Oct 2015 10:37:47 > +0200 > > 2: Received: from mout.web.de ([212.227.15.3]) by mx.kundenserver.de > (mxeue002) > with ESMTPS (Nemesis) id 0MKz7Q-1ZpBNb35bE-0006Vb for > ; Thu, 22 Oct 2015 10:37:47 +0200 > > 3: Received: from Klamotten ([84.168.195.183]) by smtp.web.de (mrweb003) > with > ESMTPSA (Nemesis) id 0MTh7A-1Zy14E1g36-00QRsw; Thu, 22 Oct 2015 10:37:47 > +0200 > > > Headers 1 & 2 are a quirky pair: both added by nominally the same server > delivering to 2 different envelope recipients. #1 has the address > "mailmanser...@waldorfkindergarten-erlangen.de" as it does in all 5 > messages in that set (which also have identical line #3's, indicating > they were sent as one). Line #2 has the address that needs to be > detected by fetchmail: beis...@waldorfkindergarten-erlangen.de. However, > the Fetchmail FAQ and man page say only that the first Received header > is examined, implying strongly that no others will be checked if that > fails, falling back to the inherently broken scanning of To/Cc headers. > > Based on that and the Fetchmail docs, it seems to me (imperfect as my > analysis has proven to be...) that a likely solution is for the OP to > add the directive "envelope 1 Received" to the relevant stanza of his > .fetchmailrc file, telling fetchmail to skip the first Received header > in fetched messages. > problem solved :-D The indication of envelope 1 Received + aka mx.kundenserver.de in the fetchmailrc was the solution. Thx a lot Marco
Sending rate limiting per destination MTA (not recipient domain)
Hi all, I am sending a bunch of emails to a set of target domains. I see that many of them are all served by the same MTA and this MTA is limiting my sending because of course it sees too many sending at a time from me. I know I could just use the transport map for all of these target domains and defining rate limiting configuration for all of them, but I am not in control of the target domain list, so it could change in the near future. Is there a way to implement a transport map for that specific target MTA instead of listing all the domains and periodically keeping that list updated? Thanks in advance Marco
Re: Sending rate limiting per destination MTA (not recipient domain)
Hello Wietse, On Fri, Nov 18, 2016 at 5:20 PM, Wietse Venema wrote: > Marco Pizzoli: > > Hi all, > > I am sending a bunch of emails to a set of target domains. > > I see that many of them are all served by the same MTA and this MTA is > > limiting my sending because of course it sees too many sending at a time > > from me. > > > > I know I could just use the transport map for all of these target domains > > and defining rate limiting configuration for all of them, but I am not in > > control of the target domain list, so it could change in the near future. > > > > Is there a way to implement a transport map for that specific target MTA > > instead of listing all the domains and periodically keeping that list > > updated? > > Fundamentally, this is a layering problem. At this time, only the > Postrix SMTP client knows remote MTA name/IP address information, > not the Postfix scheduler. You can use global settings such as > per-transport process limits or rate delays, or kernel-based traffic > shaping. > > Wietse > Thank you very much for your answer. I understand. Apart from the MX dynamic information, is there a way within Postfix to specify that specific rate limiting toward that specific hostname/ip address ? My use-case is I have a bunch of domains all of them using the same hostname/IP as MX and they could increase in the number but still having the same MX... so to me it would be acceptable to address just that specific MX sending. I thought about the iptables solution, but I was searching a Postfix-only solution. Thank you again Marco
destination throttling state sharing
Hi all, I have a battery of postfix servers used for sending bulk emails to the Internet. All of them are seen from the outside as they were one: - same hostname - same public IP address Considered that I have implemented the sending throttling for specific destinations in order to avoid "status=deferred" situations, I'm in a situation where these Postfix instances are not sharing any info about the throttling status. As a consequence, this doesn't permit me (i.e.) to scale up transparently in the number of servers, in case of need. Is there a way to share this kind of information between Postfix instances? I would really if you could share your personal experience on how to deal in general with a scenario like this. Thanks a lot in advance Marco
Re: destination throttling state sharing
Hi Wietse, On Wed, Feb 18, 2015 at 1:23 PM, Wietse Venema wrote: > Marco Pizzoli: > > > Is there a way to share this kind of information between Postfix > instances? > > This is not implemented. Postfix by design can recover from a crash > in any program except the master daemon. I don't know how to share > rate counters in a crash-recoverable manner without a great deal of > code that makes Postfix less reliable. > > I do understand. My guess was that this was (in a way) solvable by leveraging something already in place in Postfix like the interaction with memcached. But ok, message received. I willl investigate that. Thank you again Marco
Routing only email with a certain From address to another MTA?
Greetings, While I was updating/cleaning up the whole configuration of an email server I must manage (see the other message I posted here yesterday from my main address) another issue came up. The first help I'd need is help with terminology: my main problem may be the simple fact that I don't know, or forgot, what the RIGHT name of the function below is, and consequently don't recognize the right documentation. Thanks in advance for any pointer. Here is the issue. The SPF and DKIM configuration of that server as the MTA for its domain, example.com, is almost finished. Now, if someuser sends email through my postfix 1) as "From: someu...@example.com" 2) as "From: someu...@someotherdomain.com" obviously, email of type (1) will pass all SPF and DKIM checks performed at destination, email of type (2) won't. Of course, someuser could connect directly to the MTA of someotherdomain.com when he needs to use that account. But for several reasons, we (including someuser!) would really, really prefer to avoid that. So, a) is it possible to tell postfix at example.com that all and only the email from someuser with a From: address of someu...@someotherdomain.com should be relayed through that MTA, not directly to destination? (I am almost sure it is, as I said my first problem is to know/use the right search terms for this function, sorry) b) would it work, as far as SPF and DKIM are concerned? Would it cause other problems? Thanks, Marco
Re: Routing only email with a certain From address to another MTA?
Hi Wietse! indeed, judging from this howto I found thanks to your pointer: http://kostja-osipov.livejournal.com/32518.html *sender_dependent_relayhost_maps *seems exactly what I need, > Does your system have "relay" permissions at the other domain's mai > server? You may have to configure SASL auth and > "smtp_sender_dependent_authentication = yes". that's likely the next step, now I know where to go, thanks. Marco
update on: Routing only email with a certain From address to another MTA?
2015-02-24 13:44 GMT+01:00 Marco Fioretti : > Hi Wietse! > > indeed, judging from this howto I found thanks to your pointer: > > http://kostja-osipov.livejournal.com/32518.html > > *sender_dependent_relayhost_maps *seems exactly what I need, > > > Does your system have "relay" permissions at the other domain's mai > > server? You may have to configure SASL auth and > > "smtp_sender_dependent_authentication = yes". > > that's likely the next step, now I know where to go, thanks. > > Marco > Hi, after reading some more documntation and tutorials online, I have added the following section to my main.cf, postmapped and restarted postfix: smtp_sender_dependent_authentication = yes smtp_sasl_auth_enable= yes smtp_sasl_password_maps = hash:/etc/postfix/mymaps/sasl_passwd smtp_tls_security_level = may smtp_tls_auth_only = yes smtp_sasl_security_options = noanonymous smtp_sasl_type = cyrus smtp_sasl_mechanism_filter = plain, login right now I am stuck at this point, when I send email as ma...@example.com. Not sure how much it depends on me, and how much on some issues on the other side. Thanks in advance for any further help, Marco postfix/smtp[11856]: certificate verification failed for mx.example.com[xx.xx.xx.xx]:587: self-signed certificate postfix/smtp[11856]: warning: SASL authentication failure: No worthy mechs found postfix/smtp[11856]: C56A8A4E830: to=, relay= mx.example.com[xx.xx.xx.xx]:587, delay=0.31, delays=0.21/0/0.09/0, dsn=4.7.0, status=deferred (SASL authentication failed; cannot authenticate to server mx.example.com[xx.xx.xx.xx]: no mechanism available)
Re: update on: Routing only email with a certain From address to another MTA?
Just FTR: if I set smtp_tls_security_level = none I get Diagnostic-Code: smtp; 530 5.7.0 Must issue a STARTTLS command first Playing with several combination of the parameters suggested by Wietse doesn't seem to make any difference. Below is the last combination that I have tried. the lines starting with # were part of the previous line, but the result is always an error message in the logs identical to the one already posted, with the obvious exception of timestamps and msgids :-( smtp_sasl_auth_enable= yes smtp_sasl_mechanism_filter= #plain,login smtp_sasl_password_maps = hash:/etc/postfix/mymaps/sasl_passwd smtp_sasl_security_options = noanonymous smtp_sasl_type = cyrus smtp_sender_dependent_authentication = yes smtp_tls_auth_only= yes smtp_tls_security_level = may smtp_sasl_tls_security_options = noanonymous #, noplaintext 2015-02-24 18:22 GMT+01:00 Wietse Venema : > Marco Fioretti: > > 2015-02-24 13:44 GMT+01:00 Marco Fioretti : > > > > > Hi Wietse! > > > > > > indeed, judging from this howto I found thanks to your pointer: > > > > > > http://kostja-osipov.livejournal.com/32518.html > > > > > > *sender_dependent_relayhost_maps *seems exactly what I need, > > > > > > > Does your system have "relay" permissions at the other domain's mai > > > > server? You may have to configure SASL auth and > > > > "smtp_sender_dependent_authentication = yes". > > > > > > that's likely the next step, now I know where to go, thanks. > > > > > > Marco > > > > > > > Hi, > > after reading some more documntation and tutorials online, I have added > the > > following section to my main.cf, postmapped and restarted postfix: > > > > smtp_sender_dependent_authentication = yes > > smtp_sasl_auth_enable= yes > > smtp_sasl_password_maps = > hash:/etc/postfix/mymaps/sasl_passwd > > smtp_tls_security_level = may > > This table is searched with the sender address first, and if no match > is found, it is searched as usual with server or destination. > > > smtp_sasl_mechanism_filter = plain, login > ... > > postfix/smtp[11856]: certificate verification failed for > > self-signed certificate > > postfix/smtp[11856]: warning: SASL authentication failure: No worthy > mechs > > found > > Did you set smtp_sasl_tls_security_options? The default does not > allow plaintext authentication. > > Wietse >
Re: update on: Routing only email with a certain From address to another MTA?
here is postconf -n output: alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix debug_peer_level = 2 disable_vrfy_command = yes html_directory = /usr/share/doc/postfix-2.4.3-documentation/html inet_interfaces = all mail_owner = postfix mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man mydestination = $myhostname, localhost mydomain = $myhostname myhostname = a.mx.my.main.domain mynetworks = 127.0.0.0/8, xx.xx.xx.xx myorigin = $mydomain newaliases_path = /usr/bin/newaliases.postfix non_smtpd_milters = inet:localhost:8891 queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.4.3-documentation/readme relay_domains = sample_directory = /etc/postfix sender_dependent_relayhost_maps = hash:/etc/postfix/mymaps/relayhost_maps sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtp_sasl_auth_enable = yes smtp_sasl_mechanism_filter = smtp_sasl_password_maps = hash:/etc/postfix/mymaps/sasl_passwd smtp_sasl_security_options = noanonymous smtp_sasl_tls_security_options = noanonymous smtp_sasl_type = cyrus smtp_sender_dependent_authentication = yes smtp_tls_security_level = may smtpd_helo_required = yes smtpd_helo_restrictions = smtpd_milters = inet:localhost:8891 smtpd_recipient_restrictions = reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination,check_helo_access hash:/etc/postfix/reject_own_helo, check_policy_service unix:postgrey/socket smtpd_sasl_auth_enable = yes smtpd_sasl_path = /var/spool/postfix/private/auth smtpd_sasl_type = dovecot smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/myssl/mycert.pem smtpd_tls_key_file = /etc/myssl/mycert.pem smtpd_tls_loglevel = 1 smtpd_tls_security_level = may strict_rfc821_envelopes = yes unknown_address_reject_code = 554 unknown_client_reject_code = 554 unknown_hostname_reject_code = 554 unknown_local_recipient_reject_code = 550 virtual_alias_maps = hash:/etc/postfix/mymaps/valias.map virtual_gid_maps = static:5000 virtual_mailbox_base = /var/mail/mymail_storage virtual_mailbox_domains = /etc/postfix/mymaps/vhosts.map virtual_mailbox_maps = hash:/etc/postfix/mymaps/vmailboxes.map virtual_transport = procmail virtual_uid_maps = static:5000 2015-02-24 19:18 GMT+01:00 Wietse Venema : > Marco Fioretti: > > Playing with several combination of the parameters suggested by Wietse > > doesn't seem to make any difference. Below is the last combination that I > > have tried. the lines starting with # were part of the previous line, but > > the result is always an error message in the logs identical to the one > > already posted, with the obvious exception of timestamps and msgids > > > > :-( > > > > smtp_sasl_auth_enable= yes > > smtp_sasl_mechanism_filter= > > #plain,login > > Please send "postconf -n" command output. > > Wietse >
Re: update on: Routing only email with a certain From address to another MTA?
right, sorry. Here is the logs of a new message sent just now, with the configuration showed in my previous email: postfix/smtp[20851]: certificate verification failed for mx.example.com[xx.xx.xx.xx.]:587: self-signed certificate postfix/smtp[20851]: warning: SASL authentication failure: No worthy mechs found postfix/smtp[20851]: 59D5BA4E835: to=, relay= mx.example.com[xx.xx.xx.xx.]:587, delay=0.3, delays=0.18/0.02/0.1/0, dsn=4.7.0, status=deferred (SASL authentication failed; cannot authenticate to server mx.example.com[xx.xx.xx.xx.]: no mechanism available) postfix/smtpd[20844]: disconnect from localhost[127.0.0.1] 2015-02-24 19:28 GMT+01:00 Wietse Venema : > Marco Fioretti: > > here is postconf -n output: > > And the logging for this? You have changed settings. > > Wietse > > > alias_database = hash:/etc/aliases > > alias_maps = hash:/etc/aliases > > command_directory = /usr/sbin > > config_directory = /etc/postfix > > daemon_directory = /usr/libexec/postfix > > debug_peer_level = 2 > > disable_vrfy_command = yes > > html_directory = /usr/share/doc/postfix-2.4.3-documentation/html > > inet_interfaces = all > > mail_owner = postfix > > mailq_path = /usr/bin/mailq.postfix > > manpage_directory = /usr/share/man > > mydestination = $myhostname, localhost > > mydomain = $myhostname > > myhostname = a.mx.my.main.domain > > mynetworks = 127.0.0.0/8, xx.xx.xx.xx > > myorigin = $mydomain > > newaliases_path = /usr/bin/newaliases.postfix > > non_smtpd_milters = inet:localhost:8891 > > queue_directory = /var/spool/postfix > > readme_directory = /usr/share/doc/postfix-2.4.3-documentation/readme > > relay_domains = > > sample_directory = /etc/postfix > > sender_dependent_relayhost_maps = hash:/etc/postfix/mymaps/relayhost_maps > > sendmail_path = /usr/sbin/sendmail.postfix > > setgid_group = postdrop > > smtp_sasl_auth_enable = yes > > smtp_sasl_mechanism_filter = > > smtp_sasl_password_maps = hash:/etc/postfix/mymaps/sasl_passwd > > smtp_sasl_security_options = noanonymous > > smtp_sasl_tls_security_options = noanonymous > > smtp_sasl_type = cyrus > > smtp_sender_dependent_authentication = yes > > smtp_tls_security_level = may > > smtpd_helo_required = yes > > smtpd_helo_restrictions = > > smtpd_milters = inet:localhost:8891 > > smtpd_recipient_restrictions = reject_invalid_hostname, > > reject_non_fqdn_hostname, reject_non_fqdn_sender, > > reject_non_fqdn_recipient, reject_unknown_sender_domain, > > reject_unknown_recipient_domain, > > permit_mynetworks, > > permit_sasl_authenticated, > > reject_unauth_destination, > check_helo_access > > hash:/etc/postfix/reject_own_helo, > > check_policy_service unix:postgrey/socket > > smtpd_sasl_auth_enable = yes > > smtpd_sasl_path = /var/spool/postfix/private/auth > > smtpd_sasl_type = dovecot > > smtpd_tls_auth_only = yes > > smtpd_tls_cert_file = /etc/myssl/mycert.pem > > smtpd_tls_key_file = /etc/myssl/mycert.pem > > smtpd_tls_loglevel = 1 > > smtpd_tls_security_level = may > > strict_rfc821_envelopes = yes > > unknown_address_reject_code = 554 > > unknown_client_reject_code = 554 > > unknown_hostname_reject_code = 554 > > unknown_local_recipient_reject_code = 550 > > virtual_alias_maps = hash:/etc/postfix/mymaps/valias.map > > virtual_gid_maps = static:5000 > > virtual_mailbox_base = /var/mail/mymail_storage > > virtual_mailbox_domains = /etc/postfix/mymaps/vhosts.map > > virtual_mailbox_maps = hash:/etc/postfix/mymaps/vmailboxes.map > > virtual_transport = procmail > > virtual_uid_maps = static:5000 > > > > > > 2015-02-24 19:18 GMT+01:00 Wietse Venema : > > > > > Marco Fioretti: > > > > Playing with several combination of the parameters suggested by > Wietse > > > > doesn't seem to make any difference. Below is the last combination > that I > > > > have tried. the lines starting with # were part of the previous > line, but > > > > the result is always an error message in the logs identical to the > one > > > > already posted, with the obvious exception of timestamps and msgids > > > > > > > > :-( > > > > > > > > smtp_sasl_auth_enable= yes > > > > smtp_sasl_mechanism_filter= > > > > #plain,login > > > > > > Please send "postconf -n" command output. > > > > > > Wietse > > > >
Re: update on: Routing only email with a certain From address to another MTA?
It works now!
it turns out that cyrus-sasl-lib-2, cyrus-sasl WERE installed, but NOT
cyrus-sasl-plain. No idea why, or why it wouldn't generate some more
explicit warning somewhere...
But thanks Wietse! Installing it fixed the problem.
right now I am so toast that, since this is fixed, I must absolutely stop
until tomorrow but...
To Viktor: that how do I check what mechanism are being offered by the
receiving machine? I want to check that just for completeness
To the whole list: general comments on the postconf -n output that I posted
are still very welcome, to be sure there are no weak spots.
Thanks all, again!
Marco
2015-02-24 19:51 GMT+01:00 Viktor Dukhovni :
> On Tue, Feb 24, 2015 at 01:44:01PM -0500, Wietse Venema wrote:
>
> > Marco Fioretti:
> > > right, sorry. Here is the logs of a new message sent just now, with the
> > > configuration showed in my previous email:
> > >
> > > postfix/smtp[20851]: certificate verification failed for
> > > mx.example.com[xx.xx.xx.xx.]:587:
> > > self-signed certificate
> > > postfix/smtp[20851]: warning: SASL authentication failure: No worthy
> mechs
> > > found
> >
> > Could it be that the SENDING machine lacks the SASL
> > plugins needed for LOGIN and PLAIN? Try:
> >
> > # yum install cyrus-sasl{,-plain}
> >
> > (or its equivalent for non-RedHat platforms).
>
> Also, what mechanisms is the receiving machine offering?
>
> --
> Viktor.
>
multi-instances: how to discriminate "master" in process list
Hi all, I have a multi-instance setup. By doing "ps -ef", as expected, I see a lot of "master" processes. Is there a way to see which master is related to which instance at a glance? So that I can rapidly say this pid is for instance 1, and so on... What I am looking at is, ideally, a way to see the process name something like "master-instance1" i.e. rspamd does exactly this, assigning a different process name just to explicit the "incarnation" of that process Thank you in advance Marco
Getting bounces from only one server
Dear all, I need to find a workaround an issue I am facing due to the limitation of an external product I am using to send/receive emails. Long story short: - 2 postfix servers acting both as sending as receiving servers from/to the Internet. - 1 application server sending to the Internet via both of them - the application server is capable of getting bounce information polling via POP3 ONLY one location So my need is to get the bounces only via server1. Is there a way to accomplish this? Somewhat like a DSN relay? I am open for suggestions... I am already thinking about migrating the POP3 server to Dovecot and making use of its "sync" capabilities, but again I would appreciate hearing other ideas... Thank you in advance Marco
Re: Optimising new system and postscreen questions
Hello Simon, The server runs local caching DNS BIND, so it's as quick as I can get it on > the slow Internet connection we are on. > I don't qualify mysef expert enough to answer the rest of your points, but for the DNS part I suggest you think about replacing BIND with Unbound, as the DNS resolver. It has a property called min_ttl that permits you to impose a minimum amount of TTL to the entries reported. DNSBL have always real low TTL values, on purpose. If you are fne with relaxing this real-timeness, well by setting a value of i.e. 60/90 seconds it will permit you to reduce the network dependency. Worth a try. Marco
Feature request: MX rollup
This is a followup of the following request: http://postfix.1071664.n5.nabble.com/Sending-rate-limiting-per-destination-MTA-not-recipient-domain-td87355.html The feature I am asking for is implemented in PowerMTA with the name "MX rollup": http://www.circleid.com/posts/20160516_port25_announces_release_of_powermta_v45r5/ I guess that the matter is to create a daemon receiving MX information from smtp clients and making them available to the scheduler. Thanks in advance Marco
Re: SMTP connection reuse with TLS
On Wed, Aug 2, 2017 at 6:57 PM, mark burdett wrote: > That's true, as a work-around. Unfortunately we're talking about not just > opening a new TCP connection but also reestablishing TLS, which means yet > more RTT and CPU. So the increased concurrency will be significant and > will require upping limits on the client and server side. I'm guessing > most folks in this scenario will prefer to code a lightweight SMTP worker > that can reuse connections, running at a lower concurrency. > > --mark B. > Don't take for granted that you can't optimize things. I have an important experience to share... I faced the same issue when enabling the SSL connection to the remote systems. My 220K email sending was lasting 2/3 hours more than without SSL. Now I can send 100K emails in 1h, with a single Postfix instance and a single sending IP address. On a virtual Linux machine on VMware. Have a look at: - smtp_tls_session_cache_database <-- this is the most important thing. I suggest lmdb as the backing store - if you are on Linux on virtual, also to RNGD/Haveged (the second being the best for speed) - making use of the most recent openssl major version you can afford to link postifx to - loading jemalloc as the memory allocator for all postfix processes Provided that the hard drive won't be an issue, you will see a considerable difference in the performance.
Re: SMTP connection reuse with TLS
On Wed, Aug 2, 2017 at 7:44 PM, Viktor Dukhovni wrote: > On Wed, Aug 02, 2017 at 07:11:23PM +0200, Marco Pizzoli wrote: > > > Have a look at: > > - smtp_tls_session_cache_database <-- this is the most important thing. > I > > suggest lmdb as the backing store > > Yes, but Berkeley DB also works well enough in practice. > I believe you. But my experience comparing the two in OpenLDAP is strongly toward lmdb. > - if you are on Linux on virtual, also to RNGD/Haveged (the second being > > the best for speed) > > I don't think this is good advice. Use the default entropy source: > > tls_random_source = dev:/dev/urandom > > and let the kernel take care of entropy. > I did not say to change the default entropy source configured in postfix. I only meant to "help" the /dev/random source by making use of (one of) those daemons. In virtual machines the entropy is really low. In my vmware machines I am at 300, compared to the maximum possible of 4000. Those daemons really do help. During one of my bulk-sendings I saw the rngd daemon popping up within "top", so to say it needed to do its job. > > - loading jemalloc as the memory allocator for all postfix processes > > This is unlikely to be a bottleneck for SMTP. The default malloc should > be just fine. Could be, but jemalloc (and tcmalloc) give also benefit for memory fragmentation, apart for the pure allocation speed. So in constrained memory systems more than in those with huge memory they make you at least not-losing-something in the long term. Or at least they should. > The only real tuning required for a dedicated upstream > is: > > - Enable the client-side SMTP TLS session cache > Confirm > - Make sure the upstream server supports session resumption, ideally > via session tickets, but a remote cache is also ok. > Confirm. Indeed I don't see all of them supporting it, unfortunately. > - Increase concurrency as required for the larger TLS > round-trip delay. If the average message size is large > enough, the latency increase will be small, and perhaps no > tuning is required. If the average message size is small, > a multiple of 2 or a bit more may be appropriate. > On this latest point I have to *in part* disagree... My experience makes me doubtful on just extending the concurrent connections towards the remote systems. I actually need to limit the concurrent connection number to my destinations in order to not be deferred due to the "too many connections from your IP". > > -- > Viktor. >
DKIM-Signing forwarded email
Hi all, I have a postfix instance dedicated to being the main MX (IN). I normally use other postfix instances for sending emails out (OUT). Of course, even this "IN" instance needs to send emails out, mainly bounces. Now I am also implementing forwarding rules: "if you receive an email destined to this address, than forward it out to this other email address". Other addresses are @gmail.com, @msn.com, etc... In order to do that "right" I also implemented an SRS service, so to have my domain as the envelope sending address. Now I also want to enable DKIM-signing of these outgoing emails. Problem is: - SRS (or at least the product I am using, postsrsd) works at the "cleanup" level, so after smtpd - My DKIM-signing tool is a milter, so acts at smtpd time. So the email it sees is with the original sending domain and not my domain. How can I achieve the intended behaviour? Thank you in advance for your help Marco
Re: Resolve before transport
On Fri, Sep 29, 2017 at 10:12 AM, Peter wrote: > Hi guys, > > I send my emails via different gateways based on my transport file. Many > domains, however, use the same email providers, such as outlook or > gmail. Is there a way to check the MX records before the email is sent > and transport it using a specific gateway? > I already asked in the past: http://postfix.1071664.n5.nabble.com/Feature-request-MX-rollup-td90800.html Marco > > Cheers, > Peter >
Re: SMTP session caching
Hello Wietse, I was reading this topic with interest because this issue affects me very much as well. I had a slowness issue when sending to @hotmail.* . I tried all the Microsoft services in order to check how I was seen from them and I got confirmation that I was OK. I received this information not only through MS SNDS[1] but also agreeing a sending window with one of their engineers who observed my actual sending and investigated evidence of troubles. During a massive sending I was able to complete all destinations in 1hour BUT Microsoft's. (and Apple's) By looking at my logs I was capable of noticing they were slowly accepting my TCP requests, or, said better, slowing down everything related to the connection establishment. To complete my sending to @hotmail.* I was spending more than 12 hours... I changed my client configuration, for that dedicated transport, disabling STARTTLS support and so making effectively use of the connection cache. y using the connection cache I managed to get that sending complete in approx 1hour. I then applied the same configuration for Apple domains and a couple of local national ISPs. I could afford to proceed like that because: 1. these emails are just marketing 2. those mailbox providers are not providing evidence to the end user that the email was sent in clear text instead of TLS-secured. Were they to do the same as Gmail does, the red lock to email received in plain text, I will need to revert my configuration and eventually get my sending slow again... Thank you in advance for everything you can develop in order to overcome this limitation. Marco P.s. As a side note: the second limitation I face in using Postfix for bulk email sending is the missing "MX-rollup" feature I already reported twice in this list: http://postfix.1071664.n5.nabble.com/Feature-request-MX-rollup-td90800.html [1] https://postmaster.live.com/snds/ <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virus-free. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#m_6573517841975336091_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Mon, Mar 19, 2018 at 4:28 PM, Wietse Venema wrote: > Emmanuel Fust?: > > Is there any document that describe how interprocess notification is > > done in postfix ? More precisely the scheduler -> delivery agent > > notification ? > > There is no public documentation for *internal* Postfix interfaces, > so that I can change that without breaking non-Postfix software > that depends on Postfix internals. > > I agree with Viktor that updating the TLS proxy is the more feasible > approach (caching the TLS sessions outside delivery agents). I also > don't believe in changing the scheduler-to-delivery agent protocol. > The Postfix approach is not to make an existing thing more complex, > but by combining less complex things together. > > Please provide quantitative evidence that connection reuse is > necessary to get mail into the 'big providers' (i.e. they punish > connection rate and message rate differently). > > Wietse >
SSL not working after unwanted server migration
Greetings, I had my personal postfix/dovecot server, configured for some of my own domains, running without problems on a linux VPS. For reasons totally out of my control, I had to migrate everything to another VPS two days ago, without notice, (details at the bottom if anybody is interested...), and consequently without any possibility to do the due homework and testing *BEFORE* the migration, so please be patient... The problem: since software and operating system versions are not the same as before, certain settings stopped working. So far the only major one I can't handle myself, both in dovecot and postfix, seems to be TLS/SSL configuration. I regenerated and installed a new SSL certificate with letsencrypt, but: - in dovecot, I can't connect because "ssl3_get_client_hello:no shared cipher", no matter which ciphers I configure (I've already asked about this on the dovecot list) - postfix receives email, but: - also gets lots of "454 4.7.0 TLS not available due to local problem" connecting to google servers - if I try to send email, I get this: Our system has detected that this message does 550-5.7.1 not meet IPv6 sending guidelines regarding PTR records and 550-5.7.1 authentication. Please review... As far as I can tell, this is a combination of postfix/dovecot settings not valid anymore + wrong file/folder permissions + maybe not compatible selinux (now set to "permissive"). I am already reading all the online resources I can find, but I find no clear consensus on what should be done. Any help is appreciated! Thanks, and here is the postfix configuration: I am running postfix 2.10.1 on Centos 7.6. Here is the output of postconf -n: alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin xxgdb $daemon_directory/$process_name $process_id & sleep 5 disable_vrfy_command = yes html_directory = /usr/share/doc/postfix-2.4.3-documentation/html inet_interfaces = all mail_owner = postfix mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man mydestination = $myhostname, localhost mydomain = $myhostname myhostname = a.mx.MYDOMAIN mynetworks = 127.0.0.0/8, 212.110.184.219 myorigin = $mydomain newaliases_path = /usr/bin/newaliases.postfix non_smtpd_milters = inet:localhost:8891 procmail_destination_recipient_limit = 1 queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.4.3-documentation/readme relay_domains = sample_directory = /etc/postfix sender_dependent_relayhost_maps = hash:/etc/postfix/mymaps/relayhost_maps sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtp_sasl_auth_enable = yes smtp_sasl_mechanism_filter = smtp_sasl_password_maps = hash:/etc/postfix/mymaps/sasl_passwd smtp_sasl_security_options = noanonymous smtp_sasl_tls_security_options = noanonymous smtp_sasl_type = cyrus smtp_sender_dependent_authentication = yes smtp_tls_security_level = may smtpd_helo_required = yes smtpd_helo_restrictions = smtpd_milters = inet:localhost:8891 smtpd_recipient_restrictions = reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_helo_access hash:/etc/postfix/reject_own_helo, check_policy_service unix:postgrey/socket smtpd_sasl_auth_enable = yes smtpd_sasl_path = /var/spool/postfix/private/auth smtpd_sasl_type = dovecot smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/letsencrypt/live/MYDOMAIN/fullchain.pem smtpd_tls_key_file = /etc/letsencrypt/live/MYDOMAIN/privkey.pem smtpd_tls_loglevel = 1 smtpd_tls_security_level = may strict_rfc821_envelopes = yes unknown_address_reject_code = 554 unknown_client_reject_code = 554 unknown_hostname_reject_code = 554 unknown_local_recipient_reject_code = 550 virtual_alias_maps = hash:/etc/postfix/mymaps/valias.map virtual_gid_maps = static:5000 virtual_mailbox_base = /var/mail/mymail_storage virtual_mailbox_domains = /etc/postfix/mymaps/vhosts.map virtual_mailbox_maps = hash:/etc/postfix/mymaps/vmailboxes.map virtual_transport = procmail virtual_uid_maps = static:5000 postconf: warning: /etc/postfix/main.cf: unused parameter: smtp_tls_auth_only=yes postconf: warning: /etc/postfix/master.cf: unused parameter: flags=D WHY THIS HAPPENED: A few weeks ago, the old VPS provider communicated that they were going out of business on Dec 8th. For several personal reasons not relevant here (short version: have simply been almost unable to work in the same weeks) I only discovered this... on Dec. 8th. I had no time at all to test anything. Saturday I bought a new VPS from another provider, changed DNS records to point there, set up a new SSL certificate with letsencrypt, copied all the files and mailbo
Re: SSL not working after unwanted server migration
Il giorno lun 10 dic 2018 alle ore 09:14 Robert Chalmers ha scritto: > > Google is refusing access because your ipv6 PTR does not map to your domain. > It’s the common (now) google reverse lookup failing. > ... thanks for the reminder. I know, but had temporarily forgotten due to how that this migration "crashed" on me without notice, the need to have that mapping. I have already contacted the provider of the new VPS to handle this. My doubts, and consequent need for help, about my postfix configuration remain, however. I do *believe* that I have done everything correctly wrt generating and installing letsencryptcertificates. However, I know for a fact that TLS/SSL is not working in dovecot, am not sure at all if the postfix TLS/SSL configuration is correct, or complete, and I also am not sure if the interwork between dovecot and postfix is configured correctly. I have found several pages with contrasting advice on how to set file ownership/ permissions for the certificate files so postfix can access them, and if / how selinux may have a part in theproblem (even if in my vps is set to "permissive" right now). So any further comment/check on my postconf -n output is still very welcome (as I said, right now I am running postfix 2.10.1, while the config files I am using are from a 2.5/2.6 installation, I do not remember exactly) Thanks, Marco > On 10 Dec 2018, at 8:08 am, Marco Fioretti wrote: > > Greetings, > > I had my personal postfix/dovecot server, configured for some of my > own domains, running without problems on a linux VPS. For reasons > totally out of my control, I had to migrate everything to another VPS > two days ago, without notice, (details at the bottom if anybody is > interested...), and consequently without any possibility to do the due > homework and testing *BEFORE* the migration, so please be patient... > > The problem: since software and operating system versions are not the > same as before, certain settings stopped working. So far the only > major one I can't handle myself, both in dovecot and postfix, seems to > be TLS/SSL configuration. I regenerated and installed a new SSL > certificate with letsencrypt, but: > > - in dovecot, I can't connect because "ssl3_get_client_hello:no shared > cipher", no matter which ciphers I configure (I've already asked about > this on the dovecot list) > > - postfix receives email, but: > - also gets lots of "454 4.7.0 TLS not available due to local > problem" connecting to google servers > > - if I try to send email, I get this: > >Our system has detected that this message does >550-5.7.1 not meet IPv6 sending guidelines regarding PTR > records and 550-5.7.1 authentication. Please review... > > As far as I can tell, this is a combination of postfix/dovecot > settings not valid anymore + wrong file/folder permissions + maybe not > compatible selinux (now set to "permissive"). I am already reading all > the online resources I can find, but I find no clear consensus on what > should be done. Any help is appreciated! > > Thanks, and here is the postfix configuration: > > I am running postfix 2.10.1 on Centos 7.6. Here is the output of postconf -n: > > alias_database = hash:/etc/aliases > alias_maps = hash:/etc/aliases > command_directory = /usr/sbin > config_directory = /etc/postfix > daemon_directory = /usr/libexec/postfix > debug_peer_level = 2 > debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin > xxgdb $daemon_directory/$process_name $process_id & sleep 5 > disable_vrfy_command = yes > html_directory = /usr/share/doc/postfix-2.4.3-documentation/html > inet_interfaces = all > mail_owner = postfix > mailq_path = /usr/bin/mailq.postfix > manpage_directory = /usr/share/man > mydestination = $myhostname, localhost > mydomain = $myhostname > myhostname = a.mx.MYDOMAIN > mynetworks = 127.0.0.0/8, 212.110.184.219 > myorigin = $mydomain > newaliases_path = /usr/bin/newaliases.postfix > non_smtpd_milters = inet:localhost:8891 > procmail_destination_recipient_limit = 1 > queue_directory = /var/spool/postfix > readme_directory = /usr/share/doc/postfix-2.4.3-documentation/readme > relay_domains = > sample_directory = /etc/postfix > sender_dependent_relayhost_maps = hash:/etc/postfix/mymaps/relayhost_maps > sendmail_path = /usr/sbin/sendmail.postfix > setgid_group = postdrop > smtp_sasl_auth_enable = yes > smtp_sasl_mechanism_filter = > smtp_sasl_password_maps = hash:/etc/postfix/mymaps/sasl_passwd > smtp_sasl_security_options = noanonymous > smtp_sasl_tls_security_options = noanonymous > smtp_sasl_type = cyrus > smtp_sender_dependent_authentication = yes > smtp_tls_security_level = may
Re: SSL not working after unwanted server migration
Hello Alice, see answers in line Il giorno lun 10 dic 2018 alle ore 12:09 Alice Wonder ha scritto: > > When trouble shooting on systems with SELinux I put it in permissive mode - > setenforce 0 this is already the case on the new VPS (FWIW, I personally share your feelingsabout selinux in general, but that is another story..) > For cert permissions, I use ownership of root:root with 644 on the cert > and root:root with 400 on the private key. And I keep them in > /etc/pki/tls structure with /etc/pki/tls/private being a directory only > root can read (and the private key is in that directory) I just changed my permission in the same way, except that the files are in another folder (does it make any difference? It shouldn't right?), i.e. the same where letsencrypt/certbot put them: -r. 1 root root 3546 Dec 7 11:59 fullchain1.pem -rw-r--r--. 1 root root 1704 Dec 7 11:59 privkey1.pem and FWIW, as far as dovecot is concerned, this did not change things a bit, , I still can't get the "no shared cipher" abort message, even if dovecot/postfix config should point to/have the same config for these keys, right? This part is really confusing. Not sure if I can test anything more on the postfix side, until the reverse pointer gets updated in DNS. Or not? Thanks, Marco > > Postfix and Dovecot in CentOS systems work fine with that even though > the daemon runs as user postfix group postfix. > > On 12/10/18 2:45 AM, Marco Fioretti wrote: > > Il giorno lun 10 dic 2018 alle ore 09:14 Robert Chalmers > > ha scritto: > > > >> > >> Google is refusing access because your ipv6 PTR does not map to your > >> domain. > >> It’s the common (now) google reverse lookup failing. > >> ... > > > > thanks for the reminder. > > > > I know, but had temporarily forgotten due to how that this migration > > "crashed" on me > > without notice, the need to have that mapping. I have already > > contacted the provider > > of the new VPS to handle this. > > > > My doubts, and consequent need for help, about my postfix configuration > > remain, > > however. I do *believe* that I have done everything correctly wrt > > generating and > > installing letsencryptcertificates. > > > > However, I know for a fact that TLS/SSL is not working in dovecot, am not > > sure at all if the postfix TLS/SSL configuration is correct, or > > complete, and I also am not sure if the interwork between dovecot and > > postfix is configured correctly. > > > > I have found several pages with contrasting advice on how to set file > > ownership/ > > permissions for the certificate files so postfix can access them, and if / > > how > > selinux may have a part in theproblem (even if in my vps is set to > > "permissive" > > right now). So any further comment/check on my postconf -n output is still > > very welcome (as I said, right now I am running postfix 2.10.1, while > > the config files I am using are from a > > 2.5/2.6 installation, I do not remember exactly) > > > > Thanks, > > Marco > > > > > > > > > > > >> On 10 Dec 2018, at 8:08 am, Marco Fioretti > >> wrote: > >> > >> Greetings, > >> > >> I had my personal postfix/dovecot server, configured for some of my > >> own domains, running without problems on a linux VPS. For reasons > >> totally out of my control, I had to migrate everything to another VPS > >> two days ago, without notice, (details at the bottom if anybody is > >> interested...), and consequently without any possibility to do the due > >> homework and testing *BEFORE* the migration, so please be patient... > >> > >> The problem: since software and operating system versions are not the > >> same as before, certain settings stopped working. So far the only > >> major one I can't handle myself, both in dovecot and postfix, seems to > >> be TLS/SSL configuration. I regenerated and installed a new SSL > >> certificate with letsencrypt, but: > >> > >> - in dovecot, I can't connect because "ssl3_get_client_hello:no shared > >> cipher", no matter which ciphers I configure (I've already asked about > >> this on the dovecot list) > >> > >> - postfix receives email, but: > >>- also gets lots of "454 4.7.0 TLS not available due to local > >> problem" connecting to google servers > >> > >>- if I try to send email, I get this: > >> > >> Our system
Re: SSL not working after unwanted server migration
Hello Viktor, and all. This is only a partial answer to Viktor last email: Il giorno lun 10 dic 2018 alle ore 13:56 Viktor Dukhovni ha scritto: > > -r. 1 root root 3546 Dec 7 11:59 fullchain1.pem > > -rw-r--r--. 1 root root 1704 Dec 7 11:59 privkey1.pem > > This looks rather odd. You're keeping your public certificate chain > protected, but making the keys world-readable??? the setting of privkey to 644 comes from one of Alice's answers (I may have misinterpreted it, of course, but that is where it comes from). About all the other suggestions: This afternoon I have urgent family matters to attend, not sure if I will able to test and report before tomorrow afternoon about all the other advice I got so far. Any further comment or tip that comes in the meantime is welcome,of course. Tonight or tomorrow I will print out all the answers, and try to re-apply them from scratch, starting with a new, default configuration file. For now, I want to thank everybody again for all the hand-holding I am requesting, and will likely need for a few more days. In normal circumstances, I would have taken and planned this migration as a nice occasion to refresh, without hurrying, all my sisadmin skills. As it went, the server was literally pulled off under my feet, in a period when, theoretically, I should slow down and focus on non-work matters. But I need to restore email anyway asap, and right now it feels as being forced to solve a puzzle without knowing what it represents... Later, Marco
part 2 of: SSL not working after unwanted server migration
hello all, this is the same server, same situation for which I asked for help yesterday. Right now, after trying to test and follow up the advice received, this is the status: IMAPS: not working yet because of SSL "no shared cipher". Details here: https://dovecot.org/pipermail/dovecot/2018-December/113862.html POSTFIX: with the current configuration (see postconf -n output below) it seems I can: * receive email from all the mailing lists/newsletters I am subscribed to * connect with mutt from my home computer, and send email through this server to any other MTA I could use for testing, with two "exceptions": gmail still refuses connection, see below what I got from the last test a few minutes ago one server does accepts and deliver my messages, but flags them as spam (no idea why, all I see is a "X-Spam-Flag: YES" header... NOTIFICATION BY GMAIL: : host gmail-smtp-in.l.google.com[2a00:1450:400c:c0c::1b] said: 550-5.7.1 [] Our system has detected that this message does 550-5.7.1 not meet IPv6 sending guidelines regarding PTR records and 550-5.7.1 authentication. Please review 550-5.7.1 https://support.google.com/mail/?p=IPv6AuthError for more information 550 5.7.1 . t6si9122052wrw.74 - gsmtp (in reply to end of DATA command) Fact is, "" is the ipv6 address of the server for which I *did* add a reverse entry some hours ago (and I had done the same for the ipv4 dns record yesterday). In other words, I don't know what else I could / should do at this point on the DNS side. Here is the output of postconf -n: alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin xxgdb $daemon_directory/$process_name $process_id & sleep 5 disable_vrfy_command = yes html_directory = /usr/share/doc/postfix-2.4.3-documentation/html inet_interfaces = all mail_owner = postfix mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man mydestination = $myhostname, localhost mydomain = $myhostname myhostname = a.mx.MYDOMAIN mynetworks = 127.0.0.0/8, my.home.ip.address myorigin = $mydomain newaliases_path = /usr/bin/newaliases.postfix non_smtpd_milters = inet:localhost:8891 procmail_destination_recipient_limit = 1 queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.4.3-documentation/readme relay_domains = sample_directory = /etc/postfix sender_dependent_relayhost_maps = hash:/etc/postfix/mymaps/relayhost_maps sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtp_sasl_auth_enable = yes smtp_sasl_mechanism_filter = smtp_sasl_password_maps = hash:/etc/postfix/mymaps/sasl_passwd smtp_sasl_security_options = noanonymous smtp_sasl_tls_security_options = noanonymous smtp_sasl_type = cyrus smtp_sender_dependent_authentication = yes smtp_tls_security_level = may smtpd_helo_required = yes smtpd_helo_restrictions = smtpd_milters = inet:localhost:8891 smtpd_recipient_restrictions = reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_helo_access hash:/etc/postfix/reject_own_helo, check_policy_service unix:postgrey/socket smtpd_sasl_auth_enable = yes smtpd_sasl_path = /var/spool/postfix/private/auth smtpd_sasl_type = dovecot smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/letsencrypt/archive/MYDOMAIN/fullchain1.pem smtpd_tls_key_file = /etc/letsencrypt/archive/MYDOMAIN/privkey1.pem smtpd_tls_loglevel = 1 smtpd_tls_security_level = may strict_rfc821_envelopes = yes unknown_address_reject_code = 554 unknown_client_reject_code = 554 unknown_hostname_reject_code = 554 unknown_local_recipient_reject_code = 550 virtual_alias_maps = hash:/etc/postfix/mymaps/valias.map virtual_gid_maps = static:5000 virtual_mailbox_base = /var/mail/mymail_storage virtual_mailbox_domains = /etc/postfix/mymaps/vhosts.map virtual_mailbox_maps = hash:/etc/postfix/mymaps/vmailboxes.map virtual_transport = procmail virtual_uid_maps = static:5000 postconf: warning: /etc/postfix/main.cf: unused parameter: smtp_tls_auth_only=yes
Re: part 2 of: SSL not working after unwanted server migration
that problem with Dovecot is solved. It was caused by missing (not sure why/how) the "include conf.d/*" line in dovecot.conf, so the ssl configuration simply was not loaded. Now with dovecot, if anybody is interested, I have this other question about how to configure permissions properly between dovecot and postfix: https://dovecot.org/pipermail/dovecot/2018-December/113868.html with postfix proper, instead, the only or main problem right now seems to be the reverse DNS configuration, as I reported in my previous email Il giorno mar 11 dic 2018 alle ore 12:03 Benny Pedersen ha scritto: > > Marco Fioretti skrev den 2018-12-11 11:35: > > > IMAPS: not working yet because of SSL "no shared cipher". Details > > here: https://dovecot.org/pipermail/dovecot/2018-December/113862.html > > current SSL dovecot settings in conf.d/10-ssl.conf > > is missing in dovecot -n > > ask a centos maintainer for dovecot to solve that, check dovecot config > files in /etc/dovecot/ > > make sure thay match what is intended from the maintainer before you > edit it > > does dovecot.conf have last line !include. ? > > do you have stale old config files ? > > sorry cant help more
Re: part 2 of: SSL not working after unwanted server migration
Hello, all. I have added or edited as suggested in main.cf all the settings that Robert mentions in his reply below. Right now, "postfix check" only returns ~10 warnings all equal to " /etc/postfix/master.cf: unused parameter: flags=D" everything is working OK on the imap/dovecot side (except some minor issues I will deal with later). The only problem that remains is the one with gmail, but I have something new to report. Using example.com as domain name placeholder, the DNS record may be OK now (please confirm): a) it includes a text entry for "example.com:google-site-verification..." as Google b) there is a reverse IPv6 entry, and it has propagated. About 20 minutes ago, "host did start to return exactly "example.com" BUT: I only realized now that the rejection email I get when I try to send email as ma...@example.com to my gmail address says: Reporting-MTA: dns; a.mx.example.com this in turn led me to realize that the value of myhostname in main.cf is "a.mx.example.com", NOT just "example.com" as it says in the DNS records (*). To test myself, I changed myhostname to example.com, but after restart I get messages to me bounced because ma...@example.com is "User unknown in local recipient table". So, is just "example.com" the right value for myhostname, and if yes, how to fix the user unknown error? Here is the current output of postconf -n: alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin xxgdb $daemon_directory/$process_name $process_id & sleep 5 disable_vrfy_command = yes html_directory = /usr/share/doc/postfix-2.4.3-documentation/html inet_interfaces = all inet_protocols = ipv6, ipv4 mail_owner = postfix mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man mydestination = $myhostname, localhost mydomain = $myhostname myhostname = example.com mynetworks = 127.0.0.0/8, my.ip.home.address myorigin = $mydomain newaliases_path = /usr/bin/newaliases.postfix non_smtpd_milters = inet:localhost:8891 procmail_destination_recipient_limit = 1 queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.4.3-documentation/readme relay_domains = sample_directory = /etc/postfix sender_dependent_relayhost_maps = hash:/etc/postfix/mymaps/relayhost_maps sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtp_address_preference = ipv6 smtp_sasl_auth_enable = yes smtp_sasl_mechanism_filter = smtp_sasl_password_maps = hash:/etc/postfix/mymaps/sasl_passwd smtp_sasl_security_options = noanonymous smtp_sasl_tls_security_options = noanonymous smtp_sasl_type = cyrus smtp_sender_dependent_authentication = yes smtp_tls_mandatory_ciphers = high smtp_tls_security_level = may smtpd_helo_required = yes smtpd_helo_restrictions = smtpd_milters = inet:localhost:8891 smtpd_recipient_restrictions = reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_helo_access hash:/etc/postfix/reject_own_helo, check_policy_service unix:postgrey/socket smtpd_sasl_auth_enable = yes smtpd_sasl_path = /var/spool/postfix/private/auth smtpd_sasl_type = dovecot smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/letsencrypt/archive/example.com/fullchain1.pem smtpd_tls_ciphers = medium smtpd_tls_exclude_ciphers = SSLv2, aNULL, ADH, eNULL smtpd_tls_key_file = /etc/letsencrypt/archive/example.com/privkey1.pem smtpd_tls_loglevel = 1 smtpd_tls_security_level = may smtpd_use_tls = yes strict_rfc821_envelopes = yes unknown_address_reject_code = 554 unknown_client_reject_code = 554 unknown_hostname_reject_code = 554 unknown_local_recipient_reject_code = 550 virtual_alias_maps = hash:/etc/postfix/mymaps/valias.map virtual_gid_maps = static:5000 virtual_mailbox_base = /var/mail/mymail_storage virtual_mailbox_domains = /etc/postfix/mymaps/vhosts.map virtual_mailbox_maps = hash:/etc/postfix/mymaps/vmailboxes.map virtual_transport = procmail virtual_uid_maps = static:1001 postconf: warning: /etc/postfix/master.cf: unused parameter: flags=D THANKS, Marco (*) please don't ask why this mismatch... it is one more of the things that I had no time to check myself because I had to migrate without advice...) Il giorno mar 11 dic 2018 alle ore 13:16 Robert Chalmers ha scritto: > > > > > Hi again. > > The following settings are from my server. They may not necessarily work with > yours. > > # Smtpd means mails you receive from outside, smtp covers mails you send to > other servers. > > > The notification from Google is telling you that your Reverse DNS does not > point to your s
Re: part 2 of: SSL not working after unwanted server migration
here it is:
postconf -Mf
smtp inet n - n - - smtpd
submission inet n - n - - smtpd
-o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes
-o
smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
smtps inet n - n - - smtpd
-o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
628inet n - n - - qmqpd
pickup fifo n - n 60 1 pickup
cleanupunix n - n - 0 cleanup
qmgr fifo n - n 300 1 qmgr
tlsmgr unix - - n 1000? 1 tlsmgr
rewriteunix - - n - - trivial-rewrite
bounce unix - - n - 0 bounce
defer unix - - n - 0 bounce
trace unix - - n - 0 bounce
verify unix - - n - 1 verify
flush unix n - n 1000? 0 flush
proxymap unix - - n - - proxymap
smtp unix - - n - - smtp
relay unix - - n - - smtp
-o fallback_relay=
showq unix n - n - - showq
error unix - - n - - error
retry unix - - n - - error
discardunix - - n - - discard
local unix - n n - - local
virtualunix - n n - - virtual
lmtp unix - - n - - lmtp
anvil unix - - n - 1 anvil
scache unix - - n - 1 scache
procmail unix - n n - - pipe -o flags=D
user=myvmail_user argv=/usr/bin/procmail -t -m USER=${recipient}
EXTENSION=${extension} /usr/local/etc/procmailrc.common
here it
Il giorno mar 11 dic 2018 alle ore 15:51 Robert Chalmers
ha scritto:
>
> Do a
> postconf -Mf
>
> to show your master.cf file configuration.
>
>
>
> On 11 Dec 2018, at 14:47, Robert Chalmers wrote:
>
> Where/what is the -D in your master.cf file
>
>
>
>
> On 11 Dec 2018, at 14:35, Marco Fioretti wrote:
>
> /etc/postfix/master.cf: unused
> parameter: flags=D"
>
>
>
Re: part 2 of: SSL not working after unwanted server migration
Hello Robert,
there is no "-D" in master.cf, only "=D".
IN any case... I don't know what to answer.
By this I mean that I put together this procmail line in master.cf:
procmail unix - n n - - pipe -o
flags=D user=myvmail_user argv=/usr/bin/procmail -t -m
USER=${recipient} EXTENSION=${extension}
/usr/local/etc/procmailrc.common
(with "=D", not "-D") maybe 10 years ago, in order to filter all
incoming email with procmail, following advice from procmail and
postfix mailing lists. Since then, and until 4 days ago, it had always
worked as expected, and never given me reasons to remember its
existence. Do you mean that the "flags=D" setting is obsolete in the
current version of postfix?
Marco
Il giorno mar 11 dic 2018 alle ore 16:36 Robert Chalmers
ha scritto:
>
> You may actually have a -D where you should have a -d
>
>
>
>
>
> On 11 Dec 2018, at 14:57, Marco Fioretti wrote:
>
> here it is:
>
> postconf -Mf
> smtp inet n - n - - smtpd
> submission inet n - n - - smtpd
>-o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes
>-o
> smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
> smtps inet n - n - - smtpd
>-o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
>-o smtpd_client_restrictions=permit_sasl_authenticated,reject
> 628inet n - n - - qmqpd
> pickup fifo n - n 60 1 pickup
> cleanupunix n - n - 0 cleanup
> qmgr fifo n - n 300 1 qmgr
> tlsmgr unix - - n 1000? 1 tlsmgr
> rewriteunix - - n - - trivial-rewrite
> bounce unix - - n - 0 bounce
> defer unix - - n - 0 bounce
> trace unix - - n - 0 bounce
> verify unix - - n - 1 verify
> flush unix n - n 1000? 0 flush
> proxymap unix - - n - - proxymap
> smtp unix - - n - - smtp
> relay unix - - n - - smtp
>-o fallback_relay=
> showq unix n - n - - showq
> error unix - - n - - error
> retry unix - - n - - error
> discardunix - - n - - discard
> local unix - n n - - local
> virtualunix - n n - - virtual
> lmtp unix - - n - - lmtp
> anvil unix - - n - 1 anvil
> scache unix - - n - 1 scache
> procmail unix - n n - - pipe -o flags=D
>user=myvmail_user argv=/usr/bin/procmail -t -m USER=${recipient}
>EXTENSION=${extension} /usr/local/etc/procmailrc.common
> here it
> Il giorno mar 11 dic 2018 alle ore 15:51 Robert Chalmers
> ha scritto:
>
>
> Do a
> postconf -Mf
>
> to show your master.cf file configuration.
>
>
>
> On 11 Dec 2018, at 14:47, Robert Chalmers wrote:
>
> Where/what is the -D in your master.cf file
>
>
>
>
> On 11 Dec 2018, at 14:35, Marco Fioretti wrote:
>
> /etc/postfix/master.cf: unused
> parameter: flags=D"
>
>
>
>
> Robert Chalmers
> https://robert-chalmers.uk
> aut...@robert-chalmers.uk
> @R_A_Chalmers
>
Re: part 2 of: SSL not working after unwanted server migration
I confess I do not know how to check that. The output of which command
should I turn verbose?
Thanks
Il giorno mar 11 dic 2018 alle ore 16:57 Robert Chalmers
ha scritto:
>
>
> No no. That line is quite different.
>
> -D is not it.
> Are you starting master with a -D maybe.
>
> Like /use/sbin/master -D type of thing?
>
> Turn on verbose output with a -v and see if you can catch it.
>
>
>
>
> -
>
>
>
> > On 11 Dec 2018, at 3:49 pm, Marco Fioretti wrote:
> >
> > Hello Robert,
> > there is no "-D" in master.cf, only "=D".
> > IN any case... I don't know what to answer.
> >
> > By this I mean that I put together this procmail line in master.cf:
> >
> > procmail unix - n n - - pipe -o
> > flags=D user=myvmail_user argv=/usr/bin/procmail -t -m
> > USER=${recipient} EXTENSION=${extension}
> > /usr/local/etc/procmailrc.common
> >
> > (with "=D", not "-D") maybe 10 years ago, in order to filter all
> > incoming email with procmail, following advice from procmail and
> > postfix mailing lists. Since then, and until 4 days ago, it had always
> > worked as expected, and never given me reasons to remember its
> > existence. Do you mean that the "flags=D" setting is obsolete in the
> > current version of postfix?
> >
> > Marco
> > Il giorno mar 11 dic 2018 alle ore 16:36 Robert Chalmers
> > ha scritto:
> >>
> >> You may actually have a -D where you should have a -d
> >>
> >>
> >>
> >>
> >>
> >> On 11 Dec 2018, at 14:57, Marco Fioretti wrote:
> >>
> >> here it is:
> >>
> >> postconf -Mf
> >> smtp inet n - n - - smtpd
> >> submission inet n - n - - smtpd
> >> -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes
> >> -o
> >> smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
> >> smtps inet n - n - - smtpd
> >> -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
> >> -o smtpd_client_restrictions=permit_sasl_authenticated,reject
> >> 628inet n - n - - qmqpd
> >> pickup fifo n - n 60 1 pickup
> >> cleanupunix n - n - 0 cleanup
> >> qmgr fifo n - n 300 1 qmgr
> >> tlsmgr unix - - n 1000? 1 tlsmgr
> >> rewriteunix - - n - - trivial-rewrite
> >> bounce unix - - n - 0 bounce
> >> defer unix - - n - 0 bounce
> >> trace unix - - n - 0 bounce
> >> verify unix - - n - 1 verify
> >> flush unix n - n 1000? 0 flush
> >> proxymap unix - - n - - proxymap
> >> smtp unix - - n - - smtp
> >> relay unix - - n - - smtp
> >> -o fallback_relay=
> >> showq unix n - n - - showq
> >> error unix - - n - - error
> >> retry unix - - n - - error
> >> discardunix - - n - - discard
> >> local unix - n n - - local
> >> virtualunix - n n - - virtual
> >> lmtp unix - - n - - lmtp
> >> anvil unix - - n - 1 anvil
> >> scache unix - - n - 1 scache
> >> procmail unix - n n - - pipe -o flags=D
> >> user=myvmail_user argv=/usr/bin/procmail -t -m USER=${recipient}
> >> EXTENSION=${extension} /usr/local/etc/procmailrc.common
> >> here it
> >> Il giorno mar 11 dic 2018 alle ore 15:51 Robert Chalmers
> >> ha scritto:
> >>
> >>
> >> Do a
> >> postconf -Mf
> >>
> >> to show your master.cf file configuration.
> >>
> >>
> >>
> >> On 11 Dec 2018, at 14:47, Robert Chalmers wrote:
> >>
> >> Where/what is the -D in your master.cf file
> >>
> >>
> >>
> >>
> >> On 11 Dec 2018, at 14:35, Marco Fioretti wrote:
> >>
> >> /etc/postfix/master.cf: unused
> >> parameter: flags=D"
> >>
> >>
> >>
> >>
> >> Robert Chalmers
> >> https://robert-chalmers.uk
> >> aut...@robert-chalmers.uk
> >> @R_A_Chalmers
> >>
Re: part 2 of: SSL not working after unwanted server migration
OK, I removed that part of the procmail line, and restarted. Here is
output of postconf -Mf and, respectively, postconf -n
(just for my own knowledge: this has nothing to do with the ipv6
complaints from google, or has it?)
Thanks,
Marco
###
smtp inet n - n - - smtpd
submission inet n - n - - smtpd
-o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes
-o
smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
smtps inet n - n - - smtpd
-o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
628inet n - n - - qmqpd
pickup fifo n - n 60 1 pickup
cleanupunix n - n - 0 cleanup
qmgr fifo n - n 300 1 qmgr
tlsmgr unix - - n 1000? 1 tlsmgr
rewriteunix - - n - - trivial-rewrite
bounce unix - - n - 0 bounce
defer unix - - n - 0 bounce
trace unix - - n - 0 bounce
verify unix - - n - 1 verify
flush unix n - n 1000? 0 flush
proxymap unix - - n - - proxymap
smtp unix - - n - - smtp
relay unix - - n - - smtp
-o fallback_relay=
showq unix n - n - - showq
error unix - - n - - error
retry unix - - n - - error
discardunix - - n - - discard
local unix - n n - - local
virtualunix - n n - - virtual
lmtp unix - - n - - lmtp
anvil unix - - n - 1 anvil
scache unix - - n - 1 scache
procmail unix - n n - - pipe
-o user=myvmail_user argv=/usr/bin/procmail -t -m USER=${recipient}
EXTENSION=${extension} /usr/local/etc/procmailrc.common
##
postconf -n
47.53.159.60
Il giorno mar 11 dic 2018 alle ore 17:26 Robert Chalmers
ha scritto:
>
> Hi
> I misread the output of postconf above
>
> returns ~10 warnings all equal to " /etc/postfix/master.cf: unused
> parameter: flags=D"
>
> Remove the ‘flags=D’ and restart. Then do a post one -MF again
>
> Remember, you have to restart postfix to load master, not just reload.
>
> Robert
>
>
>
> __
> Robert Chalmers
> https://robert-chalmers.uk
> aut...@robert-chalmers.uk
> @R_A_Chalmers
>
> On 11 Dec 2018, at 4:12 pm, Marco Fioretti wrote:
>
> I confess I do not know how to check that. The output of which command
> should I turn verbose?
>
> Thanks
> Il giorno mar 11 dic 2018 alle ore 16:57 Robert Chalmers
> ha scritto:
>
>
>
> No no. That line is quite different.
>
>
> -D is not it.
>
> Are you starting master with a -D maybe.
>
>
> Like /use/sbin/master -D type of thing?
>
>
> Turn on verbose output with a -v and see if you can catch it.
>
>
>
>
>
> -
>
>
>
>
> On 11 Dec 2018, at 3:49 pm, Marco Fioretti wrote:
>
>
> Hello Robert,
>
> there is no "-D" in master.cf, only "=D".
>
> IN any case... I don't know what to answer.
>
>
> By this I mean that I put together this procmail line in master.cf:
>
>
> procmail unix - n n - - pipe -o
>
> flags=D user=myvmail_user argv=/usr/bin/procmail -t -m
>
> USER=${recipient} EXTENSION=${extension}
>
> /usr/local/etc/procmailrc.common
>
>
> (with "=D", not "-D") maybe 10 years ago, in order to filter all
>
> incoming email with procmail, following advice from procmail and
>
> postfix mailing lists. Since then, and until 4 days ago, it had always
>
> worked as expected, and never given me reasons to remember its
>
> existence. Do you mean that the "flags=D" setting is obsolete in the
>
> current version of postfix?
>
>
> Marco
>
> Il giorno mar 11 dic 2018 alle ore 16:36 Robert Chalmers
>
> ha scritto:
>
>
> You may actually have a -D where you should have a -d
>
>
>
>
>
>
> On 11 Dec 2018, at 14:57, Marco Fioretti wrote:
>
>
> here it is:
>
>
> postconf -Mf
>
> smtp inet
Re: part 2 of: SSL not working after unwanted server migration
Il giorno mar 11 dic 2018 alle ore 17:03 Matus UHLAR - fantomas
ha scritto:
> the "flags" is supposed to be indented, since it is continuation of
> "procmail" line:
>
>
> procmail unix - n n - - pipe -o
> flags=D user=myvmail_user argv=/usr/bin/procmail -t -m
> USER=${recipient} EXTENSION=${extension}
> /usr/local/etc/procmailrc.common
maybe it came out as indented when copying/pasting/replying in email,
but it is NOT indented in the file. All that stuff has been on one line for,
as I said, ~10 years now.
> ... Do you mean that the "flags=D" setting is obsolete in the
> >current version of postfix?
>
> it's not obsolete, but the filtering through procmail like this apparently is.
OK, as long as the functionality remains the same, I certainly don't mind
removing that part of the line!
But if you check the output of postconf -Mf that I posted a few minutes ago...
now the question becomes "why there is a warning about "user=myvmail_user"?
As far as I can see, this postfix+procmail part of the system is
working as expected now. It
is "only" gmail interfacing and webmail configuration that are still giving me
pains.
Marco
Re: part 2 of: SSL not working after unwanted server migration
OK, let's wait for the PTR record. After all, one of the advantages of email is that it is not real time, right? One thing I still have not clear, however, is what I reported about the mismatch between example.com in the DNS records, and a.mx.example.com as value of $myhostname. Comments on that? Postconf -n is below , sorry that I forgot it earlier. back to the master.cf configuration: as soon as I removed the "flags=D" part, I started getting the errors below, so I put it back. Your comments are welcome, I confess I'm totally lost on this bit. Apart from being sure that a postconf warning is much less important than email not being filtered, that is... postconf -n: alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin xxgdb $daemon_directory/$process_name $process_id & sleep 5 disable_vrfy_command = yes html_directory = /usr/share/doc/postfix-2.4.3-documentation/html inet_interfaces = all inet_protocols = ipv6, ipv4 mail_owner = postfix mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man mydestination = $myhostname, localhost mydomain = $myhostname myhostname = a.mx.example.com mynetworks = 127.0.0.0/8, myhomeipaddress myorigin = $mydomain newaliases_path = /usr/bin/newaliases.postfix non_smtpd_milters = inet:localhost:8891 procmail_destination_recipient_limit = 1 queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.4.3-documentation/readme relay_domains = sample_directory = /etc/postfix sender_dependent_relayhost_maps = hash:/etc/postfix/mymaps/relayhost_maps sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtp_address_preference = ipv6 smtp_sasl_auth_enable = yes smtp_sasl_mechanism_filter = smtp_sasl_password_maps = hash:/etc/postfix/mymaps/sasl_passwd smtp_sasl_security_options = noanonymous smtp_sasl_tls_security_options = noanonymous smtp_sasl_type = cyrus smtp_sender_dependent_authentication = yes smtp_tls_mandatory_ciphers = high smtp_tls_security_level = may smtpd_helo_required = yes smtpd_helo_restrictions = smtpd_milters = inet:localhost:8891 smtpd_recipient_restrictions = check_client_access cidr:/etc/postfix/client_checks, reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_helo_access hash:/etc/postfix/reject_own_helo, check_policy_service unix:postgrey/socket smtpd_sasl_auth_enable = yes smtpd_sasl_path = /var/spool/postfix/private/auth smtpd_sasl_type = dovecot smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/letsencrypt/archive/example.com/fullchain1.pem smtpd_tls_ciphers = medium smtpd_tls_exclude_ciphers = SSLv2, aNULL, ADH, eNULL smtpd_tls_key_file = /etc/letsencrypt/archive/example.com/privkey1.pem smtpd_tls_loglevel = 1 smtpd_tls_security_level = may smtpd_use_tls = yes strict_rfc821_envelopes = yes unknown_address_reject_code = 554 unknown_client_reject_code = 554 unknown_hostname_reject_code = 554 unknown_local_recipient_reject_code = 550 virtual_alias_maps = hash:/etc/postfix/mymaps/valias.map virtual_gid_maps = static:5000 virtual_mailbox_base = /var/mail/mymail_storage virtual_mailbox_domains = /etc/postfix/mymaps/vhosts.map virtual_mailbox_maps = hash:/etc/postfix/mymaps/vmailboxes.map virtual_transport = procmail virtual_uid_maps = static:1001 ERRORS after removing "flags=D" from the procmail line in master.cf: Dec 11 17:41:00 example.com postfix/qmgr[30169]: warning: private/procmail socket: malformed response Dec 11 17:41:00 example.com postfix/qmgr[30169]: warning: transport procmail failure -- see a previous warning/fatal/panic logfile record for th e problem description Dec 11 17:41:00 example.com postfix/master[30167]: warning: process /usr/libexec/postfix/pipe pid 30219 exit status 1 Dec 11 17:41:00 example.com postfix/master[30167]: warning: /usr/libexec/postfix/pipe: bad command startup -- throttling Dec 11 17:41:00 example.com postfix/error[30220]: B9FB01F797: to=, relay=none, delay=1.2, delays=0.19/1/0/0.02, dsn=4.3.0 , status=deferred (unknown mail transport error) Il giorno mar 11 dic 2018 alle ore 17:54 Robert Chalmers ha scritto: > > Ok, > Looking better. > > And no. Nothing to do with Google. > If you have your PTR record configured properly, it could take up to 24 or > even 48 hours to propagate. It shouldn’t but it can. > > So just be patient on that one for now :-) > > You didn’t include the postconf -n by the way... > > Robert > > > > > > > __ > Robert Chalmers > https://robert-chalmers.uk > aut...@robert-chalmers.uk > @R_A_Chalmers > > On 11 Dec 2018, at 4:44 pm, Marc
Re: part 2 of: SSL not working after unwanted server migration
the 47.53.. address is only the current address of my home laptop. The
server we are talking about is a VPS in a datacentre. And reverse
lookup of the IPv4 and v6 addresses of that server already both return
the domain name "example.com", which as I said is not exactly the same
as the value of $myhostname, which is "a.mx.example.com" and makes me
suspect that may be the problem, rather than delays in dns
propagation.
by "turning ipv6 off" I assume you mean changing "inet_protocols =
ipv6, ipv4" to "inet_protocols = ipv4" and commenting out
"smtp_address_preference = ipv6", I guess?
Thanks
Il giorno mar 11 dic 2018 alle ore 18:09 Robert Chalmers
ha scritto:
>
>
> Ok, I see no warnings in your
> postconf -Mf ???
>
> It looks good to me.
>
> If that ip address you show is your’s, then you will never have a valid PTR
> record on it, because it belongs to your ISP.
>
> host 47.53.159.60
> 60.159.53.47.in-addr.arpa domain name pointer
> net-47-53-159-60.cust.vodafonedsl.it.
>
> dig +short net-47-53-159-60.cust.vodafonedsl.it
> 47.53.159.60
>
>
> Gmail interfacing is always difficult. If you are running ipv6, and don’t
> need it, turn it off. Maybe Gmail will be ok then
>
> robert
>
>
>
>
>
>
> > On 11 Dec 2018, at 16:52, Marco Fioretti wrote:
> >
> > Il giorno mar 11 dic 2018 alle ore 17:03 Matus UHLAR - fantomas
> > ha scritto:
> >
> >> the "flags" is supposed to be indented, since it is continuation of
> >> "procmail" line:
> >>
> >>
> >> procmail unix - n n - - pipe -o
> >>flags=D user=myvmail_user argv=/usr/bin/procmail -t -m
> >>USER=${recipient} EXTENSION=${extension}
> >>/usr/local/etc/procmailrc.common
> >
> > maybe it came out as indented when copying/pasting/replying in email,
> > but it is NOT indented in the file. All that stuff has been on one line for,
> > as I said, ~10 years now.
> >> ... Do you mean that the "flags=D" setting is obsolete in the
> >>> current version of postfix?
> >>
> >> it's not obsolete, but the filtering through procmail like this apparently
> >> is.
> >
> > OK, as long as the functionality remains the same, I certainly don't mind
> > removing that part of the line!
> >
> > But if you check the output of postconf -Mf that I posted a few minutes
> > ago...
> > now the question becomes "why there is a warning about "user=myvmail_user"?
> >
> > As far as I can see, this postfix+procmail part of the system is
> > working as expected now. It
> > is "only" gmail interfacing and webmail configuration that are still giving
> > me
> > pains.
> >
> > Marco
>
> Robert Chalmers
> https://robert-chalmers.uk
> aut...@robert-chalmers.uk
> @R_A_Chalmers
>
Re: part 2 of: SSL not working after unwanted server migration
Hello Viktor, and thanks for this: > The syntax is wrong, the "-o" is not followed by any valid main.cf parameter > override. The "flags=" parameter to pipe(8) is not a main.cf parameter. > > The solution is to remove the dangling "-o". I confirm that doing so removes the warning in postconf -n, but keeps procmail working properly. So even this part of the puzzle is solved. About this: > In the meantime, you still HAVE NOT posted the logs that show smtpd(8) > complaining about being unable to initialize TLS. right now, my brain is toast from trying to do both normal work AND this in parallel (allow me to say again that this migration fell on me with no notice at all). THerefore, I have very likely missed that particular request so far. This said, I have checked /var/log/maillog. IN the last 3/4 hours, that is after the changes suggested earlier by Robert and others, I have restarted postfix 15/20 times, and the only lines that contain the "postfix/smtpd" and a warning or error message are of two types. One is connection attempts from some spam server that are rejected because that server 'does not resolve to address'. The second type is the notifications from gmail that they won't accept my email because of the ipv6 mismatch I already reported. If I misunderstood what you are asking, please tell me where/how to get it, no problem. Ditto if you want to receive the complete log privately, without any editing. Thanks in advance, Marco
Almost done with new server, was: SSL not working after unwanted server migratio
Hello! first of all, thanks again to everybody who helped, both on and off-list! Right now, the original SSL problems seem all gone, and after turning off ipv6 even gmail started to accept my email. Now I can connect with mutt from home, access mailboxes over imaps, send email using ssl/tls to any domain I have been able to try. To get there, I had as I said to turn off ipv6, as shown in postconf -n output below. Honestly, I have no idea if and what exactly I am missing by not using ipv6, thanks in advance to whoever steps in to explain. In any case, I can say that the configuration below seems to be a decent solution so far for running postfix 2.10 on Centos, for a small number of users and domains, and without running any rdbms. Next step is to figure out which between rainloop and roundcube is a better/easier/safer webmail to set up. General comments and/or tips on how to harden this, with stronger ciphers or other stuff, are very welcome. Ditto for pointers to online services to test if anything is OK wrt dkim, spf, dns, blacklists, greylisting... (I DO know some of them, but not sure if they are the most efficient). If anybody feels like receiving one email from that server, just to confirm to me that everything is fine, please let me know. Thanks, and off to dinner and bed now... Marco postconf -n: alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin xxgdb $daemon_directory/$process_name $process_id & sleep 5 disable_vrfy_command = yes html_directory = /usr/share/doc/postfix-2.4.3-documentation/html inet_interfaces = all inet_protocols = ipv4 mail_owner = postfix mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man mydestination = $myhostname, localhost mydomain = $myhostname myhostname = a.mx.example.com mynetworks = 127.0.0.0/8, myhomeipaddress myorigin = $mydomain newaliases_path = /usr/bin/newaliases.postfix non_smtpd_milters = inet:localhost:8891 procmail_destination_recipient_limit = 1 queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.4.3-documentation/readme relay_domains = sample_directory = /etc/postfix sender_dependent_relayhost_maps = hash:/etc/postfix/mymaps/relayhost_maps sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtp_address_preference = ipv4 smtp_sasl_auth_enable = yes smtp_sasl_mechanism_filter = smtp_sasl_password_maps = hash:/etc/postfix/mymaps/sasl_passwd smtp_sasl_security_options = noanonymous smtp_sasl_tls_security_options = noanonymous smtp_sasl_type = cyrus smtp_sender_dependent_authentication = yes smtp_tls_mandatory_ciphers = high smtp_tls_security_level = may smtpd_helo_required = yes smtpd_helo_restrictions = smtpd_milters = inet:localhost:8891 smtpd_recipient_restrictions = check_client_access cidr:/etc/postfix/client_checks, reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_helo_access hash:/etc/postfix/reject_own_helo, check_policy_service unix:postgrey/socket smtpd_sasl_auth_enable = yes smtpd_sasl_path = /var/spool/postfix/private/auth smtpd_sasl_type = dovecot smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/letsencrypt/archive/example.com/fullchain1.pem smtpd_tls_ciphers = medium smtpd_tls_exclude_ciphers = SSLv2, aNULL, ADH, eNULL smtpd_tls_key_file = /etc/letsencrypt/archive/example.com/privkey1.pem smtpd_tls_loglevel = 1 smtpd_tls_security_level = may smtpd_use_tls = yes strict_rfc821_envelopes = yes unknown_address_reject_code = 554 unknown_client_reject_code = 554 unknown_hostname_reject_code = 554 unknown_local_recipient_reject_code = 550 virtual_alias_maps = hash:/etc/postfix/mymaps/valias.map virtual_gid_maps = static:5000 virtual_mailbox_base = /var/mail/mymail_storage virtual_mailbox_domains = /etc/postfix/mymaps/vhosts.map virtual_mailbox_maps = hash:/etc/postfix/mymaps/vmailboxes.map virtual_transport = procmail virtual_uid_maps = static:1001 postconf -Mf: smtp inet n - n - - smtpd submission inet n - n - - smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject smtps inet n - n - - smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject 628inet n - n - - qmqpd pickup fifo n - n 60 1 pickup cleanupunix n - n - 0 cleanup
smtpd banner problem
Hello, In main.cf I have : smtpd_banner = $myhostname ESMTP $mail_name (DATA TELECOM SERVICE) But when I do : telnet myserver.tld 25 from another server I get : 220 ** I don't find why I don't get the good banner. However,
smtpd banner problem
Hello, In main.cf I have : smtpd_banner = $myhostname ESMTP $mail_name (DATA TELECOM SERVICE) But when I do : telnet myserver.tld 25 from another server I get : 220 ** I don't find why I don't get the good banner. However, doing a telnet 25 from the server itself gives the good banner [r...@mx postfix]# telnet myserver.tld 25 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. 220 myserver.tld ESMTP Postfix (DATA TELECOM SERVICE) (sorry for the bad mail sent earlier!) Best regards, Marco Tchi
RE: smtpd banner problem
Thanks for the replies. It was indeed due to our new ASA Firewall! Regards Marco -Message d'origine- De : owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] De la part de Bastian Blank Envoyé : mardi 20 janvier 2009 11:38 À : postfix-users@postfix.org Objet : Re: smtpd banner problem On Tue, Jan 20, 2009 at 11:09:22AM +0300, Marco Tchi Hong wrote: > But when I do : telnet myserver.tld 25 from another server I get : > 220 ** > I don't find why I don't get the good banner. You have a Cisco PIX in the way which have the smtp fuckup[1] feature enabled. Bastian [1]: They call it smtp fixup -- Captain's Log, star date 21:34.5...
Limit the number of recipient
Hello, I'd like to limit the number of recipient a user can specify when sending mail via our SMTP server. In other words, I'd like to refuse the mail if the number of recipients exceeds 10 for example. To do so, I set smtpd_recipient_limit to 10. To which value should I set smtpd_recipient_overshoot_limit ? I should set it to 0 ? Regards, Marco
Relay access denied issue
Dear List, Very basic relaying setup. Mail coming in from specific range of servers is allowed and forwarded to their final destinations. Postfix 2.3.3 postconf -n alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix debug_peer_level = 2 html_directory = no inet_interfaces = all mail_owner = postfix mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man mydestination = $myhostname, localhost.$mydomain, localhost newaliases_path = /usr/bin/newaliases.postfix queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES sample_directory = /usr/share/doc/postfix-2.3.3/samples sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop unknown_local_recipient_reject_code = 550 /etc/postfix/access /etc/postfix/access.db 10.35.0.0/16OK Most servers within the 10.35.0.0/16 range are allowed just fine.. Mail from one specific ip keeps bouncing: Aug 11 14:22:33 serverX postfix/smtpd[28348]: NOQUEUE: reject: RCPT from serverX.is.local[10.35.10.34]: 554 5.7.1 : Relay access denied; from= to= proto=ESMTP helo= I'm pretty sure I'm missing something very simple, but I just can't see it! Thanks for any hints in the right direction! [cid:blank29.gif] Marco van Kammen Applicatiebeheerder [cid:blank4823.gif] [cid:blank6784.gif] Mirabeau | Managed ServicesDr. C.J.K. van Aalstweg 8F 301, 1625 NV Hoorn +31(0)20-5950550 - www.mirabeau.nl<http://www.mirabeau.nl> [Mirabeau] [cid:leaf3d6c.gif] Please consider the environment before printing this email <><><><><><>
Delivery delay problems
Hello, I am using Postfix 2.3.3 and Kaspersky Antispam/Antivirus on our MX. Mailboxes are hosted on another server. The MX is relaying 250 domains or so, and it doesn't have resources issues. Our problem is that mail stay a long time in the active queue before the content filter, but when it's sent to the server where mailboxes are stored there's no problem: Sep 26 10:11:57 mx postfix/smtp[1387]: 1906C718411: to=<[EMAIL PROTECTED]>, relay=127.0.0.1[127.0.0.1]:9026, conn_use=5, delay=230, delays=0.93/210/0/19, dsn=2.0.0, status=sent (250 2.0.0 Ok (2.0.0 Ok: queued as 5A0B6718ACF )) Sep 26 10:11:57 mx postfix/smtp[744]: 5A0B6718ACF: to=<[EMAIL PROTECTED]>, relay=zsmtp.dts.mg[196.192.32.54]:25, delay=0.12, delays=0.08/0.01/0/0.03, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 6D55BF70AA2) So I went debug mode for the queue manager, and I don't see any errors...but it takes 3 minutes and 30 seconds (see logs below) before the mail is sent to the content filter. What could be the cause? Sep 26 10:08:08 mx postfix/qmgr[669]: qmgr_active_feed: queue incoming Sep 26 10:08:08 mx postfix/qmgr[669]: qmgr_active_feed: incoming/1906C718411 Sep 26 10:08:08 mx postfix/qmgr[669]: qmgr_message_alloc: active 1906C718411 Sep 26 10:08:08 mx postfix/qmgr[669]: record C 529 565 1 0 Sep 26 10:08:08 mx postfix/qmgr[669]: record T 1222412887 94462 Sep 26 10:08:08 mx postfix/qmgr[669]: record A create_time=1222412887 Sep 26 10:08:08 mx postfix/qmgr[669]: record L kas3scan:127.0.0.1:9026 Sep 26 10:08:08 mx postfix/qmgr[669]: record A rewrite_context=remote Sep 26 10:08:08 mx postfix/qmgr[669]: record S [EMAIL PROTECTED] Sep 26 10:08:08 mx postfix/qmgr[669]: 1906C718411: from=<[EMAIL PROTECTED]>, size=529, nrcpt=1 (queu e active) Sep 26 10:08:08 mx postfix/qmgr[669]: record A log_client_name=dts.dts.mg Sep 26 10:08:08 mx postfix/qmgr[669]: record A log_client_address=193.251.140.178 Sep 26 10:08:08 mx postfix/qmgr[669]: record A log_message_origin=dts.dts.mg[193.251.140.178] Sep 26 10:08:08 mx postfix/qmgr[669]: record A log_helo_name=[127.0.0.1] Sep 26 10:08:08 mx postfix/qmgr[669]: record A log_protocol_name=ESMTP Sep 26 10:08:08 mx postfix/qmgr[669]: record A client_name=dts.dts.mg Sep 26 10:08:08 mx postfix/qmgr[669]: record A reverse_client_name=dts.dts.mg Sep 26 10:08:08 mx postfix/qmgr[669]: record A client_address=193.251.140.178 Sep 26 10:08:08 mx postfix/qmgr[669]: record A helo_name=[127.0.0.1] Sep 26 10:08:08 mx postfix/qmgr[669]: record A client_address_type=2 Sep 26 10:08:08 mx postfix/qmgr[669]: record A dsn_orig_rcpt=rfc822;[EMAIL PROTECTED] Sep 26 10:08:08 mx postfix/qmgr[669]: record O [EMAIL PROTECTED] Sep 26 10:08:08 mx postfix/qmgr[669]: record R [EMAIL PROTECTED] Sep 26 10:08:08 mx postfix/qmgr[669]: record M Sep 26 10:08:08 mx postfix/qmgr[669]: record X Sep 26 10:08:08 mx postfix/qmgr[669]: record E Sep 26 10:08:08 mx postfix/qmgr[669]: dir_forest: 1906C718411 -> 1/ Sep 26 10:08:08 mx postfix/qmgr[669]: start sorted recipient list Sep 26 10:08:08 mx postfix/qmgr[669]: qmgr_message_sort: [EMAIL PROTECTED] Sep 26 10:08:08 mx postfix/qmgr[669]: end sorted recipient list Sep 26 10:08:08 mx postfix/qmgr[669]: start sorted recipient list Sep 26 10:08:08 mx postfix/qmgr[669]: qmgr_message_sort: [EMAIL PROTECTED] Sep 26 10:08:08 mx postfix/qmgr[669]: end sorted recipient list Sep 26 10:08:08 mx postfix/qmgr[669]: watchdog_start: 0x9594160 Sep 26 10:11:38 mx postfix/qmgr[669]: qmgr_active_feed: queue incoming Sep 26 10:11:38 mx postfix/qmgr[669]: transport_event: kas3scan Sep 26 10:11:38 mx postfix/qmgr[669]: private/kas3scan socket: wanted attribute: status Sep 26 10:11:38 mx postfix/qmgr[669]: input attribute name: status Sep 26 10:11:38 mx postfix/qmgr[669]: input attribute value: 0 Sep 26 10:11:38 mx postfix/qmgr[669]: private/kas3scan socket: wanted attribute: (list terminator) Sep 26 10:11:38 mx postfix/qmgr[669]: input attribute name: (end) Sep 26 10:11:38 mx postfix/qmgr[669]: qmgr_peer_select: 1906C718411 kas3scan 127.0.0.1:9026 (80 of 8 0) Sep 26 10:11:38 mx postfix/qmgr[669]: qmgr_job_retire: 1906C718411 Sep 26 10:11:38 mx postfix/qmgr[669]: send attr flags = 2051 Sep 26 10:11:38 mx postfix/qmgr[669]: send attr queue_name = active Sep 26 10:11:38 mx postfix/qmgr[669]: send attr queue_id = 1906C718411 Sep 26 10:11:38 mx postfix/qmgr[669]: send attr offset = 565 Sep 26 10:11:38 mx postfix/qmgr[669]: send attr size = 529 Sep 26 10:11:38 mx postfix/qmgr[669]: send attr nexthop = 127.0.0.1:9026 Sep 26 10:11:38 mx postfix/qmgr[669]: send attr encoding = Sep 26 10:11:38 mx postfix/qmgr[669]: send attr sender = [EMAIL PROTECTED] Sep 26 10:11:38 mx postfix/qmgr[669]: send attr envelope_id = Sep 26 10:11:38 mx postfix/qmgr[669]: send attr ret_flags = 0 Sep 26 10:11:38 mx postfix/qmgr[669]: send attr time = [data 44 bytes] Sep 26 10:11:38 mx postfix/qmgr[669]: send attr log_client_name = dts.dts.mg Sep 26 10:11:38 mx postfix/qmgr[669]: send attr log_client_address = 193.251.14
RE: Delivery delay problems
Ok, so the problem is definitely a content filter problem ? This has nothing to do with our Postfix configuration if I understand. -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Wietse Venema Envoyé : vendredi 26 septembre 2008 15:00 À : Marco TCHI HONG Cc : postfix-users@postfix.org Objet : Re: Delivery delay problems Marco TCHI HONG: > Our problem is that mail stay a long time in the active queue before the > content filter, but when it's sent to the server where mailboxes are > stored there's no problem: > > Sep 26 10:11:57 mx postfix/smtp[1387]: 1906C718411: > to=<[EMAIL PROTECTED]>, relay=127.0.0.1[127.0.0.1]:9026, conn_use=5, > delay=230, delays=0.93/210/0/19, dsn=2.0.0, status=sent (250 2.0.0 Ok > (2.0.0 Ok: queued as 5A0B6718ACF )) The mail spends 19 seconds in the content filter. This means that your content filter performance sucks. Wietse
RE: Delivery delay problems
>One possible explanation is that the filter queries a >broken DNS (blocklist) server When the problem occured, I already thought about the broken DNSBL query. The content filter isn't doing any DNSBL check and the problem persists. >Another possibility is that the >Postfix SMTP server behind the content filter has problems when it >tries to resolve the 127.0.0.1 client IP address to a hostname. How would be resolving a problem 127.0.0.1 when in my /etc/hosts.conf I have : order hosts,bind and the right entry in /etc/hosts How does the qmgr determines when it can send the message to the content filter ? Marco -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Wietse Venema Envoyé : vendredi 26 septembre 2008 15:40 À : Postfix users Objet : Re: Delivery delay problems Marco TCHI HONG: > Our problem is that mail stay a long time in the active queue before the > content filter, but when it's sent to the server where mailboxes are > stored there's no problem: > > Sep 26 10:11:57 mx postfix/smtp[1387]: 1906C718411: > to=<[EMAIL PROTECTED]>, relay=127.0.0.1[127.0.0.1]:9026, conn_use=5, > delay=230, delays=0.93/210/0/19, dsn=2.0.0, status=sent (250 2.0.0 Ok > (2.0.0 Ok: queued as 5A0B6718ACF )) Wietse: > The mail spends 19 seconds in the content filter. This means that > your content filter performance sucks. Marco TCHI HONG: > Ok, so the problem is definitely a content filter problem ? > This has nothing to do with our Postfix configuration if I understand. You need to find out why the mail spends 19 seconds in the content filter. One possible explanation is that the filter queries a broken DNS (blocklist) server. Another possibility is that the Postfix SMTP server behind the content filter has problems when it tries to resolve the 127.0.0.1 client IP address to a hostname. And then there are a billion other possibilities. Wietse
RE: Delivery delay problems
>KAV versions I've seen are not fully transparent proxies, they respond >with banner 220 and EHLO 250 before making a downstream connection. The >connection to the downstream server may happen as late as "." (after >the content is scanned). It is certainly important to make sure that >the configured concurrency into the filter is not too high and that >the downstream re-injection port concurrency is at least that high. The downstream re-injection port concurrency is a bit higher than the concurrency into the filter. Below is the chain a message follows : smtpd (port 25, 100) -> spawn/kas-pipe (port 9026, 50) -> spawn/smtpscanner (port 10025, 60) -> spawn (port 9025, 70). spawn/kas-pipe (port 9026, 50) : to antispam spawn/smtpscanner (port 10025, 60) : to antivirus spawn (port 9025, 70) : back to postfix [EMAIL PROTECTED] marco]# telnet 127.0.0.1 9026 Trying 127.0.0.1... Connected to mx.dts.mg (127.0.0.1). Escape character is '^]'. 220 kas30pipe.dts.mg ESMTP Service ready -> I get this message instantaneously [EMAIL PROTECTED] marco]# telnet 127.0.0.1 9025 Trying 127.0.0.1... Connected to mx.dts.mg (127.0.0.1). Escape character is '^]'. 220 mx.dts.mg ESMTP Postfix (DATA TELECOM SERVICE) -> I get this message instantaneously [EMAIL PROTECTED] marco]# telnet 127.0.0.1 10025 Trying 127.0.0.1... Connected to mx.dts.mg (127.0.0.1). Escape character is '^]'. 220 mx.dts.mg ESMTP Kaspersky Lab. -> It takes forever to get this one ... So I guess my problem is with the antivirus... >The OP should measure process concurrency, CPU utilization, disk >utilization, ... Possibly tcpdump the Postfix -> KAV and >KAV->postfix traffic and look for delays. However I have no issue with CPU,Ram utilisation and Disk IO Wait.
