Block mail servers with no reverse dns entries
Hi, How can force postfix to reject emails from mail servers which doesn't have a reverse dns entry ? and is this correct thing to do according to the standards? Thank you. Michael Peter
Re: Postfix + Courier or Dovecot?
On Wed, Jun 17, 2015 at 8:23 PM, Noel Jones wrote: > Postfix plays well with both of these, there should be no unexpected > behavior whichever you choose. > > I personally think dovecot is easy to set up and simple to interface > with postfix, so that's the way I lean. Dovecot may have other > advantages, but the lazy admin factor weighs a lot. > > If you need client-side AUTH in postfix, you'll need cyrus as > dovecot doesn't support that. > I guess it depends which auth you are doing. I used dovecot to do the SMTP AUTH (against kerberos and a local db) for postfix. > So look at them both and pick the one that seems most comfortable to > you. > > > > -- Noel Jones
Re: Block mail servers with no reverse dns entries
Michael Peter: > Hi, > > How can force postfix to reject emails from mail servers which doesn't > have a reverse dns entry ? You can use reject_unknown_reverse_client_hostname or reject_unknown_client_hostname, depending on the appropriate definition of "unknown". Note that the outcome of these depends on how well DNS works. Don't use if if your end has poor DNS service. > and is this correct thing to do according to the standards? This is more a matter of policy than law. I prefer to turn some additional tests when check_client_access matches "unknown". Wietse
Re: Postfix + Courier or Dovecot?
Once upon a time, Eric Broch said: > that courier chokes on large mailboxes, but I never experienced that. It > always performed well for me. I recently switched an install of about 55,000 mailboxes (mostly telco/ISP customers) from Courier to Dovecot. The mail spool is on a backend accessed over NFS; the NFS network traffic dropped significantly (from around 300 megabits per second to about 20 megabits per second) after the switch. Our backend has an SSD read cache to (mostly) keep up with the load with Courier, and now with Dovecot, the SSD is essentially unused (the working set fits in the storage array RAM cache). Depending on your access patterns, Dovecot indexing can be a huge win. Also, Dovecot management is far superior. For example, we have mailbox quotas, which with Courier were just stored in a file in the Maildir. That file had to be regenerated periodically (scanning the whole mailbox), and there was no quick way to check the quota status (it took reading 55,000 files). Dovecot can store quotas in a database, so checking them now is one SELECT (that takes a fraction of a second) away. -- Chris Adams
Re: Postfix + Courier or Dovecot?
Thanks to everyone on their feedback. I'm going with Dovecot. Michael Munger, dCAP, MCPS, MCNPS, MBSS High Powered Help, Inc. Microsoft Certified Professional Microsoft Certified Small Business Specialist Digium Certified Asterisk Professional mich...@highpoweredhelp.com On 06/18/2015 10:28 AM, Chris Adams wrote: > Once upon a time, Eric Broch said: >> that courier chokes on large mailboxes, but I never experienced that. It >> always performed well for me. > I recently switched an install of about 55,000 mailboxes (mostly > telco/ISP customers) from Courier to Dovecot. The mail spool is on a > backend accessed over NFS; the NFS network traffic dropped significantly > (from around 300 megabits per second to about 20 megabits per second) > after the switch. Our backend has an SSD read cache to (mostly) keep up > with the load with Courier, and now with Dovecot, the SSD is essentially > unused (the working set fits in the storage array RAM cache). > > Depending on your access patterns, Dovecot indexing can be a huge win. > > Also, Dovecot management is far superior. For example, we have mailbox > quotas, which with Courier were just stored in a file in the Maildir. > That file had to be regenerated periodically (scanning the whole > mailbox), and there was no quick way to check the quota status (it took > reading 55,000 files). Dovecot can store quotas in a database, so > checking them now is one SELECT (that takes a fraction of a second) > away. >
Re: Question about permit_mynetworks option
On 16 Jun 2015, at 12:04, Noel Jones wrote: If all users must authenticate, it's common to set main.cf mynetworks = 127.0.0.1, [::1] so that local processes can submit mail. It's up to you to determine if local processes require submission on your server. If not required in you environment, set mynetworks empty. mynetworks = Worth clarifying: Not including the loopback in mynetworks DOES NOT prevent local submission, it prevents unauthenticated submission via an smtpd process (i.e. port 25 or 587) over the loopback interface. Submission by local processes using the sendmail compatibility interface (i.e. direct execution of the sendmail binary or of tools that use it like /usr/bin/mail[x], etc.) do not use SMTP and so do not inject mail via the loopback TCP/IP interface and are not blocked by removing the loopback from mynetworks. Some webserver hijacks involve the use of PHP scripts that talk unauthenticated SMTP to localhost, a method also sometimes used by nominally legitimate PHP scripts to send mail. Removing the loopback from mynetworks can be a useful layer of defense on a webserver if you don't need to coddle that sort of sloppiness.
Re: Question about permit_mynetworks option
On Thu, Jun 18, 2015 at 11:24:24AM -0400, Bill Cole wrote: > On 16 Jun 2015, at 12:04, Noel Jones wrote: > > >If all users must authenticate, it's common to set main.cf > >mynetworks = 127.0.0.1, [::1] > >so that local processes can submit mail. It's up to you to determine > >if local processes require submission on your server. If not > >required in you environment, set mynetworks empty. > >mynetworks = > > > Worth clarifying: > > Not including the loopback in mynetworks DOES NOT prevent local submission, > it prevents unauthenticated submission via an smtpd process (i.e. port 25 or > 587) over the loopback interface. Submission by local processes using the > sendmail compatibility interface (i.e. direct execution of the sendmail > binary or of tools that use it like /usr/bin/mail[x], etc.) do not use SMTP > and so do not inject mail via the loopback TCP/IP interface and are not > blocked by removing the loopback from mynetworks. If we're going in this much detail, might as well mention: http://www.postfix.org/postconf.5.html#authorized_submit_users -- Viktor.
Re: Empty sender question
On 17 Jun 2015, at 3:00, Michael Peter wrote: Hi, I understand that postfix send bounces or failed delivered notifications using empty sender. As does every MTA which in compliance with the SMTP standards of the past >25 years. See https://tools.ietf.org/html/rfc5321 and its linked ancestors for details. But does postfix accept empty sender emails during the MAIL FROM command during the SMTP conversation? Yes, unless it is misconfigured to reject the null (empty) sender. because i think that postfix needs a valid email address ? No, it needs a valid SMTP return path value, which can either be an email address OR null. if postfix reject empty sender emails during receiving of emails, so how come bounces and failed delivered notices are received from other email servers ? The condition of your 'if' clause is not normally met. The reason i am asking for that in order to block some spam attacks on our email mail server that using empty email senders Do not block mail simply because of a null sender, as that will eliminate all valid email failure notices generated elsewhere. Find another way.
Re: WIth postscreen working so well, still using fail2ban?
On 17 Jun 2015, at 22:07, PGNd wrote:
postscreen is one layer in a multi-layer defense. It does not have
to stop all unwanted email. That is what the other layers are for.
Certainly. That does not warrant blindly stacking layers upon one
another simply because one can.
There are certainly layers that postscreen clearly renders marginal
(DNSBL checks in SA postqueue).
Others like fail2ban, I'm simply not sure as yet.
It varies from site to site, but if you have the wrong sort of target
domains you can see things like Cutwail spambots making hundreds of
near-simultaneous connections, fast-talking ("EHLO ylmf-pc" is the
signature) and causing spectacular log explosions. The sheer connection
rate of such bots can amount to a brief DoS, depending on your links and
hardware heft. For reasons that I cannot explain, about 10% of Cutwail
bots survive for months at a time and will come back to you a few hours
to a few days later with a repeat performance. It's not hard for
postscreen to keep Cutwail away from smtpd, but doing so isn't without
cost. A tool like fail2ban may not be able to act fast enough to cut off
the first attack from bots acting like Cutwail, but if configured sanely
(90 days ban for fast-talkers) it can help a great deal.
Securely opening store-and-forward only gateway to system- & MUA- submission?
I've a 2-postfix setup. The frontend is open to 'net only on port 25 receives email for my domains from 'net applies restrictions forwards to backend if PASS serves as outbound SMARTHOST to backend; accepts no direct submission generates log entries that feed fail2ban does NOT deliver directly into backend's IMAP store The backend is open to 'net only on port 587 receives email for my domains only fwd'd from frontend delivers email to local IMAP store serves as the smtp server used for MUA port 587 submissions, from end-user clients, for outbound delivery It's all nicely 'bolted down'. My next steps are to (1) enable submission of system mail by non-postfix services running on the frontend -- in this example, for delivery of fail2ban-generated admin messages. (2) enable submission of port 587 MUA submission on the frontend, ensuring concurrent delivery of submitted/sent mail to sender-account's backend IMAP store Questions: (re: 1) What's the right, secure UID to use for the fail2ban-generated injection into Postfix? (re: 2) What mechanism can/should be used to copy frontend-submitted-and-sent mail to the backend's IMAP store? Re: 1, fail2ban is configured to inject/submit those messages using the postfix instance's sendmail, actionban = printf %%b "Subject: [Fail2Ban] : banned from `uname -n` ... " | /usr/local/sbin/sendmail -f Currently fail2ban runs as root. With a config edit, /main.cf - authorized_submit_users = + authorized_submit_users = root messages are delivered as intended. Is submission by root user a security risk from postfix' perspective? Options, if needed, include exec'ing fail2ban 'rootless', as UID= 'fail2ban'(unique) or 'postfix'(shared), or leaving it run as root and simply submit as other UID. What's the recommendation to NOT poke silly holes into my postfix setup?
Re: WIth postscreen working so well, still using fail2ban?
On Thu, Jun 18, 2015, at 09:00 AM, Bill Cole wrote: > It varies from site to site, but if you have the wrong sort of target > domains you can see things like ... ... > A tool like fail2ban may not be able to act fast enough to cut off > the first attack from bots acting like Cutwail, but if configured sanely > (90 days ban for fast-talkers) it can help a great deal. The 'data' I'd been looking at, my own logs, was simply, fortunately, and just to-date, lacking in many of these attacks/exploits. The examples given so far certainly provide, for me, sufficient argument to keep f2b in the loop. The minor challenge is updating f2b's jail defs, actions and filters to be relevant to my setup of postscreen + smtpd_ restrictions prequeue SPF-check proxy prequeue amavisd ClamAV + DKIM checks postqueue amavisd Spamassassin checks It seems that response codes & log syntax have changed for postscreen, and the examples and pkg-included f2b bits make a bunch of outdated assumptions that result in no-hits. Not a big deal, just needs some staring at logs for a bit; slightly more challenging crafting the rules in this 'newer' setup for log entries for attacks/exploits that I haven't yet seen.
Re: WIth postscreen working so well, still using fail2ban?
PGNd: > It seems that response codes & log syntax have changed for postscreen, > and the examples and pkg-included f2b bits make a bunch of outdated > assumptions that result in no-hits. Some tools understand smtpd logging very well, but they need to be updated because postscreen logging is different. Wietse
Re: WIth postscreen working so well, still using fail2ban?
On 18/06/2015 14:44, Wietse Venema wrote: Some tools understand smtpd logging very well, but they need to be updated because postscreen logging is different. Wietse Is there any "recent" Howto or like, for fail2ban and postfix (postscreen, sasl, user unknow, etc...)? Regards, - _Engº Julio Cesar Covolato 0v0 /(_)\ F: 55-11-3129-3366 ^ ^ PSI INTERNET -
Understanding sender_access
Hi, I'm trying to understand how to reject mail not within my domain claiming it's from my domain. I understand body_checks can be used to block mail "From:" my domain, and check_sender_access can be used to block "MAIL FROM" my domain, but don't understand the implications of doing that. I have postfix set up on a mail relay which accepts mail from the Internet and forwards to an internal Exchange server. This Exchange server is the only server responsible for outbound mail. There are no mobile users, but on occasion mail is sent from bulk mailers as being "From:" our domain. I'm concerned that by implementing body_checks or a sender map could reject these emails. Do these bulk mailers generally have a common setup where they can be configured to use smtp-auth for this? I'm hoping someone can provide some general guidance on how to configure my system to permit trusted senders to use our domain while spammers trying to use "From:" our domain are rejected. Is this type of spoofing generally a concern? Is typically SPF the best approach? Thanks, Alex
preference transport_maps and alias_maps
Greetings! I implemented a rule with transport_maps to block all public email delivery except whitelisted domains as below: /etc/postfix/main.cf = transport_maps = hash:/etc/postfix/transport /etc/postfix/transport == trustedcompany.com : mycompany.com : * error:5.1.2 recipient domains not allowed It works quite well until it is reported that the logwatch emails are blocked. The logwatch email is sent to root user at localhost, which is an aliases defined at /etc/aliases. /etc/aliases == root: ad...@mycompany.com The logs show the transport_map takes preference over the aliases map. The DNS domain of $myhostname is prd.mycompany.com, which is a subdomain of mycompany.com. Jun 17 10:33:39 mxserver postfix/pickup[1128]: 76067F81FE: uid=0 from= Jun 17 10:33:39 mxserver postfix/cleanup[1208]: 76067F81FE: message-id=<20150617173339.76067f8...@mxserver.prd.mycompany.com> Jun 17 10:33:39 mxserver postfix/qmgr[1129]: 76067F81FE: from=, size=797, nrcpt=1 (queue active) Jun 17 10:33:39 mxserver postfix/error[1210]: 76067F81FE: to=, orig_to=, relay=none, delay=0.01, delays=0.01/0/0/0, dsn=5.1.2, status=bounced (recipient domains not allowed) Jun 17 10:33:39 mxserver postfix/cleanup[1208]: 784AAF8200: message-id=<20150617173339.784aaf8...@mxserver.prd.mycompany.com> Jun 17 10:33:39 mxserver postfix/bounce[1211]: 76067F81FE: sender non-delivery notification: 784AAF8200 Jun 17 10:33:39 mxserver postfix/qmgr[1129]: 784AAF8200: from=<>, size=2766, nrcpt=1 (queue active) Jun 17 10:33:39 mxserver postfix/qmgr[1129]: 76067F81FE: removed Jun 17 10:33:39 mxserver postfix/error[1210]: 784AAF8200: to=, relay=none, delay=0.01, delays=0/0/0/0, dsn=5.1.2, status=bounced (recipient domains not allowed) Jun 17 10:33:39 mxserver postfix/qmgr[1129]: 784AAF8200: removed Is there any way to make the alias map take preference to the transport map? Thanks, Steve NOTICE: This email message is for the sole use of the addressee named above and may contain confidential information. Any unauthorized review, use, disclosure, distribution or duplication of this message or any attachments is expressly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies and backups of the original message.
Re: Understanding sender_access
On 6/18/2015 1:21 PM, Alex Regan wrote: > Hi, > > I'm trying to understand how to reject mail not within my domain > claiming it's from my domain. I understand body_checks can be used > to block mail "From:" my domain, and check_sender_access can be used > to block "MAIL FROM" my domain, but don't understand the > implications of doing that. > > I have postfix set up on a mail relay which accepts mail from the > Internet and forwards to an internal Exchange server. This Exchange > server is the only server responsible for outbound mail. > > There are no mobile users, but on occasion mail is sent from bulk > mailers as being "From:" our domain. I'm concerned that by > implementing body_checks or a sender map could reject these emails. > Do these bulk mailers generally have a common setup where they can > be configured to use smtp-auth for this? > > I'm hoping someone can provide some general guidance on how to > configure my system to permit trusted senders to use our domain > while spammers trying to use "From:" our domain are rejected. > > Is this type of spoofing generally a concern? Is typically SPF the > best approach? > > Thanks, > Alex Use SPF to limit forgery by outside parties. This restricts use of the envelope sender, not the From: header. Note this may affect your recipients' ability to forward your mail elsewhere. Generally, you should ignore the contents of the From: header as a spam indicator. For example, this email says it's from me, but it's really from the postfix-users list. If you want to be strict about it, you can use a content filter such as SpamAssassin and add a little bit to the score based on the From: header, but it would be unwise to reject mail only because the From: header contains your domain. For example, you would never receive your own posts to this list. Note that sometimes mail arrives with a bare username in the From: header. Some configurations of postfix may add "@$myorigin" to the bare name. To prevent this, on your gateway set main.cf remote_header_rewrite_domain = domain.invalid http://www.postfix.org/ADDRESS_REWRITING_README.html#william -- Noel Jones
Re: Understanding sender_access
Hi, I'm trying to understand how to reject mail not within my domain claiming it's from my domain. I understand body_checks can be used to block mail "From:" my domain, and check_sender_access can be used to block "MAIL FROM" my domain, but don't understand the implications of doing that. I have postfix set up on a mail relay which accepts mail from the Internet and forwards to an internal Exchange server. This Exchange server is the only server responsible for outbound mail. There are no mobile users, but on occasion mail is sent from bulk mailers as being "From:" our domain. I'm concerned that by implementing body_checks or a sender map could reject these emails. Do these bulk mailers generally have a common setup where they can be configured to use smtp-auth for this? I'm hoping someone can provide some general guidance on how to configure my system to permit trusted senders to use our domain while spammers trying to use "From:" our domain are rejected. Is this type of spoofing generally a concern? Is typically SPF the best approach? Thanks, Alex Use SPF to limit forgery by outside parties. This restricts use of the envelope sender, not the From: header. Note this may affect your recipients' ability to forward your mail elsewhere. Generally, you should ignore the contents of the From: header as a spam indicator. For example, this email says it's from me, but it's really from the postfix-users list. If you want to be strict about it, you can use a content filter such as SpamAssassin and add a little bit to the score based on the From: header, but it would be unwise to reject mail only because the From: header contains your domain. For example, you would never receive your own posts to this list. Note that sometimes mail arrives with a bare username in the From: header. Some configurations of postfix may add "@$myorigin" to the bare name. To prevent this, on your gateway set main.cf remote_header_rewrite_domain = domain.invalid http://www.postfix.org/ADDRESS_REWRITING_README.html#william Thanks so much for your help. That brings together the individual pieces. Now I can ask more specific questions. Thanks, Alex
Re: preference transport_maps and alias_maps
Steve Zeng: > Is there any way to make the alias map take preference to the transport map? Fundamentally not possible. The transport chooses the delkiery agent. The local delivery agent expands alias_maps. The precedence is described in ADDRESS_REWRITING_README a.k.a. http://www.postfix.org/ADDRESS_REWRITING_README.html Wietse
Re: preference transport_maps and alias_maps
On Thu, Jun 18, 2015 at 07:53:58PM +, Steve Zeng wrote: > transport_maps = hash:/etc/postfix/transport > > /etc/postfix/transport > == > trustedcompany.com : > mycompany.com : > * error:5.1.2 recipient domains not allowed > > It works quite well until it is reported that the logwatch emails are > blocked. The logwatch email is sent to root user at localhost, which is > an aliases defined at /etc/aliases. > > > /etc/aliases > == > root: ad...@mycompany.com > > Is there any way to make the alias map take preference to the transport map? Yes, if you ask the right question. While local aliases(5) happen after transport selection, virtual(5) aliases happen before transport selection. So turn that into a virtual(5) alias and you get what you wanted. -- Viktor.
Re: Empty sender question
On Thu, 18 Jun 2015 11:36:01 Bill Cole wrote: > On 17 Jun 2015, at 3:00, Michael Peter wrote: > > Hi, > > > > I understand that postfix send bounces or failed delivered > > notifications > > using empty sender. > > As does every MTA which in compliance with the SMTP standards of the > past >25 years. > > See https://tools.ietf.org/html/rfc5321 and its linked ancestors for > details. > > > But does postfix accept empty sender emails during the MAIL FROM > > command > > during the SMTP conversation? > > Yes, unless it is misconfigured to reject the null (empty) sender. > > > because i think that postfix needs a valid > > email address ? > > No, it needs a valid SMTP return path value, which can either be an > email address OR null. > > > if postfix reject empty sender emails during receiving of emails, so > > how > > come bounces and failed delivered notices are received from other > > email > > servers ? > > The condition of your 'if' clause is not normally met. > > > The reason i am asking for that in order to block some spam attacks on > > our > > email mail server that using empty email senders > > Do not block mail simply because of a null sender, as that will > eliminate all valid email failure notices generated elsewhere. Find > another way. If you're able to sign all your outgoing email using BATV envelope senders you could reject all messages with an empty/null sender that wasn't to a correctly signed BATV recipient at your MX. The only limitations here is that you can't guarantee BATV signed email on a domain which runs mailing lists or other applications that encode information in the envelope sender.
Re: preference transport_maps and alias_maps
Virtual alias sounds like a better idea. I just implemented a workaround solution by adding an extra line below to white list all subdomain of mycompany.com at /etc/postfix/transport: mycompany.com : .mycompany.com : Will try it out. Thanks a lot. Steve Sent from my BlackBerry 10 smartphone on the Bell network. Original Message From: Viktor Dukhovni Sent: Thursday, June 18, 2015 5:54 PM To: postfix-users@postfix.org Reply To: postfix-users@postfix.org Subject: Re: preference transport_maps and alias_maps On Thu, Jun 18, 2015 at 07:53:58PM +, Steve Zeng wrote: > transport_maps = hash:/etc/postfix/transport > > /etc/postfix/transport > == > trustedcompany.com : > mycompany.com : > * error:5.1.2 recipient domains not allowed > > It works quite well until it is reported that the logwatch emails are > blocked. The logwatch email is sent to root user at localhost, which is > an aliases defined at /etc/aliases. > > > /etc/aliases > == > root: ad...@mycompany.com > > Is there any way to make the alias map take preference to the transport map? Yes, if you ask the right question. While local aliases(5) happen after transport selection, virtual(5) aliases happen before transport selection. So turn that into a virtual(5) alias and you get what you wanted. -- Viktor. NOTICE: This email message is for the sole use of the addressee named above and may contain confidential information. Any unauthorized review, use, disclosure, distribution or duplication of this message or any attachments is expressly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies and backups of the original message.
mail address-rewritten & redirected to a pipe service faiis to hit the pipe?
I've setup a Postfix store & forward frontend gateway that forwards all mail
for valid domains (DDD1.com -> DDDN.com) to a Postfix backend.
-- The frontend serves as an outbound smarthost for all backend domains.
-- Transport, and recipient verification, TO the backend, and all smarthost
sends FROM the backend, are directed solely a VPN link.
-- The frontend accepts no local delivery; No mail is accepted for the
canonical domain.
-- A local amavisd instance, configured as a postfix prequeue proxy filter,
handles SA filtering, teaching a local bayes* instance.
I want to open the frontend canonical domain to receive mail at only @ 2 email
addresses. Emails received at those emails do not need to be delivered/stored
to any accounts -- simply piped to another service.
Currently, mail's not getting to the pipe. I'd appreciate any help in figuring
out why not.
In more detail ...
The goal is to provide spam/ham learning addresses on the frontend that valid
backend users can forward miscategorized mails to, so that I can train the
bayes instances on the frontend:
-- any backend domain user, us...@dddn.com, sending from the backend,
can forward SPAM or HAM to a spam/ham address at the frontend's canonical
domain - "spam.1...@mail..com" or "ham.1...@mail..com"
-- email accepted at one of those addresses on the frontend is piped to
a perl scripts to be bayes-learned by the local SA instance
Iiuc, this requires the use of ADDRESS REWRITING, the correct ADDRESS CLASSES,
and a pipe.
This is the current working config,
/etc/aliases
root: postmas...@ddd1.com
postmaster: root
mailer-daemon: postmaster
/main.cf
myhostname = myhost..com
mydomain = mail..com
myorigin = $mydomain
mydestination = $myhostname localhost.$mydomain localhost
$mydomain
default_transport = smtp-out-ext:
local_transport = error:5.1.1 local delivery is disabled
local_recipient_maps =
transport_maps =
static:relay-vpn:[internal.mail-backend..com]:12345
...
To get these spam/ham addresses working, I'm attempting to crib the approach at
https://gtmp.org/doku.php/publications:sa-postfix-en .
That document deals with all on a single server. With my frontend/backend
split I'm unclear on the proper approach, and which specific address class(es)
(http://www.postfix.org/ADDRESS_CLASS_README.html) I should be implementing.
I've so far made the following changes to the frontend's config
/etc/aliases
root: postmas...@1.com
postmaster: root
mailer-daemon: postmaster
+ spam.1234: s...@spam.spam
+ ham.1234: h...@ham.ham
/main.cf
myhostname= myhost..com
mydomain = mail..com
myorigin = $mydomain
mydestination = $myhostname localhost.$mydomain localhost
$mydomain
default_transport = smtp-out-ext:
local_transport = error:5.1.1 local delivery is disabled
local_recipient_maps =
unknown_local_recipient_reject_code = 550
- transport_maps =
static:relay-vpn:[internal.mail-backend..com]:12345
+ transport_maps = lmdb:/usr/local/etc/postfix/salearn_transport
+
static:relay-vpn:[internal.mail-backend..com]:12345
+ /salearn_transport
+ spam.spam sa-spam:
+ ham.hamsa-ham:
/master.cf
...
+ sa-spamunix - nn--
pipe
+ user=amavisd:amavisd
argv=/usr/local/etc/spamassassin/scripts/sa-learn-wrapper.pl spam ${sender}
+ sa-ham unix - nn--
pipe
+ user=amavisd:amavisd
argv=/usr/local/etc/spamassassin/scripts/sa-learn-wrapper.pl ham ${sender}
With this config, on send FROM 'us...@ddd1.com' on the backend TO
'spam.1...@mail..com' on the frontend, fontend logs show
The connection from the backend to the frontend
Jun 18 20:11:44 myhost postfix/smarthost/smtpd[17508]: connect from
internal.mail-backend..com[10.13.1.16]
Jun 18 20:11:45 myhost postfix/smarthost/smtpd[17508]: Trusted TLS
connection established from internal.mail-backend..com[10.13.1.16]: TLSv1.2
with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Jun 18 20:11:45 myhost postfix/smarthost/smtpd[17508]: 266FB6450E:
client=internal.mail-backend..com[10.13.1.16]
Jun 18 20:11:45 myhost postfix/cleanup[17510]: 266FB6450E:
message-id=<5583886f.5040...@ddd1.com>
Jun 18 20:11:45 myhost postfix/qmgr[15826]: 266FB6450E:
from=, size=2700, nrcpt=1 (queue active)
J
