I've been poking at this a bit tonight. I am by no means a postfix expert. In
the hopes that someone can see an obvious configuration issue, I'm going to
post what I'm seeing:
In my main.cf;
smtpd_recipient_restrictions = check_recipient_access
inline:{
{ gmail.com = class-gmail }
{ yahoo.com = class-yahoo }
} permit_mynetworks permit_sasl_authenticated defer_unauth_destination
restriction_classes = class-gmail, class-yahoo
class-gmail = check_recipient_access randmap:{filter smtp1:, filter smtp2:}
class-yahoo = check_recipient_access randmap:{filter smtp1:, filter smtp2:}
postconf complains about this:
postconf: warning: /etc/postfix/main.cf: unused parameter:
class-yahoo=check_recipient_access randmap:{filter smtp1:, filter smtp2:}
postconf: warning: /etc/postfix/main.cf: unused parameter:
class-gmail=check_recipient_access randmap:{filter smtp1:, filter smtp2:}
postconf: warning: /etc/postfix/main.cf: unused parameter:
restriction_classes=class-gmail, class-yahoo
and postfix itself complains of a config error when trying to send email.
I upped the debug and this is where it is having issues:
Nov 29 23:47:29 OptiPlex-9010 postfix/smtpd[500582]: resolve_clnt:
`sean.hennessey@YYY' -> `x...@gmail.com' -> transp=`smtp'
host=`smtp.gmail.com:587' rcpt=`x...@gmail.com' flags= class=default
Nov 29 23:47:29 OptiPlex-9010 postfix/smtpd[500582]: ctable_locate: install
entry key sean.hennessey@YYY?x...@gmail.com
Nov 29 23:47:29 OptiPlex-9010 postfix/smtpd[500582]: extract_addr: in:
<x...@gmail.com>, result: x...@gmail.com
Nov 29 23:47:29 OptiPlex-9010 postfix/smtpd[500582]: >>> START Recipient
address RESTRICTIONS <<<
Nov 29 23:47:29 OptiPlex-9010 postfix/smtpd[500582]: generic_checks:
name=check_recipient_access
Nov 29 23:47:29 OptiPlex-9010 postfix/smtpd[500582]: check_mail_access:
x...@gmail.com
Nov 29 23:47:29 OptiPlex-9010 postfix/smtpd[500582]: ctable_locate: leave
existing entry key sean.hennessey@YYY?x...@gmail.com
Nov 29 23:47:29 OptiPlex-9010 postfix/smtpd[500582]: maps_find: inline:{ {
gmail.com = class-gmail } { yahoo.com = class-yahoo } }: x...@gmail.com:
not found
Nov 29 23:47:29 OptiPlex-9010 postfix/smtpd[500582]: maps_find: inline:{ {
gmail.com = class-gmail } { yahoo.com = class-yahoo } }: inline:{ {
gmail.com = class-gmail } { yahoo.com = class-yahoo }
}(0,lock|fold_fix|utf8_request): gmail.com = class-gmail
Nov 29 23:47:29 OptiPlex-9010 postfix/smtpd[500582]: mail_addr_find:
x...@gmail.com -> class-gmail
Nov 29 23:47:29 OptiPlex-9010 postfix/smtpd[500582]: check_table_result:
inline:{ { gmail.com = class-gmail } { yahoo.com = class-yahoo } }
class-gmail x...@gmail.com
Nov 29 23:47:29 OptiPlex-9010 postfix/smtpd[500582]: >>> START Recipient
address RESTRICTIONS <<<
Nov 29 23:47:29 OptiPlex-9010 postfix/smtpd[500582]: generic_checks:
name=class-gmail
Nov 29 23:47:29 OptiPlex-9010 postfix/smtpd[500582]: warning: unknown smtpd
restriction: "class-gmail"
Nov 29 23:47:29 OptiPlex-9010 postfix/smtpd[500582]: NOQUEUE: reject: RCPT from
Latitude-E5540.lan[192.168.0.141]: 451 4.3.5 Server configuration error;
from=<sean.hennessey@YYY> to=<x...@gmail.com> proto=SMTP helo=<latitude-e5540>
Nov 29 23:47:29 OptiPlex-9010 postfix/smtpd[500582]: >
Latitude-E5540.lan[192.168.0.141]: 451 4.3.5 Server configuration error
I took a shot at changing main.cf from restriction_classes to
smtpd_restriction_classes. That got passed warnings from postconf, but now I
get this:
Nov 30 00:03:37 OptiPlex-9010 postfix/smtpd[501383]: >>> START Recipient
address RESTRICTIONS <<<
Nov 30 00:03:37 OptiPlex-9010 postfix/smtpd[501383]: generic_checks:
name=check_recipient_access
Nov 30 00:03:37 OptiPlex-9010 postfix/smtpd[501383]: check_mail_access:
x...@gmail.com
Nov 30 00:03:37 OptiPlex-9010 postfix/smtpd[501383]: ctable_locate: leave
existing entry key sean.hennessey@YYY?x...@gmail.com
Nov 30 00:03:37 OptiPlex-9010 postfix/smtpd[501383]: maps_find: inline:{ {
gmail.com = class-gmail } { yahoo.com = class-yahoo } }: x...@gmail.com:
not found
Nov 30 00:03:37 OptiPlex-9010 postfix/smtpd[501383]: maps_find: inline:{ {
gmail.com = class-gmail } { yahoo.com = class-yahoo } }: inline:{ {
gmail.com = class-gmail } { yahoo.com = class-yahoo }
}(0,lock|fold_fix|utf8_request): gmail.com = class-gmail
Nov 30 00:03:37 OptiPlex-9010 postfix/smtpd[501383]: mail_addr_find:
x...@gmail.com -> class-gmail
Nov 30 00:03:37 OptiPlex-9010 postfix/smtpd[501383]: check_table_result:
inline:{ { gmail.com = class-gmail } { yahoo.com = class-yahoo } }
class-gmail x...@gmail.com
Nov 30 00:03:37 OptiPlex-9010 postfix/smtpd[501383]: >>> START Recipient
address RESTRICTIONS <<<
Nov 30 00:03:37 OptiPlex-9010 postfix/smtpd[501383]: generic_checks:
name=class-gmail
Nov 30 00:03:37 OptiPlex-9010 postfix/smtpd[501383]: >>> START Recipient
address RESTRICTIONS <<<
Nov 30 00:03:37 OptiPlex-9010 postfix/smtpd[501383]: generic_checks:
name=check_recipient_access
Nov 30 00:03:37 OptiPlex-9010 postfix/smtpd[501383]: check_mail_access:
x...@gmail.com
Nov 30 00:03:37 OptiPlex-9010 postfix/smtpd[501383]: ctable_locate: leave
existing entry key sean.hennessey@YYY?x...@gmail.com
Nov 30 00:03:37 OptiPlex-9010 postfix/smtpd[501383]: maps_find: randmap:{filter
smtp1:, filter smtp2:}: randmap:{filter smtp1:, filter
smtp2:}(0,lock|fold_fix|utf8_request): x...@gmail.com = smtp2:
Nov 30 00:03:37 OptiPlex-9010 postfix/smtpd[501383]: mail_addr_find:
x...@gmail.com -> smtp2:
Nov 30 00:03:37 OptiPlex-9010 postfix/smtpd[501383]: check_table_result:
randmap:{filter smtp1:, filter smtp2:} smtp2: x...@gmail.com
Nov 30 00:03:37 OptiPlex-9010 postfix/smtpd[501383]: warning: access table
randmap:{filter smtp1:, filter smtp2:} has entry with lookup table: smtp2:
Nov 30 00:03:37 OptiPlex-9010 postfix/smtpd[501383]: warning: do not specify
lookup tables inside SMTPD access maps
Nov 30 00:03:37 OptiPlex-9010 postfix/smtpd[501383]: warning: define a
restriction class and specify its name instead.
Nov 30 00:03:37 OptiPlex-9010 postfix/smtpd[501383]: NOQUEUE: reject: RCPT from
Latitude-E5540.lan[192.168.0.141]: 451 4.3.5 Server configuration error;
from=<sean.hennessey@YYY> to=<x...@gmail.com> proto=SMTP helo=<latitude-e5540>
Nov 30 00:03:37 OptiPlex-9010 postfix/smtpd[501383]: >
Latitude-E5540.lan[192.168.0.141]: 451 4.3.5 Server configuration error
I'm going to try to dig into more details on the morrow, but in case anyone
happens to know.
Thanks in advance.
________________________________
From: owner-postfix-us...@postfix.org <owner-postfix-us...@postfix.org> on
behalf of Wietse Venema <wie...@porcupine.org>
Sent: Tuesday, November 29, 2022 9:59 AM
To: Postfix users <postfix-users@postfix.org>
Subject: Re: Is there an easy way to "warm up" a new sending IP w/ Postfix
>Sean Hennessey:
> All,
>
> I'm bringing a new sending IP online and need to know if there is
> an easy way to warm it up w/ Postfix.
>
> For those that don't know, warming up is a process where you start
> to send small amounts of mail of the new IP till it's built up a
> good enough reputation.
>
> In a past life I use Port25's powermta software. It has an easy
> config way of doing this where you can say for gmail.com divert
> the first X emails to use this way of sending instead of the normal
> way.
>
> I'm trying to see if there is something similar in postfix.
>
> So basically I need a way to take a configurable amount of mail
> for various domains and send them on smtp endpoint instead of the
> relay that is currently configured.
>
> I searched the list archives and saw the thread of gradual shift
> of traffic from back in February of this year. That gives me some
> ideas, but that seems to be for all traffic, not a subset.
>
> I'd really like a way to send X% of gmail.com traffic to one relay
> and the rest to another relay. Ditto for a couple of other major
> ESP's like Yahoo, MS, etc...
>
> Thanks in advance.
The two examples below support different old/new IP address ratios
for different destinations, as well as the same ratios for all
destinations.
To change the ratios over time, you would have to update main.cf
and rely on Postfix built-in behavior to restart Postfix SMTP server
processes after 100 SMTP client connections.
First, specify master.cf entries with different source IP addresses.
Each entry uses the proper smtp_helo_name that matches the PTR value
for the smtp_bind_address setting.
In /etc/postfix/master.cf:
==========================
smtp1 unix - - n - - smtp
-o { smtp_bind_address = 1.2.3.1 }
-o { smtp_helo_name = helo-for-1.2.3.1 }
smtp2 unix - - n - - smtp
-o { smtp_bind_address = 1.2.3.2 }
-o { smtp_helo_name = helo-for-1.2.3.2 }
In /etc/postfix/main.cf:
========================
Next an example that supports different warming up ratios for
different destinations. See "Notes" below for a simpler approach
when the warming up ratios can be the same for all destinations.
This example uses a nested table, which requires a restriction class.
smtpd_recipient_restrictions = check_recipient_access
inline:{
{ gmail.com = class-gmail }
{ yahoo.com = class-yahoo }
}
...other restrictions...
# To get (90%, 10%), specify one filter 9x and the other filter 1x.
# The order does not matter.
restriction_classes = class-gmail, class-yahoo
class-gmail = check_recipient_access randmap:{filter smtp1:, filter smtp2:}
class-yahoo = check_recipient_access randmap:{filter smtp1:, filter smtp2:}
Notes:
======
- Instead of inline:{...}, a hash or pcre table could work too.
With pcre you can easily specify a catch-all rule at the end.
- If you can use the same randmap:{} settings for all destinations, then
you can avoid the need for restriction_classes and for the lookup
table that returns restriction class names. Just select the filter
action with:
smtpd_recipient_restrictions =
check_recipient_access randmap:{filter smtp1:, filter smtp2:}
...other restrictions...
- For the future: we could make randmap smarter and support a weight
factor, like randmap:{{filter smtp1:}*99, {filter smtp2:}*1} where
a weight of *1 is of course the default.
The examples were not tested...
Wietse
