Re: Problem with sending mail from localhost but not remote host
Hi, I have finally figured out the problem and it was nothing to do with Postfix. The application on the local server had been misconfigured and was supplying an incorrect value (undefined) to the BCC field which had been completely overlooked in the logs. Apologies for taking up your time on this (but I have learnt a lot about debugging the whole Postfix/mail process - so time well spent on my part!). Thanks Steve On 30 Sep 2014, at 15:50, Wietse Venema wrote: > Steve Hawes: >> Will try that and see what I get though what I do not understand >> is why it works fine for a remote client but not if the client is >> localhost. What would cause the difference? > > There are many examples where Postfix can make a query for non-existent > information. Trying to avoid one specific example is a waste of > time. You would run into the same problem again elsewhere. Fix the > database query. > > Wietse
Re: Postfix original_recipient
Thank you for notice Bill. I'll try paste all again as text:
I noticed that in my postfix configuration there is a problem with
${original_recipient} which is not set or is overwritten by
${recipient}
My master.cf is below. The problem is that in the autoresponder -r
${original_recipient} is equal to ${recipient}.
Because of that, if user address belongs to a group (aliases) then if
sender sends message to this group then the autoresponder responds
from uses address. I want autoresponder only replay if the mail was
sent directly to the user (not throught alias).
I'd like to know the ${original_recipient} to check if the mail was
sent directly to user or to alias group.
# ==
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==
smtp inet n - n - - smtpd
# -o smtp_send_xforward_command=yes
amavisunix - - n - 4 smtp
-o smtp_data_done_timeout=1200
-o smtp_send_xforward_command=yes
-o disable_dns_lookups=yes
-o max_use=20
-o
receive_override_options=no_unknown_recipient_checks,no_header_body_checks,no_address_mappings
# -o receive_override_options=no_address_mappings
#smtp inet n - n - 1 postscreen
#smtpd pass - - n - - smtpd
#dnsblog unix - - n - 0 dnsblog
#tlsproxy unix - - n - 0 tlsproxy
#submission inet n - n - - smtpd
# -o smtpd_tls_security_level=encrypt
# -o smtpd_sasl_auth_enable=yes
# -o smtpd_tls_auth_only=yes
# -o smtpd_client_restrictions=permit_sasl_authenticated,reject
# -o smtpd_sasl_security_options=noanonymous
# -o smtpd_sasl_tls_security_options=noanonymous
## -o milter_macro_daemon_name=ORIGINATING
smtps inet n - n - - smtpd
#-o content_filter=autoresponder:dummy #włączenie tego spowoduje
dublowanie wszystkich maili
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_tls_auth_only=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o smtpd_sasl_security_options=noanonymous
-o smtpd_sasl_tls_security_options=noanonymous
-o milter_macro_daemon_name=ORIGINATING
-o receive_override_options=no_address_mappings
#628 inet n - n - - qmqpd
pickupfifo n - n 60 1 pickup
-o content_filter=
-o receive_override_options=no_header_body_checks
cleanup unix n - n - 0 cleanup
qmgr fifo n - n 300 1 qmgr
#qmgr fifo n - n 300 1 oqmgr
tlsmgrunix - - n 300 1 tlsmgr
rewrite unix - - n - - trivial-rewrite
bounceunix - - n - 0 bounce
defer unix - - n - 0 bounce
trace unix - - n - 0 bounce
verifyunix - - n - 1 verify
flush unix n - n 1000? 0 flush
proxymap unix - - n - - proxymap
proxywrite unix - - n - 1 proxymap
smtp unix - - n - - smtp
# When relaying mail as backup MX, disable fallback_relay to avoid MX loops
relay unix - - n - - smtp
-o smtp_fallback_relay=
# -o smtp_helo_timeout=5
# -o smtp_connect_timeout=5
showq unix n - n - - showq
error unix - - n - - error
retry unix - - n - - error
discard unix - - n - - discard
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - n - - lmtp
anvil unix - - n - 1 anvil
localhost:10025 inet n - n - - smtpd
-o content_filter=autoresponder:dummy
-o smtpd_delay_reject=no
-o smtpd_client_restrictions=permit_mynetworks,reject
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o smtpd_data_restrictions=reject_unauth_pipelining
-o smtpd_end_of_data_restrictions=
-o smtpd_restriction_classes=
-o mynetworks=127.0.0.0/8
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000
-o smtpd_client_connection_count_limit=0
-o smtpd_client_connection_rate_limit=0
-o
receive_override_options=no_unknown_recipient_checks,no_header_body_checks,no_address_map
Re: postfix not able to send email
Thanks everyone. Troubleshooting was much pain. I built it from scratch and it works fine now. Re, -- // Subin On Tuesday 23 September 2014 08:00 PM, Viktor Dukhovni wrote: On Tue, Sep 23, 2014 at 10:55:32AM +0200, Christian R??ner wrote: Debian turns on chroot in master.cf. See http://www.postfix.org/DEBUG_README.html#no_chroot for turning it off. Not sure, if this depends on his setup, as he compiled it from source. Installs from source don't clobber an existing master.cf file. So unless Postfix was never previously installed on the system, any prior chroot settings will apply.
Re: Postfix original_recipient
On Wed, Oct 01, 2014 at 02:56:48AM -0700, Artyum wrote:
> Thank you for notice Bill. I'll try paste all again as text:
>
> I noticed that in my postfix configuration there is a problem with
> ${original_recipient} which is not set or is overwritten by
> ${recipient}
> My master.cf is below. The problem is that in the autoresponder -r
> ${original_recipient} is equal to ${recipient}.
> Because of that, if user address belongs to a group (aliases) then if
> sender sends message to this group then the autoresponder responds
> from uses address. I want autoresponder only replay if the mail was
> sent directly to the user (not throught alias).
> I'd like to know the ${original_recipient} to check if the mail was
> sent directly to user or to alias group.
IIRC for auto-responses, the correct way to determine whether a message was
sent "directly", is to parse the To: and Cc: headers. The envelope will
often contain the user name in original-recipient even in mail via lists.
--
Viktor.
Re: Postfix original_recipient
Dear Viktor, you're probably right but that would be one of possible
ways to do auto-responses. However in this case the autoresponser is
not the clue. The original_recipient should work as expected,
shouldn't it ? I tried to use no_address_mappings in master.cf and
autoresponder_destination_recipient_limit=1 as was written in postfix
documentation but without success. I can't find other options :(
2014-10-01 14:47 GMT+02:00 Viktor Dukhovni [via Postfix]
:
> On Wed, Oct 01, 2014 at 02:56:48AM -0700, Artyum wrote:
>
>> Thank you for notice Bill. I'll try paste all again as text:
>>
>> I noticed that in my postfix configuration there is a problem with
>> ${original_recipient} which is not set or is overwritten by
>> ${recipient}
>> My master.cf is below. The problem is that in the autoresponder -r
>> ${original_recipient} is equal to ${recipient}.
>> Because of that, if user address belongs to a group (aliases) then if
>> sender sends message to this group then the autoresponder responds
>> from uses address. I want autoresponder only replay if the mail was
>> sent directly to the user (not throught alias).
>> I'd like to know the ${original_recipient} to check if the mail was
>> sent directly to user or to alias group.
>
> IIRC for auto-responses, the correct way to determine whether a message was
> sent "directly", is to parse the To: and Cc: headers. The envelope will
> often contain the user name in original-recipient even in mail via lists.
>
> --
> Viktor.
>
>
>
> If you reply to this email, your message will be added to the discussion
> below:
> http://postfix.1071664.n5.nabble.com/Postfix-original-recipient-tp71161p71295.html
> To unsubscribe from Postfix original_recipient, click here.
> NAML
--
View this message in context:
http://postfix.1071664.n5.nabble.com/Postfix-original-recipient-tp71161p71296.html
Sent from the Postfix Users mailing list archive at Nabble.com.
Re: Accept mail from non-exsistent users
Vijay Rajah: > Hello, > > I need to send mails from one of my servers, with a sender address that > is non-existent (EX: no-re...@mydomain.tld).. > > The mail-hub (postfix 2.11) is rejecting the sender address, with > > Sender address rejected: User unknown in virtual mailbox table) > > I suspect this is because I have "smtpd_reject_unlisted_sender = yes" in > my main.cf Do not send mail with a bogus sender address. At your own risk, you can add the sender address to your virtual aliases, and use smtpd_recipient_restrictions to block return mail. /etc/postfix/main.cf: smtpd_recipient_restrictions = ... reject_unauth_destination check_recipient_access hash:/etc/postfix/recipient_access ... However, there is a risk that receivers may drop your mail when they find out that returned mail is undeliverable. Wietse
Re: Accept mail from non-exsistent users
On 30 Sep 2014, at 23:22 , Vijay Rajah wrote: > I need to send mails from one of my servers, with a sender address that is > non-existent (EX: no-re...@mydomain.tld).. > > The mail-hub (postfix 2.11) is rejecting the sender address, with > > Sender address rejected: User unknown in virtual mailbox table) > > I suspect this is because I have "smtpd_reject_unlisted_sender = yes" in my > main.cf Yes, that would be why. Don’t do that. -- "I've had a perfectly wonderful evening. But this wasn't it." - Groucho Marx
Postfix incompatibility safety net
I am implementing a safety net for incompatible Postfix configuration changes. After a Postfix upgrade, this will allow you to keep running Postfix with the historical default settings, during which time Postfix will log all uses of any old default value that will be affected by an incompatible change. Examples: master.cf: line 72: using legacy default setting chroot=y using legacy default setting append_dot_mydomain=yes to rewrite "foo" to "foo.example.com" using legacy default setting smtputf8_enable=no to accept non-ASCII address "?@example.com" Once you have run Postfix for some time, you know if any main.cf or master.cf setting needs to be updated (set explicitly to old default value) before you can turn off these checks. More on that below. The safety net is controlled with one configuration parameter: name: compatibility_level default: 0 (zero) At this time, no Postfix system has a compatibility_level setting in main.cf, therefore it will be zero. There is also an internal compatibility level that increments by 1 with each incompatible change. With the next Postfix snapshot, this internal level will be 1. The next time you upgrade Postfix, the main.f compatibility level will be zero, which is smaller than the internal level of 1. This turns on a couple things: - Use backwards-compatible default settings so that Postfix keeps working as before. - Log the above messages when Postfix is actually using any of those backwards-compatible default settings. This will show whether your site depends on the old defaults. Finally, you set the parameters explicitly that must stay at their historical value, and configure "compatibility_level = 1" in main.cf. This turns off the checks and warnings. Wietse
PERMIT smtpd_client_restrictions
Hello, as I see/understand it, a check_client_access lookup that returns PERMIT will skip over the rest of smtpd_client_restrictions but WILL still run the checks in the other smtpd_*_restrictions classes, right? I can't find that information in the SMTPD_ACCESS_README or other documents. (I can't find PERMIT in the access.5 manpage either). Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant
Re: PERMIT smtpd_client_restrictions
Am 01.10.2014 um 18:46 schrieb Sebastian Wiesinger: > as I see/understand it, a check_client_access lookup that returns > PERMIT will skip over the rest of smtpd_client_restrictions but WILL > still run the checks in the other smtpd_*_restrictions classes, right? i would say PERMIT is unconditional for allow the message as well as REJECT works exactly the same way hence you normally say DUNNO and not PERMIT in config files > I can't find that information in the SMTPD_ACCESS_README or other > documents. (I can't find PERMIT in the access.5 manpage either) PERMIT is the same as OK
Re: PERMIT smtpd_client_restrictions
Sebastian Wiesinger: > Hello, > > as I see/understand it, a check_client_access lookup that returns > PERMIT will skip over the rest of smtpd_client_restrictions but WILL > still run the checks in the other smtpd_*_restrictions classes, right? > > I can't find that information in the SMTPD_ACCESS_README or other Begin quote from SMTPD_ACCESS_README: "Each restriction list is evaluated from left to right until some restriction produces a result of PERMIT, REJECT or DEFER (try again later). The end of the list is equivalent to a PERMIT result." End quote. > (I can't find PERMIT in the access.5 manpage either). Begin quote from access.5 manpage: OTHER ACTIONS restriction... Apply the named UCE restriction(s) (permit, reject, reject_unauth_destination, and so on). End quote. Wietse > > Regards > > Sebastian > > -- > GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) > 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE > SCYTHE. > -- Terry Pratchett, The Fifth Elephant >
Blacklist failure response
I have been thinking of maybe putting up an experimental anti-spam blocklist server. As far as the client interface, this would operate in the usual way, i.e. via DNS, just as all of the current well-known blacklists do. Due to the (backend) nature of the thing however, it would probably only provide service ... initially at least... from a single machine and a single IP address. I am curious what would happen to Postfix clients if they included references to that in their smtpd_recipient_restrictions, and if the one and only server for the thing went down for a time. What would happen in such a case? Would inbound e-mail start to back up horribly, as Postfix waited for DNS responses that were not forthcoming?
Re: Blacklist failure response
Am 01.10.2014 um 19:04 schrieb Ronald F. Guilmette: > I have been thinking of maybe putting up an experimental > anti-spam blocklist server. As far as the client interface, > this would operate in the usual way, i.e. via DNS, just as > all of the current well-known blacklists do. > > Due to the (backend) nature of the thing however, it would > probably only provide service ... initially at least... > from a single machine and a single IP address. > > I am curious what would happen to Postfix clients if they > included references to that in their smtpd_recipient_restrictions, > and if the one and only server for the thing went down for a > time. > > What would happen in such a case? Would inbound e-mail start to > back up horribly, as Postfix waited for DNS responses that were > not forthcoming? no - no answer is just no answer and mail goes through but why have a single point of failure? just use rbldnsd and rsync it to a second machine - it even reloads changed zones each minute without doing anything, rbldnsd beats out any pther DNS software by it's nature that it was developed for only RBL's and nothing else RBL's in "smtpd_recipient_restrictions" are mostly a bad idea after "Postscreen" was introduced which caches results and can do weighting instead block unconditionally
How transparently move account to a different server?
:-) Two mail servers: `sth1.domain.tld' and `sth2.domain.tld'. Each serves only one (non-virtual) domain. I need to transparently move a few user accounts from `sth1' to `sth2'. That is: for some users the maildir is moved from `sth1' to `sth2' and served (SMTP/IMAP) by `sth2' instead of `sth1' but the change is transparent to other users: they still send email to / receive from `someu...@sth1.domain.tld'. My idea is to simply redirect mail via virtual or forward on `sth1' and re-map addresses of outgoing mail by canonical on `sth2' (plus some extra *checks changes). Will it it work? Is it the recommended way of doing such change? Are there any more proper solutions? Best regards, Marek
Re: PERMIT smtpd_client_restrictions
* Wietse Venema [2014-10-01 19:03]: > Sebastian Wiesinger: > > Hello, > > > > as I see/understand it, a check_client_access lookup that returns > > PERMIT will skip over the rest of smtpd_client_restrictions but WILL > > still run the checks in the other smtpd_*_restrictions classes, right? > > > > I can't find that information in the SMTPD_ACCESS_README or other > > Begin quote from SMTPD_ACCESS_README: > > "Each restriction list is evaluated from left to right until > some restriction produces a result of PERMIT, REJECT or DEFER > (try again later). The end of the list is equivalent to a PERMIT > result." > > End quote. Okay, I can't explain how I overlooked that. Thank you very much for clearing it up for me. > > (I can't find PERMIT in the access.5 manpage either). > > Begin quote from access.5 manpage: > > OTHER ACTIONS >restriction... > Apply the named UCE restriction(s) (permit, reject, > reject_unauth_destination, and so on). > > End quote. And that is owing to me using case sensitivity when searching. :( Thank you and sorry for wasting your time. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant
Re: How transparently move account to a different server?
On 10/1/2014 12:20 PM, Marek Kozlowski wrote: > :-) > > Two mail servers: `sth1.domain.tld' and `sth2.domain.tld'. Each serves > only one (non-virtual) domain. I need to transparently move a few user > accounts from `sth1' to `sth2'. That is: for some users the maildir is > moved from `sth1' to `sth2' and served (SMTP/IMAP) by `sth2' instead of > `sth1' but the change is transparent to other users: they still send > email to / receive from `someu...@sth1.domain.tld'. > > My idea is to simply redirect mail via virtual or forward on `sth1' and > re-map addresses of outgoing mail by canonical on `sth2' (plus some > extra *checks changes). Will it it work? Is it the recommended way of > doing such change? Are there any more proper solutions? > > Best regards, > Marek > Yes, that's a common way of moving accounts between servers. -- Noel Jones
Re: Splitting email.
On 30.09.14, 16:26, Wietse Venema wrote: > giacomo: > > Hello at all, > > I would like to split email from an external mail server (from my ISP) to > > an internal mail server. The ISP receive all mail of the domain in one > > mail address (the server use zimbra with postfix). > > Does this mean that us...@example.com, us...@example.com, etc., are > delivered to the same ISP mailbox, and you want to deliver it to > separate mailboxes on your server? (Replace "example.com" with your > real domain name). Not exactly. The ISP mailbox catch all users of real domain name in a unique mail box (example chatch...@realdomain.com). I want to deliver it on a internal server to separate mailboxes. Is possible this action? > > > I would like to split this email on the relative folder of the > > target user of domain. The internal mail server use postfix. The > > server work fine with virtual user sending e receiving mail > > internally. It's possible this operation? Is there any program > > or procedure to use with postfix to do this? > > You "should" be able to do this with a fetchmail-like program that > looks at the Postfix X-Original-To address header. > > DO NOT USE the To: address header for this purpose. Doing so will > result in delivery loops with mailing list articles. For example, > this reply message does not have your address in the To: header; > and you would be sending it back to postfix-users@postfix.org. > That would cause you to lose your mailing list membership. > > Wietse Thanks -- Luciano -- Le informazioni contenute nella presente e-mail e nei documenti/files eventualmente allegati sono confidenziali. Essi sono riservati esclusivamente al destinatario della stessa. La loro eventuale comunicazione, diffusione o, comunque, rivelazione a terzi, nonche' la copiatura e/o conservazione e' vietata. Se avete ricevuto questa e-mail per errore, Vi preghiamo cortesemente di informare immediatamente il mittente della stessa e di distruggerla o, comunque, cancellarla dal Vostro sistema. This e-mail contains confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and destroy this e-mail. Any unauthorised communication, diffusion, disclosure and copy of the material in this e-mail is strictly forbidden. --
Re: Splitting email.
giacomo: > On 30.09.14, 16:26, Wietse Venema wrote: > > giacomo: > > > Hello at all, > > > I would like to split email from an external mail server (from my ISP) to > > > an internal mail server. The ISP receive all mail of the domain in one > > > mail address (the server use zimbra with postfix). > > > > Does this mean that us...@example.com, us...@example.com, etc., are > > delivered to the same ISP mailbox, and you want to deliver it to > > separate mailboxes on your server? (Replace "example.com" with your > > real domain name). > > Not exactly. The ISP mailbox catch all users of real domain name in > a unique mail box (example chatch...@realdomain.com). > I want to deliver it on a internal server to separate mailboxes. > Is possible this action? I see no difference with my description above. Multiple recipients are delivered to the same ISP mailbox, and you want to deliver that email elsewhere to separate mailboxes. I suggest that you look at my solution below. Wietse > > > > > I would like to split this email on the relative folder of the > > > target user of domain. The internal mail server use postfix. The > > > server work fine with virtual user sending e receiving mail > > > internally. It's possible this operation? Is there any program > > > or procedure to use with postfix to do this? > > > > You "should" be able to do this with a fetchmail-like program that > > looks at the Postfix X-Original-To address header. > > > > DO NOT USE the To: address header for this purpose. Doing so will > > result in delivery loops with mailing list articles. For example, > > this reply message does not have your address in the To: header; > > and you would be sending it back to postfix-users@postfix.org. > > That would cause you to lose your mailing list membership. > > > > Wietse > > Thanks > > -- > Luciano > -- > Le informazioni contenute nella presente e-mail e nei documenti/files > eventualmente allegati sono confidenziali. Essi sono riservati > esclusivamente al destinatario della stessa. La loro eventuale > comunicazione, diffusione o, comunque, rivelazione a terzi, nonche' la > copiatura e/o conservazione e' vietata. Se avete ricevuto questa e-mail per > errore, Vi preghiamo cortesemente di informare immediatamente il mittente > della stessa e di distruggerla o, comunque, cancellarla dal Vostro sistema. > > This e-mail contains confidential and/or privileged information. If you are > not the intended recipient (or have received this e-mail in error), please > notify the sender immediately and destroy this e-mail. Any unauthorised > communication, diffusion, disclosure and copy of the material in this > e-mail is strictly forbidden. > -- >
Re: Blacklist failure response
In message <542c35a7.3050...@rhsoft.net>, "li...@rhsoft.net" wrote: >Am 01.10.2014 um 19:04 schrieb Ronald F. Guilmette: >> What would happen in such a case? Would inbound e-mail start to >> back up horribly, as Postfix waited for DNS responses that were >> not forthcoming? > >no - no answer is just no answer and mail goes through Yeabut, how sloly? If each inbound e-mail is gettung jammed up for, say, 1.25 minutes, waiting for DNS responses that will never arrive, this could cause a problem for some clients. >but why have a single point of failure? just use rbldnsd >and rsync it to a second machine It's a long story, but rsync simply would not be possible.
Re: Blacklist failure response
Ronald F. Guilmette: > > In message <542c35a7.3050...@rhsoft.net>, > "li...@rhsoft.net" wrote: > > >Am 01.10.2014 um 19:04 schrieb Ronald F. Guilmette: > >> What would happen in such a case? Would inbound e-mail start to > >> back up horribly, as Postfix waited for DNS responses that were > >> not forthcoming? > > > >no - no answer is just no answer and mail goes through > > Yeabut, how sloly? See "man 5 resolver" for timeouts, retry counts, etc. Wietse
Re: Blacklist failure response
Am 01.10.2014 um 21:40 schrieb Ronald F. Guilmette: > In message <542c35a7.3050...@rhsoft.net>, > "li...@rhsoft.net" wrote: > >> Am 01.10.2014 um 19:04 schrieb Ronald F. Guilmette: >>> What would happen in such a case? Would inbound e-mail start to >>> back up horribly, as Postfix waited for DNS responses that were >>> not forthcoming? >> >> no - no answer is just no answer and mail goes through > > Yeabut, how sloly? no idea about postfix without postscreen, i guess also 10 seconds postscreen has 10 seconds timeout for a response and in the next release it is configureable also keep in mind postscreen does all rbl lookups in parallel and finally summarizes the scores postscreen_dnsbl_timeout (default: 10s) The time limit for DNSBL or DNSWL lookups. This is separate from the timeouts in the dnsblog(8) daemon which are defined by system resolver(3) routines. This feature is available in Postfix 2.12.
Re: Blacklist failure response
In message <3j7sdd1mnszb...@spike.porcupine.org>, wie...@porcupine.org (Wietse Venema) wrote: >Ronald F. Guilmette: >> >> In message <542c35a7.3050...@rhsoft.net>, >> "li...@rhsoft.net" wrote: >> >> >Am 01.10.2014 um 19:04 schrieb Ronald F. Guilmette: >> >> What would happen in such a case? Would inbound e-mail start to >> >> back up horribly, as Postfix waited for DNS responses that were >> >> not forthcoming? >> > >> >no - no answer is just no answer and mail goes through >> >> Yeabut, how sloly? > >See "man 5 resolver" for timeouts, retry counts, etc. Thank you. I am aware of the general retry scheme. Nominally, I believe that there is one try and three retries, starting at a five second delay and doubling that for each successive retry. So, 5+10+20+40 = 1.25 minutes, in case the server you are querying is down. No? But clients of a typical resolver library (e.g. Postfix) may optionally request either more or fewer retries. No? So I was asking what Postfix does. Also, I was sort-of indirectly asking whether or not Postfix has any in-built mechanism that might automagically spot malfunctioning blacklist servers and disable their further use, you know, in order to prevent inbound stuff from getting all backed up.
Re: Blacklist failure response
Postfix doesn't have any type of automatic detection of any malfunctioning blacklists, it may be configurable on how long to wait for a response, I'm not sure on that, but no dynamic changing of what is being used, if you think that one though, postfix shouldn't do anything like that. Would tempt people to DOS attack the blacklist to bypass it. As for the exponential deferral queue options, see: queue_run_delay maximal_backoff_time minimal_backoff_time bounce_queue_lifetime maximal_queue_lifetime On Wed, Oct 1, 2014 at 4:42 PM, Ronald F. Guilmette wrote: > > In message <3j7sdd1mnszb...@spike.porcupine.org>, > wie...@porcupine.org (Wietse Venema) wrote: > >>Ronald F. Guilmette: >>> >>> In message <542c35a7.3050...@rhsoft.net>, >>> "li...@rhsoft.net" wrote: >>> >>> >Am 01.10.2014 um 19:04 schrieb Ronald F. Guilmette: >>> >> What would happen in such a case? Would inbound e-mail start to >>> >> back up horribly, as Postfix waited for DNS responses that were >>> >> not forthcoming? >>> > >>> >no - no answer is just no answer and mail goes through >>> >>> Yeabut, how sloly? >> >>See "man 5 resolver" for timeouts, retry counts, etc. > > Thank you. I am aware of the general retry scheme. > > Nominally, I believe that there is one try and three retries, > starting at a five second delay and doubling that for each > successive retry. > > So, 5+10+20+40 = 1.25 minutes, in case the server you are querying > is down. No? > > But clients of a typical resolver library (e.g. Postfix) may > optionally request either more or fewer retries. No? > > So I was asking what Postfix does. > > Also, I was sort-of indirectly asking whether or not Postfix > has any in-built mechanism that might automagically spot > malfunctioning blacklist servers and disable their further > use, you know, in order to prevent inbound stuff from getting > all backed up.
Re: Blacklist failure response
Wietse:
> >See "man 5 resolver" for timeouts, retry counts, etc.
>
> But clients of a typical resolver library (e.g. Postfix) may
> optionally request either more or fewer retries. No?
>
> So I was asking what Postfix does.
There is no supported API for retry/timeout settings as far as I
can tell. Whacking bits in the __res structure does not count.
Maybe it can be set with environment variables, but that
may require support to do:
import_environment = PATH=xxx, {RES_OPTIONS = stuff with spaces}, ...
I can add a few lines of code to support { ... } if that helps.
> Also, I was sort-of indirectly asking whether or not Postfix
> has any in-built mechanism that might automagically spot
> malfunctioning blacklist servers and disable their further
> use, you know, in order to prevent inbound stuff from getting
> all backed up.
Postscreen has its own time limit. That possible because the
lookup is done in a different process.
Postfix does not maintain state about good/bad DNSXL servers. Don't
use bad DNSXL servers, or use postscreen's time limits.
Wietse
Re: Blacklist failure response
In message Paul C wrote: >Postfix doesn't have any type of automatic detection of any >malfunctioning blacklists, it may be configurable on how long to wait >for a response, I'm not sure on that, but no dynamic changing of what >is being used, if you think that one though, postfix shouldn't do >anything like that. Would tempt people to DOS attack the blacklist to >bypass it. Right. Like the spammers aren't already out there doing exactly that, day in and day out anyway.[1] =-=-=-=-=-=-=-=-=- [1] Speaking as one who had his own blacklist DDoS'd off the net entirely, way back in 2003, before it was even fashionable.
Re: Blacklist failure response
In message <3j7vdm3rglzb...@spike.porcupine.org>, you wrote:
>Wietse:
>There is no supported API for {DNS} retry/timeout settings as far as I
>can tell. Whacking bits in the __res structure does not count.
>
>Maybe it can be set with environment variables, but that
>may require support to do:
>
>import_environment = PATH=xxx, {RES_OPTIONS = stuff with spaces}, ...
>
>I can add a few lines of code to support { ... } if that helps.
Thank you for the offer, but please don't do that just on my account.
Mostly, I just wanted to know if Postfix was _already_ putting anything
special of its own into the __res structure.. like perhaps a Postfix-
specific value for retries.
But if not, then my question is answered... DNS resolution of anything
in Postfix is done according to whatever the defaults are in the local
resolver library (which are generally both well known and well documented).
>Postfix does not maintain state about good/bad DNSXL servers. Don't
>use bad DNSXL servers...
A good piece of advice if ever there was one.
Regards,
rfg
Re: Blacklist failure response
Ronald F. Guilmette:
>
> In message <3j7vdm3rglzb...@spike.porcupine.org>, you wrote:
>
Wietse:
>There is no supported API for {DNS} retry/timeout settings as far as I
>can tell. Whacking bits in the __res structure does not count.
Ronald F. Guilmette:
> Mostly, I just wanted to know if Postfix was _already_ putting anything
> special of its own into the __res structure.. like perhaps a Postfix-
> specific value for retries.
Postfix does set/unset documented bits, as documented:
http://www.postfix.org/postconf.5.html#smtp_dns_resolver_options
But retry/timeout are not among the documented bits, so they
are not whacked.
Wietse
