Re: Maximum simultaneous outbounds ?

[Viktor Dukhovni]

> On Mar 3, 2019, at 2:56 AM, Ronald F. Guilmette  
> wrote:
> 
> But this other fellow I've been taking to offered an unexpected observation:
> If a given Postfix installation was attempting to support, say, 1 million
> unique domain names (correponding to 1 million unique customers) and if
> just 11,000 of those were to all simultaneously attempt to send -outbound-
> emails to six (6) different destinations apiece, then... this other fellow
> asserted... all of the 65536 maximum available IPv4 port numbers would be
> exhausted, and then havoc would ensue.

This mental model is deeply flawed.  Postfix has a queue manager, that
limits the concurrency per destination, and the active queue size.  And
a master(8) process that limits the process count per transport.  Postfix
also accepts messages at a finite rate, so 66,000 messages will not arrive
instantaneously.  Once the active queue is full further accepted messages
will accumulate in the incoming queue on disk, but will not consume network
resources or RAM.

It is of course possible to receive inbound messages faster than the
steady-state output rate, in which case the number of queued messages
will grow quite high.  And if this is allowed to continue indefinitely,
until the file system almost fills up.

But the port number exhaustion scenario is not even close.

  http://www.postfix.org/OVERVIEW.html#delivering
  http://www.pos

-- 
Viktor.

Re: Maximum simultaneous outbounds ?

[Ronald F. Guilmette]

In message <41848ab9-339a-41a8-9a20-b1533eb77...@dukhovni.org>, 
Viktor Dukhovni  wrote:

>> On Mar 3, 2019, at 2:56 AM, Ronald F. Guilmette
> wrote:
>>
>> But this other fellow I've been taking to offered an unexpectedobservation:
>> If a given Postfix installation was attempting to support, say, 1 million
>> unique domain names (correponding to 1 million unique customers) and if
>> just 11,000 of those were to all simultaneously attempt to send -outbound-
>> emails to six (6) different destinations apiece, then... this other fellow
>> asserted... all of the 65536 maximum available IPv4 port numbers would be
>> exhausted, and then havoc would ensue.
>
>This mental model is deeply flawed.

Thank you for the response Vicktor, but could you please be more specific,
just so that I have it on the record?

Whose mental model is it that you are saying is "deeply flawed"?  Mine or
the other guy's?

>Postfix has a queue manager, that
>limits the concurrency per destination, and the active queue size.  And
>a master(8) process that limits the process count per transport. Postfix
>also accepts messages at a finite rate, so 66,000 messages will not arrive
>instantaneously.  Once the active queue is full further accepted messages
>will accumulate in the incoming queue on disk, but will not consume network
>resources or RAM.

Paraphrasing, it sounds to me like you just said that Postfix is designed
to behave well, and in fact does behave well, even under very high loads.

But I, for one, already knew that.  (And I suspect that most folks who use
Postfix at "big" places knew that already also.)

I still would like to know if the total number of outbound SMTP connections
which Postfix may have open, at any one given point in time, may or may not
exceed 65536.

(I admit that this is really rather entirely a matter of academic curiosity
on my part and that it may have little or no practical implications.  I
just have this running disagreement going about how many angels can dance
on the head of... I'm sorry... about how many domain names can, in practice
be hosted on a single IPv4 address.  I say "millions".  Others are telling
me that I'm delusional and need to seek immediate treatment. I am not yet
favorably inclined to acecpt their judgement on the matter.The key point
of disagreement seens to be our differing evaluations about how many
simultaneous outbound SMTP a good quality... or best quality... SMTP server
could in practice support.)

>But the port number exhaustion scenario is not even close.

I'm not at all sure how to interpret that.

May I assume that your intent was to say that a hosting company could
tell all of its 1 million customers to use a single shared mail server
for all of their outbound needs, and that even though this might possibly
create a unsustainable load, the unsustainability would *not* become
evident, in the first instance, as an exhaustion of outbound IPv4 port
numbers?

Re: Unexpected directories in virtual_mailbox_base

[Thomas Seilund]

On 02/03/2019 13.38, @lbutlr wrote:

On 01 Mar 2019, at 07:21, Thomas Seilund  wrote:

-- Once a day for each user I clear the bayes files and rebuild bayes files 
with:

You are removing the bases entries daily and rebuilding them based on a very 
few (if any) messages in your LaernAs folders?

That’s the same as not using bayes at all.


Thanks for your reply

Each user has a ham mail folder and a spam mail folder.

I instruct user to have at least 10 not spam mails in the ham folder.

And I instruct the users to move spam that make it to the inbox to the 
spam folder.


In most cases users have +10 mails in the ham folder and +100 mails in 
the spam folder.


How should SA learn from the two folders if not by running sa-learn on 
each of the two folders regularly?


I use SA by integrating SpamAssassin into Postfix using spamd and I 
wrote a bash script to rewrite spam method


as described in 
https://wiki.apache.org/spamassassin/IntegratedSpamdInPostfix


Any advice would be wellcome

Re: Unexpected directories in virtual_mailbox_base

[Matus UHLAR - fantomas]

On 01 Mar 2019, at 07:21, Thomas Seilund  wrote:

-- Once a day for each user I clear the bayes files and rebuild bayes files 
with:



On 02/03/2019 13.38, @lbutlr wrote:

You are removing the bases entries daily and rebuilding them based on a very 
few (if any) messages in your LaernAs folders?

That’s the same as not using bayes at all.


On 03.03.19 11:27, Thomas Seilund wrote:

Each user has a ham mail folder and a spam mail folder.

I instruct user to have at least 10 not spam mails in the ham folder.


spamassassin needs at least 100  pieces of each to start hitting.

And I instruct the users to move spam that make it to the inbox to the 
spam folder.


In most cases users have +10 mails in the ham folder and +100 mails in 
the spam folder.


How should SA learn from the two folders if not by running sa-learn on 
each of the two folders regularly?


note that the commands you have mentioned:
https://marc.info/?l=postfix-users&m=155145015801188&w=2

don't clear bayes database, they only train new spam/ham.

the complaint was about removing bayes database daily. You don't need to
remove bayes database at all. Don't clear the bayes database.

I use SA by integrating SpamAssassin into Postfix using spamd and I 
wrote a bash script to rewrite spam method


as described in 
https://wiki.apache.org/spamassassin/IntegratedSpamdInPostfix


there are better way to integrate spamassassin to postfix, I'd recommend
spamass-milter if you weant to keep per-user databases.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Honk if you love peace and quiet. 

Re: Maximum simultaneous outbounds ?

[Wietse Venema]

Ronald F. Guilmette:
> But this other fellow I've been taking to offered an unexpected observation:
> If a given Postfix installation was attempting to support, say, 1 million
> unique domain names (correponding to 1 million unique customers) and if
> just 11,000 of those were to all simultaneously attempt to send -outbound-
> emails to six (6) different destinations apiece, then... this other fellow
> asserted... all of the 65536 maximum available IPv4 port numbers would be
> exhausted, and then havoc would ensue.

As shipped, Postfix makes up to 100 parallel outbound connections,
200 if configured as an MX for remote domains. It also has limits
on the number and size of in-memory objects, and it stops accepting
new mail before the file system is full.

