At its core is redirection, not a separate mailing. The sending address names a partner and a daily quota; the first messages of the day to each receiver go to the partner, the rest go as usual.
Three numbers to keep in mind. The quota is counted per receiver, per day, per warmed-up sending address. 1000/day with ten large receivers is ten thousand messages from the cold address a day, not a thousand.
The counters reset at midnight and survive a restart. And so does the used-up quota itself: a node restart will not give the cold address a second day of traffic in a row.
The cold partner is an ordinary sending address, and it delivers messages by its own settings. So it must have its own: address, name, signing key, its own limits.
The vendor’s caveat comes as the first line of the section and decides whether the mechanism fits at all: it is needed when there is at least one warmed-up address. For a fleet of only new addresses the vendor recommends limits, not this.
The mechanism has no values of its own: cold-virtual-mta names the partner, max-cold-virtual-mta-msg sets the number. Both halves are required — a quota without a partner does nothing.
| What | Where | Default |
|---|---|---|
| who the partner is | cold-virtual-mta in the warmed-up sending address | none |
| how many messages | max-cold-virtual-mta-msg in its receiver block | 0/d, that is, disabled |
| how the cold one sends | its own sending address block | nothing is inherited |
Set it as a ladder, not as a single number: a constant hundred messages a day from day one is not warm-up.
# the warmed-up one hands off the first messages of the day, the cold one sends by its own settings <virtual-mta vmta1> smtp-source-host 1.2.3.4 vmta1.example.com cold-virtual-mta vmta2 <domain *> max-cold-virtual-mta-msg 1000/day </domain> </virtual-mta> <virtual-mta vmta2> smtp-source-host 5.6.7.8 vmta2.example.com <domain *> max-msg-rate 100/h </domain> </virtual-mta>
what people get wrong and how it ends3 mistakes▶
§ 11.6
§ 3.3.10.57
§ 11.6
4 relations
max-cold-virtual-mta-msg<domain>Names the partner; here only the number of messages it gets is set. § 3.3.10.57The sending address — what it is made ofThe partner address that early traffic is diverted to is named here. § 3.3.12.4A group of sending addresses with traffic sharesThe second way to give a new address a small share of traffic: not a fraction of a percent in a pool, but the day’s first messages. inferencecold-virtual-mta<virtual-mta>The mechanism this line enables — with counting rules and caveats. § 3.3.12.4virtual-mta<virtual-mta-pool>Another way to give a new address a small share: not a tenth of a percent but the first messages of the day. § 3.3.13.1
pmtaacctfind --output csv[vmta,rcpt,timeLogged] /var/log/pmta/acct-*.csv
3 articles
◇The sending address — what it is made ofA named set of everything that is a property of the address: which IP the message leaves from, how the node introduces itself, what it signs with and how fast it sends.◇A group of sending addresses with traffic sharesA named group of sending addresses; without shares messages are distributed in rotation, with shares in the given proportion, in steps of a tenth of a percent.◇The sender names the stream for each messageThe message carries the name of the stream it should be sent through — the choice is made by the submitting program, not by the node configuration.