[pfx] Re: returned message path
On 25.08.23 13:45, Henrik Y via Postfix-users wrote: If the messages was delivered into peer system, and peer MTA found it was invalid for delivery, will this message be returned back to the sender host, or returned back to MX server of sender domain? In addition to what has been said, the delivery failure results into new message (bounce) being generated and sent to the envelope sender address. Since there can be different servers for outgoing and incoming mail, it makes no sense to return message to host mail has been received from. There are cases of servers sending e-mail with envelope from: set to e.g. www1.example.com, where www1.example.com is the sending host that does not receive mail and has no MX records, do the bounce sits in queue until it expires. However this should not be your problem. -- 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. How does cat play with mouse? cat /dev/mouse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Spam mails seen in logfiles question
Bill Cole via Postfix-users: > On 2023-08-23 at 14:38:18 UTC-0400 (Wed, 23 Aug 2023 12:38:18 -0600) > IUL Support via Postfix-users > is rumored to have said: > > > I must be missing something in what you're saying. > > > > If the server receives a message for myu...@mydomain.com and myuser's > > mailbox is full... by default the server generates a bounce, I don't > > see any > > way around that. > > In most modern configurations of Postfix, a full mailbox will result in > a rejection code in SMTP. The incoming message is never queued. If the > sender uses the ESMTP SIZE extension, the receiving server may reject an > oversize message without seeing the message data at all. ...modern versions that integrate with Dovecot, so that the Postfix check_pilocy_service feature can query Dovecot. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] DANE monitoring building block: updated "danesmtp" shell function
On Wed, Aug 16, 2023 at 07:48:30PM -0400, Viktor Dukhovni wrote:
> Problem found via:
>
> danesmtp ()
> {
> local host=$1;
> shift;
> local opts=(-starttls smtp -connect "$host:25" -verify 9
> -verify_return_error -dane_ee_no_namechecks -dane_tlsa_domain "$host");
> set -- $(dig +short +nosplit -t tlsa "_25._tcp.$host" | egrep -i
> '^[23] [01] [012] [0-9a-f]+$');
> while [ $# -ge 4 ]; do
> opts=("${opts[@]}" "-dane_tlsa_rrdata" "$1 $2 $3 $4");
> shift 4;
> done;
> ( sleep 1;
> printf "QUIT\r\n" ) | openssl s_client -tls1_2 -cipher 'aRSA:aECDSA'
> "${opts[@]}"
> }
New/improved "danesmtp" shell (bash) function. The updated version can
take an optional explicit IP address to connect to, so you can test each
of the IP addresses of a host in turn:
danesmtp () {
local OPTIND=1 opt
local -a rrs sslopts
local rr i=0 host addr
while getopts a: opt; do
case $opt in
a) addr=$OPTARG
case $addr in *:*) addr="[$addr]";; esac;;
*) printf 'usage: danesmtp [-a addr] host [ssloption ...]\n'
return 1;;
esac
done
shift $((OPTIND - 1))
host=$1
shift
if [[ -z "$addr" ]]; then
addr="$host"
fi
sslopts=(-starttls smtp -connect "$addr:25"
-verify 9 -verify_return_error
-dane_ee_no_namechecks -dane_tlsa_domain "$host")
rrs=( $(dig +short +nosplit -t tlsa "_25._tcp.$host" |
grep -Ei '^[23] [01] [012] [0-9a-f]+$') )
while (( i < ${#rrs[@]} - 3 )); do
rr=${rrs[@]:$i:4}
i=$((i+4))
sslopts=("${sslopts[@]}" "-dane_tlsa_rrdata" "$rr")
done
( sleep 1; printf "QUIT\r\n" ) | openssl s_client -brief
"${sslopts[@]}" "$@"
}
--
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] BUG: Postfix deals badly with corrected-typo in aliases :(
SUMMARY * Scenario/repeatability: - Typical default postfix configuration - An alias is added, but with a typo. - Incoming email is rejected as expected, "Recipient address rejected: undeliverable address: unknown user: "address" - Typo corrected. newaliases is used. Postfix can be restarted. Doesn't matter. - Local email to the alias now works - Incoming email is still rejected, as it fails reject_unverified_recipient. Even ten hours later. * Expected result - After newaliases, and particularly after postfix reload, the alias should function. * Turned on debugging to log level 10. Revealed nothing interesting. * Analysis - See www.postfix.org/ADDRESS_VERIFICATION_README.html#caching - Since Postfix 2.7, there's a persistent verification database. - By default, address_verify_map = btree:$data_directory/verify_cache - By default, the database survives newaliases, postfix reload, and postfix stop - By default, all failed probes (even of local/aliases) expire after three days. - Workaround: postfix stop; rm $data_directory/verify_cache.db; postfix start * Discussion - This is a very non-intuitive implementation, and very difficult for an average admin to diagnose: no information points to the verification cache. - Having examined the (verify.c) code, I realize a 'nice' solution (clear cache of local address entries after newaliases) isn't that simple. Someone with more experience can likely design a proper fix. * Suggestions - At the very least, this needs to be highlighted in documentation for newaliases etc - Next step: distinguish local and non-local addresses; enable reset of local cache entries after newaliases. [end] ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: BUG: Postfix deals badly with corrected-typo in aliases :(
On Fri, Aug 25, 2023 at 08:07:01PM -0600, Pete Holzmann via Postfix-users wrote: > SUMMARY > > * Scenario/repeatability: >- See www.postfix.org/ADDRESS_VERIFICATION_README.html#caching >- Since Postfix 2.7, there's a persistent verification database. Actually, there isn't, or, more precisely, it isn't actually used by default. You have to choose to enable recipient verification, and if you do, you have read the fine documentation on address verification, including the documentation on the cache TTLs in: http://www.postfix.org/verify.8.html which is referenced from, e.g. http://www.postfix.org/ADDRESS_VERIFICATION_README.html#dirty_secret and various other sections. >- By default, all failed probes (even of local/aliases) expire after >three days. As documented, but there should also be a background refresh every 3 hours, so that the second try 3h after correcting the problem, will succeed: address_verify_negative_expire_time = 3d address_verify_negative_refresh_time = 3h address_verify_positive_expire_time = 31d address_verify_positive_refresh_time = 7d >- Workaround: postfix stop; rm $data_directory/verify_cache.db; >postfix start Tune the settings to your needs. There's no need to remove the database. That also wipes your positive cache results. >- This is a very non-intuitive implementation, and very difficult for >an average admin to diagnose: no information points to the >verification cache. Only if you haven't read the documentation. >- Having examined the (verify.c) code, I realize a 'nice' solution >(clear cache of local address entries after newaliases) isn't that >simple. Someone with more experience can likely design a proper fix. Reading the code is not necessary. Just the documentation is sufficient. > * Suggestions >- At the very least, this needs to be highlighted in documentation >for newaliases etc No, newaliases have nothing to do with this. This is entirely material for ADDRESS_VERIFICATION_README and verify(8), but perhaps the timer parameters could be also mentioned prominently in the README file. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