Postfix is in a different league than software that just runs the
system into the ground under load, and that requires a babysitter
to become unstuck.

Wietse

Re: migrating/cloning 3.2.4 > 3.3.2?

[Wietse Venema]

Voytek:
> what else should I be checking/testing/adding/removing ?

Look in the Postfix 3.3 RELEASE_NOTES file.

Wietse

postscreen_dnsbl_action "drop" not working correctly?

[Mayhem]

It doesn't appear that postscreen_dnsbl_action is working correctly when set
to "drop".

The manual states "Drop the connection immediately with a 521 SMTP reply" -
but that's not happening. It's still checking the block lists.

Mar  3 08:03:50 localhost postfix/postscreen[80179]: CONNECT from
[185.234.217.223]:64507 to [xx.xx.xx.xx]:25
Mar  3 08:03:50 localhost postfix/dnsblog[80180]: addr 185.234.217.223
listed by domain zen.spamhaus.org as 127.0.0.2
Mar  3 08:03:50 localhost postfix/dnsblog[80180]: addr 185.234.217.223
listed by domain zen.spamhaus.org as 127.0.0.4
Mar  3 08:03:56 localhost postfix/postscreen[80179]: DNSBL rank 1 for
[185.234.217.223]:64507
Mar  3 08:03:56 localhost postfix/postscreen[80179]: HANGUP after 0.48 from
[185.234.217.223]:64507 in tests after SMTP handshake
Mar  3 08:03:56 localhost postfix/postscreen[80179]: DISCONNECT
[185.234.217.223]:64507
Mar  3 08:13:15 localhost postfix/postscreen[80959]: CONNECT from
[185.234.217.223]:64042 to [xx.xx.xx.xx]:25
Mar  3 08:13:16 localhost postfix/dnsblog[80961]: addr 185.234.217.223
listed by domain zen.spamhaus.org as 127.0.0.2
Mar  3 08:13:16 localhost postfix/dnsblog[80961]: addr 185.234.217.223
listed by domain zen.spamhaus.org as 127.0.0.4
Mar  3 08:13:21 localhost postfix/postscreen[80959]: DNSBL rank 1 for
[185.234.217.223]:64042
Mar  3 08:13:21 localhost postfix/postscreen[80959]: HANGUP after 0.47 from
[185.234.217.223]:64042 in tests after SMTP handshake
Mar  3 08:13:21 localhost postfix/postscreen[80959]: DISCONNECT
[185.234.217.223]:64042

*main.cf :*

postscreen_blacklist_action = drop
postscreen_greet_action = enforce
postscreen_dnsbl_action = drop
postscreen_dnsbl_threshold = 1

postscreen_dnsbl_sites =
 zen.spamhaus.org,
 b.barracudacentral.org


*postscreen :*

postscreen_access_list = permit_mynetworks
postscreen_bare_newline_action = ignore
postscreen_bare_newline_enable = no
postscreen_bare_newline_ttl = 30d
postscreen_blacklist_action = drop
postscreen_cache_cleanup_interval = 12h
postscreen_cache_map = btree:$data_directory/postscreen_cache
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 = drop
postscreen_dnsbl_max_ttl =
${postscreen_dnsbl_ttl?{$postscreen_dnsbl_ttl}:{1}}h
postscreen_dnsbl_min_ttl = 60s
postscreen_dnsbl_reply_map =
postscreen_dnsbl_sites = zen.spamhaus.org, b.barracudacentral.org
postscreen_dnsbl_threshold = 1
postscreen_dnsbl_timeout = 10s
postscreen_dnsbl_whitelist_threshold = 0
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 = $smtpd_banner
postscreen_greet_ttl = 1d
postscreen_greet_wait = ${stress?{2}:{6}}s
postscreen_helo_required = $smtpd_helo_required
postscreen_non_smtp_command_action = drop
postscreen_non_smtp_command_enable = no
postscreen_non_smtp_command_ttl = 30d
postscreen_pipelining_action = enforce
postscreen_pipelining_enable = no
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



--
Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html

Re: postscreen_dnsbl_action "drop" not working correctly?

[Wietse Venema]

Assuming that you don't have multiple conflicting "postscreen_dnsbl_action"
settings in main.cf, you can configure postscreen to log the action
(drop, enforce, etc.) with "postscreen -v".

Commands:

# postconf -F "smtp/inet/command = postscreen -v"
# postfix reload

This will slow down postscreen, so you may want to use this temporarily.

Wietse

Re: postscreen_dnsbl_action "drop" not working correctly?

[Matus UHLAR - fantomas]

On 03.03.19 10:21, Mayhem wrote:

It doesn't appear that postscreen_dnsbl_action is working correctly when set
to "drop".

The manual states "Drop the connection immediately with a 521 SMTP reply" -
but that's not happening. It's still checking the block lists.

Mar  3 08:03:50 localhost postfix/postscreen[80179]: CONNECT from
[185.234.217.223]:64507 to [xx.xx.xx.xx]:25
Mar  3 08:03:50 localhost postfix/dnsblog[80180]: addr 185.234.217.223
listed by domain zen.spamhaus.org as 127.0.0.2
Mar  3 08:03:50 localhost postfix/dnsblog[80180]: addr 185.234.217.223
listed by domain zen.spamhaus.org as 127.0.0.4
Mar  3 08:03:56 localhost postfix/postscreen[80179]: DNSBL rank 1 for
[185.234.217.223]:64507
Mar  3 08:03:56 localhost postfix/postscreen[80179]: HANGUP after 0.48 from
[185.234.217.223]:64507 in tests after SMTP handshake


according to:
http://www.postfix.org/POSTSCREEN_README.html

When an SMTP client hangs up unexpectedly, postscreen(8) logs this as:

   HANGUP after time from [address]:port in test name


this looks like client hung up before postscreen could reject the
connection.

as I understand it, postscreen_greet_action is evaluated before
postscreen_dnsbl_action, so it hits before due to this.


postscreen_dnsbl_action = drop
postscreen_dnsbl_max_ttl =
${postscreen_dnsbl_ttl?{$postscreen_dnsbl_ttl}:{1}}h
postscreen_dnsbl_min_ttl = 60s
postscreen_dnsbl_reply_map =
postscreen_dnsbl_sites = zen.spamhaus.org, b.barracudacentral.org
postscreen_dnsbl_threshold = 1
postscreen_dnsbl_timeout = 10s
postscreen_dnsbl_whitelist_threshold = 0
postscreen_greet_action = enforce
postscreen_greet_banner = $smtpd_banner
postscreen_greet_ttl = 1d
postscreen_greet_wait = ${stress?{2}:{6}}s


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

Re: postscreen_dnsbl_action "drop" not working correctly?

[Wietse Venema]

Original poster:
>Mar  3 08:03:56 localhost postfix/postscreen[80179]: HANGUP after 0.48 from
>[185.234.217.223]:64507 in tests after SMTP handshake

Matus UHLAR - fantomas:
> this looks like client hung up before postscreen could reject the
> connection.

No, the client hung up 0.48s after it was tarpitted with the 'tests
after SMTP handshake'.

Wietse

Re: Maximum simultaneous outbounds ?

[Viktor Dukhovni]

On Sun, Mar 03, 2019 at 01:49:12AM -0800, Ronald F. Guilmette wrote:

> >> But this other fellow I've been taking to offered an unexpectedobservation:
> >> If a given Postfix installation was attempting to support, say, 1 million
> >> unique domain names (correponding to 1 million unique customers) and if
> >> just 11,000 of those were to all simultaneously attempt to send -outbound-
> >> emails to six (6) different destinations apiece, then... this other fellow
> >> asserted... all of the 65536 maximum available IPv4 port numbers would be
> >> exhausted, and then havoc would ensue.
> >
> >This mental model is deeply flawed.
> 
> Thank you for the response Viktor, but could you please be more specific,
> just so that I have it on the record?
> 
> Whose mental model is it that you are saying is "deeply flawed"?  Mine or
> the other guy's?

There's only one "mental model" under discussion of what happens
when Postfix is delivering email.  Namely, that no matter how many
messages arrive in quick succession, they'll all be "talking to the
network" (using an outbound TCP connection) at the same time.  This
mental model is deeply flawed.

I could also point out that TCP stacks can allow the same local
ephemeral port to be used for multiple TCP connections, provided
the 4-tuple (remote ip, remote port, local ip, local port) is unique.
There is no requirement that just the local ports of established
TCP connections be distinct.

> Paraphrasing, it sounds to me like you just said that Postfix is designed
> to behave well, and in fact does behave well, even under very high loads.

I tried to provide a more accurate model of how Postfix delivers
email, from which you or anyone else can reach your own conclusions.

> But I, for one, already knew that.  (And I suspect that most folks who use
> Postfix at "big" places knew that already also.)

Well, it seems that you only knew the empirical conclusions.  Had you
known how Postfix ensures performance under load, you'd have refuted
the other fellow's false scenario without coming to the list.

> I still would like to know if the total number of outbound SMTP connections
> which Postfix may have open, at any one given point in time, may or may not
> exceed 65536.

This is a silly question.  Typical message delivery latency can be
estimated at around 1s.  A hypothetical server running at a concurrency
of 64k connections would be pumping out 64k msgs/sec, but the Postfix
queue manager and the disk are very unlikely to go that fast.
Realistically, a single email server may be able to deliver at best
O(1000) msgs/sec.

At a hypothetical sustained 64k messages per second, a server would
be able to deliver around 5.6 billion messages a day.  That's not
a realistic load for a single machine, either inbound or outbound.

Real servers handle smaller loads with outbound concurrency limits
in the hundreds or a few thousand.  With Postfix brief input spikes
that exceed the output rate lead growth in the size of the queue
without unbounded demand for CPU and network.

There are also caps on concurrent incoming connections, and
sufficiently high input rates will reduce opportunities for new
connections, forcing some or most senders to defer delivery.  That's
what horizontal scaling is for, with anycast IPs to spread the load
geographically, and in-datacentre load-balancers to further spread
the load among multiple machines, ...

-- 
Viktor.

Re: postscreen_dnsbl_action "drop" not working correctly?

[Mayhem]

The 521 SMTP reply only happens after checking the block lists. It's not
being dropped immediately like the manually says it should be.

-

Mar  3 09:59:54 localhost postfix/postscreen[84375]: CONNECT from
[85.54.217.239]:5089 to [xx.xx.xx.xx]:25
Mar  3 09:59:54 localhost postfix/postscreen[84375]:
source=postscreen_access_list address=85.54.217.239 acl=permit_mynetworks
Mar  3 09:59:54 localhost postfix/postscreen[84375]: match_hostaddr:
postscreen_access_list: 85.54.217.239 ~? 127.0.0.0/8
Mar  3 09:59:54 localhost postfix/postscreen[84375]: match_hostaddr:
postscreen_access_list: 85.54.217.239 ~? [::1]/128
Mar  3 09:59:54 localhost postfix/postscreen[84375]: match_hostaddr:
postscreen_access_list: 85.54.217.239 ~? xx.xx.xx.xx
Mar  3 09:59:54 localhost postfix/postscreen[84375]: match_list_match:
85.54.217.239: no match
Mar  3 09:59:54 localhost postfix/postscreen[84375]:
source=postscreen_access_list address=85.54.217.239 - no match
Mar  3 09:59:54 localhost postfix/postscreen[84375]: psc_endpt_lookup_done:
new + recent flags: NEW|PREGR_TODO|DNSBL_TODO
Mar  3 09:59:54 localhost postfix/postscreen[84375]: match_hostaddr:
postscreen_whitelist_interfaces: xx.xx.xx.xx ~?
static:all(0,lock|utf8_request)
Mar  3 09:59:54 localhost postfix/postscreen[84375]: > [85.54.217.239]:5089:
220-mail.example.com ESMTP Postfix (3.3.3)
Mar  3 09:59:54 localhost postfix/postscreen[84375]: send attr rbl_domain =
b.barracudacentral.org
Mar  3 09:59:54 localhost postfix/postscreen[84375]: send attr
client_address = 85.54.217.239
Mar  3 09:59:54 localhost postfix/postscreen[84375]: send attr label = 1
Mar  3 09:59:54 localhost postfix/postscreen[84375]: send attr rbl_domain =
zen.spamhaus.org
Mar  3 09:59:54 localhost postfix/postscreen[84375]: send attr
client_address = 85.54.217.239
Mar  3 09:59:54 localhost postfix/postscreen[84375]: send attr label = 1
Mar  3 09:59:54 localhost postfix/postscreen[84375]: master_notify: status 1
Mar  3 09:59:54 localhost postfix/dnsblog[84377]: addr 85.54.217.239 listed
by domain b.barracudacentral.org as 127.0.0.2
Mar  3 09:59:54 localhost postfix/postscreen[84375]: unknown_stream: wanted
attribute: rbl_domain
Mar  3 09:59:54 localhost postfix/postscreen[84375]: input attribute name:
rbl_domain
Mar  3 09:59:54 localhost postfix/postscreen[84375]: input attribute value:
b.barracudacentral.org
Mar  3 09:59:54 localhost postfix/postscreen[84375]: unknown_stream: wanted
attribute: client_address
Mar  3 09:59:54 localhost postfix/postscreen[84375]: input attribute name:
client_address
Mar  3 09:59:54 localhost postfix/postscreen[84375]: input attribute value:
85.54.217.239
Mar  3 09:59:54 localhost postfix/postscreen[84375]: unknown_stream: wanted
attribute: label
Mar  3 09:59:54 localhost postfix/postscreen[84375]: input attribute name:
label
Mar  3 09:59:54 localhost postfix/postscreen[84375]: input attribute value:
1
Mar  3 09:59:54 localhost postfix/postscreen[84375]: unknown_stream: wanted
attribute: rbl_addr
Mar  3 09:59:54 localhost postfix/postscreen[84375]: input attribute name:
rbl_addr
Mar  3 09:59:54 localhost postfix/postscreen[84375]: input attribute value:
127.0.0.2
Mar  3 09:59:54 localhost postfix/postscreen[84375]: unknown_stream: wanted
attribute: ttl
Mar  3 09:59:54 localhost postfix/postscreen[84375]: input attribute name:
ttl
Mar  3 09:59:54 localhost postfix/postscreen[84375]: input attribute value:
300
Mar  3 09:59:54 localhost postfix/postscreen[84375]: unknown_stream: wanted
attribute: (list terminator)
Mar  3 09:59:54 localhost postfix/postscreen[84375]: input attribute name:
(end)
Mar  3 09:59:54 localhost postfix/dnsblog[84376]: addr 85.54.217.239 listed
by domain zen.spamhaus.org as 127.0.0.11
Mar  3 09:59:54 localhost postfix/dnsblog[84376]: addr 85.54.217.239 listed
by domain zen.spamhaus.org as 127.0.0.4
Mar  3 09:59:54 localhost postfix/postscreen[84375]: unknown_stream: wanted
attribute: rbl_domain
Mar  3 09:59:54 localhost postfix/postscreen[84375]: input attribute name:
rbl_domain
Mar  3 09:59:54 localhost postfix/postscreen[84375]: input attribute value:
zen.spamhaus.org
Mar  3 09:59:54 localhost postfix/postscreen[84375]: unknown_stream: wanted
attribute: client_address
Mar  3 09:59:54 localhost postfix/postscreen[84375]: input attribute name:
client_address
Mar  3 09:59:54 localhost postfix/postscreen[84375]: input attribute value:
85.54.217.239
Mar  3 09:59:54 localhost postfix/postscreen[84375]: unknown_stream: wanted
attribute: label
Mar  3 09:59:54 localhost postfix/postscreen[84375]: input attribute name:
label
Mar  3 09:59:54 localhost postfix/postscreen[84375]: input attribute value:
1
Mar  3 09:59:54 localhost postfix/postscreen[84375]: unknown_stream: wanted
attribute: rbl_addr
Mar  3 09:59:54 localhost postfix/postscreen[84375]: input attribute name:
rbl_addr
Mar  3 09:59:54 localhost postfix/postscreen[84375]: input attribute value:
127.0.0.11 127.0.0.4
Mar  3 09:59:54 localhost postfix/postscreen[84375]: unknown_stream: wanted
attribute: ttl

Re: postscreen_dnsbl_action "drop" not working correctly?

[Wietse Venema]

Mayhem:
> Mar  3 10:00:00 localhost postfix/postscreen[84375]: DNSBL rank 2 for
> [85.54.217.239]:5089
> Mar  3 10:00:00 localhost postfix/postscreen[84375]: FAIL
> [85.54.217.239]:5089
> Mar  3 10:00:00 localhost postfix/postscreen[84375]: DROP
> [85.54.217.239]:5089
> Mar  3 10:00:00 localhost postfix/postscreen[84375]: flags for psc_conclude:
> NOFORWARD|NEW|PREGR_PASS|PREGR_TODO|DNSBL_FAIL|DNSBL_TODO|DNSBL_DONE
> Mar  3 10:00:00 localhost postfix/postscreen[84375]: > [85.54.217.239]:5089:
> 521 5.7.1 Service unavailable; client [85.54.217.239] blocked using
> b.barracudacentral.org
> Mar  3 10:00:00 localhost postfix/postscreen[84375]: DISCONNECT
> [85.54.217.239]:5089
> Mar  3 10:00:00 localhost postfix/postscreen[84375]: connection closed fd
> 128

And it's working as promised.

Wietse

Re: postscreen_dnsbl_action "drop" not working correctly?

[Mayhem]

No, the manual states "Drop the connection immediately with a 521 SMTP reply"
and that's not happening.

The 521 drop comes *after* the pregreet and DNSBL checks.

Mar  3 09:59:54 localhost postfix/dnsblog[84376]: addr 85.54.217.239 listed
by domain zen.spamhaus.org as 127.0.0.11
Mar  3 09:59:54 localhost postfix/dnsblog[84376]: addr 85.54.217.239 listed
by domain zen.spamhaus.org as 127.0.0.4
Mar  3 10:00:00 localhost postfix/postscreen[84375]: PASS pregreet test
[85.54.217.239]:5089
Mar  3 10:00:00 localhost postfix/postscreen[84375]: DNSBL rank 2 for
[85.54.217.239]:5089
Mar  3 10:00:00 localhost postfix/postscreen[84375]: FAIL
[85.54.217.239]:5089
Mar  3 10:00:00 localhost postfix/postscreen[84375]: DROP
Mar  3 10:00:00 localhost postfix/postscreen[84375]: > [85.54.217.239]:5089:
521 5.7.1 Service unavailable



--
Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html

rewriting From: address based on To: address

[Ian! D. Allen]

This is a query about how to have Postfix rewrite a From: address only
for messages sent to a particular destination address.

I've set my Postfix transport map so that most of my home email (From:
idal...@idallen.ca) goes out via my web host idallen.ca:

smtp:[idallen.ca]:submission

My College often throws idallen email into spam folders, so I have set
up a preceding transport map line that sends anything destined to my
College directly into the College with authentication:

mycollege.com smtp:[outlook.office365.com]:submission

In my mutt email client I created a send-hook that rewrites my From:
address to be the required address for my College (required for office365)
only for messages destined for my College.  If not going to my College,
mutt leaves the From: address set to idal...@idallen.ca.

That's great for messages I send with mutt, but it doesn't fix the
From: address for messages to my College sent using any other method
(e.g. directly with sendmail or using Perl, etc.); those other methods
still have From: idal...@idallen.ca and they get rejected by office365.

How can I have Postfix rewrite my From: address *only* for messages
destined for my College, or for messages using the mycollege.com transport
line (same thing)?  (Then I wouldn't need the mutt send-hook.)

Do I need to write my own "Postfix After-Queue Content Filter"
(http://www.postfix.org/FILTER_README.html) to do this?

-- 
| Ian! D. Allen, BA, MMath  -  idal...@idallen.ca - Ottawa, Ontario, Canada
| Home: www.idallen.com   Contact Improvisation Dance: www.contactimprov.ca
| Former college professor (Free/Libre GNU+Linux) at:  teaching.idallen.com
| Defend digital freedom:  http://eff.org/  and have fun:  http://fools.ca/

Re: Unexpected directories in virtual_mailbox_base

[Bill Cole]

On 1 Mar 2019, at 9:21, Thomas Seilund wrote:


On 01/03/2019 08.39, Andrey Repin wrote:

Greetings, Thomas Seilund!


smtp  inet  n   -   n   
-   -   smtpd -o
content_filter=spamfilter -o 
receive_override_options=no_address_mappings
spamfilter    unix  -   n   n   
-   -   pipe

flags=Rq user=vmail argv=/usr/bin/spamfilter.sh -oi -f ${sender}
${recipient}


Apparently, the reason you're filtering outbound mail is that you are 
having local users submit mail on port 25, using the same configuration 
of the smtpd daemon that is used for mail coming in from the Internet.


Best practice is to have port 587 "submission" (plaintext with STARTTLS 
support) and/or port 465 "smtps" ("wrappermode" TLS) transports, using 
smtpd with settings suited only for initial message submission. By 
splitting initial message submission from inbound message transport, you 
can make both services better and safer. This includes the options to 
not scan mail from your own users OR to scan it differently so that you 
don't create useless and unwanted directories for random remote 
recipients.



Furthermore, I have this script in /usr/bin/spamfilter:
#!/bin/bash
SENDMAIL=/usr/sbin/sendmail
SPAMASSASSIN=/usr/bin/spamc
RECEIVER=`echo $4 | tr '[:upper:]' '[:lower:]'`
${SPAMASSASSIN} -u $RECEIVER | ${SENDMAIL} "$@"
exit $?


That's almost the simplest shim possible between Postfix and 
SpamAssassin. To make it not try to use per-user configurations, just 
remove the "-u $RECEIVER" on the 5th line. That would be an appropriate 
script for use as the pipe target of an additional transport used as the 
content_filter of a submission or smtps service.



Finally, this is the parameters I have for SA in file
/etc/sysconfig/spamassassin:
SPAMDOPTIONS="--daemonize --create-prefs --max-children=5
--helper-home-dir=/mnt/ebs01/vmail/%d/%l/SpamAssassin 
--username=vmail
--nouser-config 
--virtual-config-dir=/mnt/ebs01/vmail/%d/%l/SpamAssassin"

export PYTHONPATH=/usr/lib/python2.6/site-packages


Easiest way to stop creating the unwanted directories: remove 
"--create-prefs" there. It won't solve the root cause, but it will fix 
the symptom.


If your users are not using personal spamassasin lists, you can just 
tell it

to use same user for all server works.


I assume I do use personal SA lists as I run like this:

-- Each user has a LearnAsSpam and LearnAsHam mailfolder.

-- I instruct users to move mails that SA falsely did not tag as spam 
to the LearnAsSpam folder


-- I instruct users to have at least 10 not spam messages in 
LearnAsHam


-- Once a day for each user I clear the bayes files and rebuild bayes 
files with:


-- sudo -u vmail sa-learn --username vmail --spam --dbpath 
$SUBDIR/SpamAssassin $SUBDIR/mail/LearnAsSpam/cur


-- sudo -u vmail sa-learn --username vmail --ham  --dbpath 
$SUBDIR/SpamAssassin $SUBDIR/mail/LearnAsHam/cur


-- $SUBDIR evaluates to each users vmail directory, ie. 
/mnt/ebs01/vmail/netmaster.dk/tps


If there is a better way to keep bayes upto date I would be happy to 
know.


Your users are unlikely to be actually using Bayes if you're clearing 
the databases daily. SA Bayes will not score messages AT ALL if its 
database doesn't have enough messages learned to have a statistically 
valid sample size, set by default to 200 each of spam and ham. That's 
high enough to avoid most cases of Bayes being actively bad, but Bayes 
doesn't really work *well* until it has about a thousand messages 
analyzed.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole

Re: postscreen_dnsbl_action "drop" not working correctly?

[Wietse Venema]

Wietse Venema:
> Mayhem:
> > Mar  3 10:00:00 localhost postfix/postscreen[84375]: DNSBL rank 2 for
> > [85.54.217.239]:5089
> > Mar  3 10:00:00 localhost postfix/postscreen[84375]: FAIL
> > [85.54.217.239]:5089
> > Mar  3 10:00:00 localhost postfix/postscreen[84375]: DROP
> > [85.54.217.239]:5089
> > Mar  3 10:00:00 localhost postfix/postscreen[84375]: flags for psc_conclude:
> > NOFORWARD|NEW|PREGR_PASS|PREGR_TODO|DNSBL_FAIL|DNSBL_TODO|DNSBL_DONE
> > Mar  3 10:00:00 localhost postfix/postscreen[84375]: > [85.54.217.239]:5089:
> > 521 5.7.1 Service unavailable; client [85.54.217.239] blocked using
> > b.barracudacentral.org
> > Mar  3 10:00:00 localhost postfix/postscreen[84375]: DISCONNECT
> > [85.54.217.239]:5089
> > Mar  3 10:00:00 localhost postfix/postscreen[84375]: connection closed fd
> > 128
> 
> And it's working as promised.

The logging shows that postscreen closes the connection immediately
after sending "521 5.7.1 Service unavailable".

Wietse

Re: rewriting From: address based on To: address

[Wietse Venema]

Ian! D. Allen:
> This is a query about how to have Postfix rewrite a From: address only
> for messages sent to a particular destination address.
> 
> I've set my Postfix transport map so that most of my home email (From:
> idal...@idallen.ca) goes out via my web host idallen.ca:
> 
> smtp:[idallen.ca]:submission
> 
> My College often throws idallen email into spam folders, so I have set
> up a preceding transport map line that sends anything destined to my
> College directly into the College with authentication:
> 
> mycollege.com smtp:[outlook.office365.com]:submission
> 
> In my mutt email client I created a send-hook that rewrites my From:
> address to be the required address for my College (required for office365)
> only for messages destined for my College.  If not going to my College,
> mutt leaves the From: address set to idal...@idallen.ca.
> 
> That's great for messages I send with mutt, but it doesn't fix the
> From: address for messages to my College sent using any other method
> (e.g. directly with sendmail or using Perl, etc.); those other methods
> still have From: idal...@idallen.ca and they get rejected by office365.
> 
> How can I have Postfix rewrite my From: address *only* for messages
> destined for my College, or for messages using the mycollege.com transport
> line (same thing)?  (Then I wouldn't need the mutt send-hook.)

This needs a dedicated SMTP transport for the college, smtp_generic_maps
setting that replaces idal...@idallen.ca with your college email address.

master.cf:
smtp  unix  -   -   n   -   -   smtp
-o smtp_generic_maps=maptype:mapname

Or with Postfix 3 and later:

master.cf:
smtp  unix  -   -   n   -   -   smtp
-o { smtp_generic_maps = inline:{{idal...@idallen.ca = you@college}}}

Which keeps it all together in one place.

This updates envelope addresses and header addresses.

Wietse

From address for delivery failure notifications

[Martin Brampton]

Is there a way to set a from address for Postfix automatic messages on 
delivery failure?

Re: postscreen_dnsbl_action "drop" not working correctly?

[Mayhem]

Could someone update the manual for clarification then?

The manual suggests the connection will close immediately - and that's it.
As is stands now, it makes no mention that it will "Allow other tests to
complete" first.

ignore : Ignore the failure of this test. Allow other tests to complete.

enforce : Allow other tests to complete. Reject attempts to deliver mail
with a 550 SMTP reply

drop : Drop the connection immediately with a 521 SMTP reply.

-

With that said, when  postscreen_dnsbl_action is set to "drop" - why does it
still do the pregreet & DNSBL tests? Why not drop the connection immediately
and omit those tests?



--
Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html

Re: From address for delivery failure notifications

[Wietse Venema]

Martin Brampton:
> Is there a way to set a from address for Postfix automatic messages on 
> delivery failure?

With command-line submission:
sendmail -f bounce-address recipient-address...

With SMTP submission:
MAIL FROM:...

With QMQP, the bounce address is the second protocol field (immediately
after the message content which is field 1), if I recall correctly.

Wietse

Re: From address for delivery failure notifications

[Martin Brampton]

Thanks, but I'm looking for a way to set a default in postfix, not to 
set a bounce address for a particular email. Is that possible?



On 03/03/2019 21:13, Wietse Venema wrote:

Martin Brampton:

Is there a way to set a from address for Postfix automatic messages on
delivery failure?


With command-line submission:
 sendmail -f bounce-address recipient-address...

With SMTP submission:
 MAIL FROM:...

With QMQP, the bounce address is the second protocol field (immediately
after the message content which is field 1), if I recall correctly.

Wietse

Re: From address for delivery failure notifications

[Wietse Venema]

Martin Brampton:
> Is there a way to set a from address for Postfix automatic messages on
> delivery failure?

On 03/03/2019 21:13, Wietse Venema wrote:
> With command-line submission:
>  sendmail -f bounce-address recipient-address...
> 
> With SMTP submission:
>  MAIL FROM:...
> 
> With QMQP, the bounce address is the second protocol field (immediately
> after the message content which is field 1), if I recall correctly.

Martin Brampton:
> Thanks, but I'm looking for a way to set a default in postfix, not to 
> set a bounce address for a particular email. Is that possible?

To override the bounce address and the From: header:

/etc/postfix/main.cf:
sender_canonical_maps = static:f...@example.com

To override the bounce address without changing the From: header:

/etc/postfix/main.cf:
sender_canonical_maps = static:f...@example.com
sender_canonical_classes = envelope_sender

Wietse

latest 3.5 experimental release

[John Fawcett]

Hi Wietse

just in case you're not aware of it: the latest experimental release
does not seem to be present at this link

ftp://ftp.porcupine.org/mirrors/postfix-release/experimental/postfix-3.5-20190301.tar.gz

or the equivalent mirror links.

John

Re: latest 3.5 experimental release

[Wietse Venema]

John Fawcett:
> Hi Wietse
> 
> just in case you're not aware of it: the latest experimental release
> does not seem to be present at this link
> 
> ftp://ftp.porcupine.org/mirrors/postfix-release/experimental/postfix-3.5-20190301.tar.gz
> 
> or the equivalent mirror links.

It was under /mirrors/official/. I have updated the master copy.

Wietse

Re: postscreen_dnsbl_action "drop" not working correctly?

[Bill Cole]

On 3 Mar 2019, at 14:54, Mayhem wrote:

No, the manual states "Drop the connection immediately with a 521 SMTP 
reply"

and that's not happening.

The 521 drop comes *after* the pregreet and DNSBL checks.


Because the basis for the drop IS the DNSBL checks. Postscreen cannot 
drop a connection because of a test it does not perform.




Mar  3 09:59:54 localhost postfix/dnsblog[84376]: addr 85.54.217.239 
listed

by domain zen.spamhaus.org as 127.0.0.11
Mar  3 09:59:54 localhost postfix/dnsblog[84376]: addr 85.54.217.239 
listed

by domain zen.spamhaus.org as 127.0.0.4
Mar  3 10:00:00 localhost postfix/postscreen[84375]: PASS pregreet 
test

[85.54.217.239]:5089
Mar  3 10:00:00 localhost postfix/postscreen[84375]: DNSBL rank 2 for
[85.54.217.239]:5089
Mar  3 10:00:00 localhost postfix/postscreen[84375]: FAIL
[85.54.217.239]:5089
Mar  3 10:00:00 localhost postfix/postscreen[84375]: DROP
Mar  3 10:00:00 localhost postfix/postscreen[84375]: > 
[85.54.217.239]:5089:

521 5.7.1 Service unavailable



--
Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole

Re: Maximum simultaneous outbounds ?

[Ronald F. Guilmette]

In message <44c5tp4v0yzj...@spike.porcupine.org>, you wrote:

>Postfix is in a different league than software that just runs the
>system into the ground under load, and that requires a babysitter
>to become unstuck.

Thanks for the clarification and the clarity.

You wouldn't happen to have the names of any products that fall
into that other category that you just described would you?

(It really irks me the way that some people demand lots and lots of
IPv4 addresses, which are in short supply, in order to accomplish
things that could be done with lots lots less of that particular
finite and limited resource.  But convincing some of these folks
of the error of their ways isn't easy, and I could use all of the
additional ammunition that I can lay hands on.)

Re: Maximum simultaneous outbounds ?

[Ronald F. Guilmette]

In message <20190303184645.gl...@straasha.imrryr.org>, Viktor wrote:

>I could also point out that TCP stacks can allow the same local
>ephemeral port to be used for multiple TCP connections, provided
>the 4-tuple (remote ip, remote port, local ip, local port) is unique.
>There is no requirement that just the local ports of established
>TCP connections be distinct.

This answers my original and most fundamental question, and confirms
what I believed I already knew about the potential for simultaneous
local IPv4 port reuse.  So thanks for that.

>Well, it seems that you only knew the empirical conclusions.  Had you
>known how Postfix ensures performance under load, you'd have refuted
>the other fellow's false scenario without coming to the list.

Well, when arguing (e.g. on a mailing list) with someone who consistantly
drops down into the classic retorical "appeal to authority" mode (as
in: "I know, you don't, and you are an idiot, so STFU!') it is usually
best to get a pronouncement from a a different authority having a
different view, if the goal is to refute the false "appeal to authority"
being put forward.  So I came here.

I personally don't know off the top of my head any folks who are more
widely considered "authorities" on how mail servers can and should work
than you and Wietse.

>> I still would like to know if the total number of outbound SMTP connections
>> which Postfix may have open, at any one given point in time, may or may not
>> exceed 65536.
>
>This is a silly question.  Typical message delivery latency can be
>estimated at around 1s.  A hypothetical server running at a concurrency
>of 64k connections would be pumping out 64k msgs/sec, but the Postfix
>queue manager and the disk are very unlikely to go that fast.
>Realistically, a single email server may be able to deliver at best
>O(1000) msgs/sec.
>
>At a hypothetical sustained 64k messages per second, a server would
>be able to deliver around 5.6 billion messages a day.  That's not
>a realistic load for a single machine, either inbound or outbound.
>
>Real servers handle smaller loads with outbound concurrency limits
>in the hundreds or a few thousand.  With Postfix brief input spikes
>that exceed the output rate lead growth in the size of the queue
>without unbounded demand for CPU and network.
>
>There are also caps on concurrent incoming connections, and
>sufficiently high input rates will reduce opportunities for new
>connections, forcing some or most senders to defer delivery.  That's
>what horizontal scaling is for, with anycast IPs to spread the load
>geographically, and in-datacentre load-balancers to further spread
>the load among multiple machines, ...

Well, but see, this is precisly what the argument was/is about.  

As soon as you start talking about load balancers, you are also taking
about more than one IP address.

It was and is my contention that even great vast gobs of outbound email
can be handled on a single IPv4 address, *if* one is doing it "right".
And by "right" in this context, I mean having a great big pipe into the
machine in question, having the machine itself be something killer, like
fer instance a 32-core Ryzen or something, and having the "disk" be
something like a 1TB NVME stick, or maybe even... dare I say it?... Optane!

Basically, my central thesis in this other conversation that I'm having
elsewhere is that current usage norms when it comes to (finite and vanishing)
IPv4 addresses are, by and large, exceptionally wasteful and that allocation
policy should be adjusted accordingly.

My opponents in this debate have used and are using mutiple (mostly lame)
arguments for why they need lots and lots of IPv4 addreses.  I was able
to rather easily shoot down most of those (obviously lame) arguments on
my own, but when it came to this question of how many simultaneous outbound
mail sessions could dance on the head of a single IPv4 address, I had
to ask for some help which I believe I have now, mostly, gotten.
(Thank you.)


Regards,
rfg

Re: Maximum simultaneous outbounds ?

[Wietse Venema]

Ronald F. Guilmette:
> 
> In message <44c5tp4v0yzj...@spike.porcupine.org>, you wrote:
> 
> >Postfix is in a different league than software that just runs the
> >system into the ground under load, and that requires a babysitter
> >to become unstuck.
> 
> Thanks for the clarification and the clarity.
> 
> You wouldn't happen to have the names of any products that fall
> into that other category that you just described would you?

Let's say that Postfix was influenced by good and bad experiences
with other software.

Wietse

Re: rewriting From: address based on To: address

[Ian! D. Allen]

On Sun, Mar 03, 2019 at 03:51:35PM -0500, Wietse Venema wrote:
> smtp  unix  -   -   n   -   -   smtp
> -o { smtp_generic_maps = inline:{{idal...@idallen.ca = you@college}}}

Am I right that since my master.cf already has a "smtp unix" entry, the
above "smtp unix" line would over-ride it and change the From lines in
*all* my outgoing messages?

> Which keeps it all together in one place.

Am I right that I actually have to do these two things (two places):

1. Change my existing College transport map to select a unique service name,
and
2. make main.cf use the same new service name

Like this (two places, not just one)?

transport:
mycollege.com smtpcollege:[outlook.office365.com]:submission

main.cf:
smtpcollege  unix  -   -   n   -   -   smtp
-o { smtp_generic_maps = inline:{{idal...@idallen.ca = 
i...@mycollege.com}}}

-- 
| Ian! D. Allen, BA, MMath  -  idal...@idallen.ca - Ottawa, Ontario, Canada
| Home: www.idallen.com   Contact Improvisation Dance: www.contactimprov.ca
| Former college professor (Free/Libre GNU+Linux) at:  teaching.idallen.com
| Defend digital freedom:  http://eff.org/  and have fun:  http://fools.ca/

Re: rewriting From: address based on To: address

[Ian! D. Allen]

On Sun, Mar 03, 2019 at 03:51:35PM -0500, Wietse Venema wrote:
> smtp  unix  -   -   n   -   -   smtp
> -o { smtp_generic_maps = inline:{{idal...@idallen.ca = you@college}}}
> This updates envelope addresses and header addresses.

Well, the above correctly updates *most* header addresses, but is a bit
too aggressive about the ones it does update.

I have my mutt client insert an "x-sender: Ian "
and the above inline mapping does *not* change that header line address.
So it doesn't update *all* header addresses and this is good for me.

I also have my mutt client insert a "Reply-to: idal...@idallen.ca" header,
and the above inline mapping *does* change that to be my College address.
I didn't want the Reply-To changed, so I tried this:

I changed to using "Reply-to: Ian " and the
inline mapping *still* replaced it with my College address, even though
"idal...@idallen.ca" doesn't match "idallen+...@idallen.ca".

I changed to using "Reply-to: Ian " and the inline
mapping did leave it alone, so I know it's not just replacing everything.
The inline mapping is ignoring the "+stuff" part of my email addresses.

How do I sneak through a Reply-To that goes to idal...@idallen.ca ?

-- 
| Ian! D. Allen, BA, MMath  -  idal...@idallen.ca - Ottawa, Ontario, Canada
| Home: www.idallen.com   Contact Improvisation Dance: www.contactimprov.ca
| Former college professor (Free/Libre GNU+Linux) at:  teaching.idallen.com
| Defend digital freedom:  http://eff.org/  and have fun:  http://fools.ca/

Re: rewriting From: address based on To: address

[Wietse Venema]

Ian! D. Allen:
> On Sun, Mar 03, 2019 at 03:51:35PM -0500, Wietse Venema wrote:
> > smtp  unix  -   -   n   -   -   smtp
> > -o { smtp_generic_maps = inline:{{idal...@idallen.ca = you@college}}}
> > This updates envelope addresses and header addresses.
> 
> Well, the above correctly updates *most* header addresses, but is a bit
> too aggressive about the ones it does update.

It changes standard headers that usually specify sender information,
like From and Reply-To, not non-standard headers like X-Mumble.

> How do I sneak through a Reply-To that goes to idal...@idallen.ca ?

Postfix is an MTA, not a content-management system. For complex
rewriting policies use a plugin: a filter or milter. Maybe Sendmail
can do it with built-ins.

Wietse

Re: rewriting From: address based on To: address

[Wietse Venema]

Wietse Venema:
> Ian! D. Allen:
> > On Sun, Mar 03, 2019 at 03:51:35PM -0500, Wietse Venema wrote:
> > > smtp  unix  -   -   n   -   -   smtp
> > > -o { smtp_generic_maps = inline:{{idal...@idallen.ca = you@college}}}
> > > This updates envelope addresses and header addresses.
> > 
> > Well, the above correctly updates *most* header addresses, but is a bit
> > too aggressive about the ones it does update.
> 
> It changes standard headers that usually specify sender information,
> like From and Reply-To, not non-standard headers like X-Mumble.
> 
> > How do I sneak through a Reply-To that goes to idal...@idallen.ca ?
> 
> Postfix is an MTA, not a content-management system. For complex
> rewriting policies use a plugin: a filter or milter. Maybe Sendmail
> can do it with built-ins.

Or make the header_opts table configurable; this is where all
the header properties are currently hard-coded.

Wietse

Re: Maximum simultaneous outbounds ?

[LuKreme]

On Mar 3, 2019, at 16:17, Ronald F. Guilmette  wrote:
> You wouldn't happen to have the names of any products that fall
> into that other category that you just described would you?

rsync done this to my system in the past.

-- 
My main job is trying to come up with new and innovative and effective ways to 
reject even more mail. I'm up to about 97% now.

Re: postscreen_dnsbl_action "drop" not working correctly?

[Mayhem]

I was under the impression that Postscreen kept a cache of the IP addresses
that failed Pregreet / DNSBL tests.Then it would use those cached results to
drop clients immediately based on that previously cached results / expire
time.

What is throwing me off is this :

postscreen_dnsbl_max_ttl :

The maximum amount of time that postscreen(8) will use the result from a
successful DNS-based  reputation test before a client IP address is required
to pass that test again.

--

If the IP address and the result is cached, why not use those results to
drop the connection until the TTL has expired?



--
Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html

Change 451 Temp Lookup code to permanent 550 code for unknown local recipients

[James Brown]

Postfix 3.4.0, using Dovecot for SASL authentication and MySQL.

I have set:

unknown_local_recipient_reject_code = 550

But when an email comes through to an unknown user, a 451 Temporary Lookup 
Failure code is given, not a 550:

2019-03-04 15:52:00.949864+1100  localhost smtpd[25337]: connect from 
localhost[127.0.0.1]
2019-03-04 15:52:01.246686+1100  localhost smtpd[12280]: warning: connect to 
mysql server 127.0.0.1: Access denied for user 'postfix'@'localhost' (using 
password: YES)
2019-03-04 15:52:01.246723+1100  localhost smtpd[12280]: warning: 
mysql:/usr/local/etc/postfix/mysql_virtual_mailbox_maps.cf lookup error for 
"annie.cli...@bordo.com.au "
2019-03-04 15:52:01.246747+1100  localhost smtpd[12280]: NOQUEUE: reject: RCPT 
from localhost[127.0.0.1]: 451 4.3.0 mailto:annie.cli...@bordo.com.au>>: Temporary lookup failure; 
from=mailto:purch...@thorintl.com>> 
to=mailto:annie.cli...@bordo.com.au>> proto=ESMTP 
helo=http://astaro1.bordo.com.au/>?-?192.168.1.2?-?mail.bordo.com.au 
?-?mail.bordo.com.au >

This causes the sending mail server to store the email and try several times.

This is the sort of thing the sending mail server sees:

Connected to mail.bordo.com.au .
Escape character is '^]'.
220 mail.bordo.com.au  ESMTP Postfix
EHLO me 
250-mail.bordo.com.au 
250-STARTTLS
250-SIZE 10240
250-AUTH PLAIN
250-AUTH=PLAIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250 NOOP
mail from: jlbr...@bordo.com.au 
250 2.1.0 Ok
rcpt to: sdf...@bordo.com.au 
451 4.3.0 mailto:sdf...@bordo.com.au>>: Temporary lookup 
failure
Connection closed by foreign host.

How can I get it to send a permanent failure code?

Thanks,

James.

smime.p7s
Description: S/MIME cryptographic signature

Re: Change 451 Temp Lookup code to permanent 550 code for unknown local recipients

[Pau Amma]

On Mon, March 4, 2019 5:29 am, James Brown wrote:
> Postfix 3.4.0, using Dovecot for SASL authentication and MySQL.
>
> I have set:
>
> unknown_local_recipient_reject_code = 550
>
> But when an email comes through to an unknown user, a 451 Temporary Lookup
> Failure code is given, not a 550:
>
> 2019-03-04 15:52:00.949864+1100  localhost smtpd[25337]: connect from
> localhost[127.0.0.1]
> 2019-03-04 15:52:01.246686+1100  localhost smtpd[12280]: warning: connect
> to mysql server 127.0.0.1: Access denied for user 'postfix'@'localhost'
> (using password: YES)

I think Postfix is temp-rejecting in this case to give you a chance to fix
this before the next sender retry attempt.

Re: Change 451 Temp Lookup code to permanent 550 code for unknown local recipients

[Viktor Dukhovni]

[ Just this once, I'm going to make an exception and send HTML email. It's only
   new content is colour added to two snippets of the original text. ]

> On Mar 4, 2019, at 12:29 AM, James Brown  wrote:
> 
> 2019-03-04 15:52:00.949864+1100  localhost smtpd[25337]: connect from 
> localhost[127.0.0.1]
> 2019-03-04 15:52:01.246686+1100  localhost smtpd[12280]: warning: connect to 
> mysql server 127.0.0.1: Access denied for user 'postfix'@'localhost' (using 
> password: YES)
> 2019-03-04 15:52:01.246723+1100  localhost smtpd[12280]: warning: 
> mysql:/usr/local/etc/postfix/mysql_virtual_mailbox_maps.cf lookup error for 
> "annie.cli...@bordo.com.au"
> 2019-03-04 15:52:01.246747+1100  localhost smtpd[12280]: NOQUEUE: reject: 
> RCPT from localhost[127.0.0.1]: 451 4.3.0 : 
> Temporary lookup failure; from= 
> to= proto=ESMTP 
> helo=

[ For anyone reading this in mutt, pine, elm, ... the "mysql" table warnings
  have been emphasized for the OP.  With a bit of luck he'll realize that 
failure
  to access the database is not an instance of "unknown local recipient". ]

-- 
-- 
Viktor.

Re: Change 451 Temp Lookup code to permanent 550 code for unknown local recipients

[James Brown]

> On 4 Mar 2019, at 4:40 pm, Viktor Dukhovni  wrote:
> 
> [ Just this once, I'm going to make an exception and send HTML email. It's 
> only
>new content is colour added to two snippets of the original text. ]
> 
>> On Mar 4, 2019, at 12:29 AM, James Brown  wrote:
>> 
>> 2019-03-04 15:52:00.949864+1100  localhost smtpd[25337]: connect from 
>> localhost[127.0.0.1]
>> 2019-03-04 15:52:01.246686+1100  localhost smtpd[12280]: warning: connect to 
>> mysql server 127.0.0.1: Access denied for user 'postfix'@'localhost' (using 
>> password: YES)
>> 2019-03-04 15:52:01.246723+1100  localhost smtpd[12280]: warning: 
>> mysql:/usr/local/etc/postfix/mysql_virtual_mailbox_maps.cf lookup error for 
>> "annie.cli...@bordo.com.au"
>> 2019-03-04 15:52:01.246747+1100  localhost smtpd[12280]: NOQUEUE: reject: 
>> RCPT from localhost[127.0.0.1]: 451 4.3.0 : 
>> Temporary lookup failure; from= 
>> to= proto=ESMTP 
>> helo=
> 
> [ For anyone reading this in mutt, pine, elm, ... the "mysql" table warnings
>   have been emphasized for the OP.  With a bit of luck he'll realize that 
> failure
>   to access the database is not an instance of "unknown local recipient". ]

Thanks Pau and Victor. Sorry about the HTML email.

The access denied warning has now been fixed - I had not changed the password 
in mysql_virtual_mailbox_maps.cf. No longer getting that error - thanks!

And sender is now getting a 550 error!

2019-03-04 17:38:35.647068+1100  localhost smtpd[75996]: connect from 
localhost[127.0.0.1]
2019-03-04 17:38:36.636562+1100  localhost smtpd[75996]: NOQUEUE: reject: RCPT 
from localhost[127.0.0.1]: 550 5.1.1 : Recipient 
address rejected: User unknown in virtual mailbox table; 
from= to= proto=ESMTP 
helo=
2019-03-04 17:38:36.914926+1100  localhost cleanup[79609]: CDAC911DFB34: 
message-id=<20190304063836.cdac911df...@mail.bordo.com.au>
2019-03-04 17:38:37.043967+1100  localhost smtpd[75996]: disconnect from 
localhost[127.0.0.1] ehlo=1 starttls=0/1 mail=1 rcpt=0/1 quit=1 commands=3/5

Thanks again,

James.


smime.p7s
Description: S/MIME cryptographic signature