Address verification probes & smtp_fallback_relay
Currently I'm using smtp_fallback_relay but I don't want Address verification probes to take that particular path. How can I disable smtp_fallback_relay for the address verification probes? -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: Address verification probes & smtp_fallback_relay
On Mon, Sep 29, 2014 at 12:00:04PM +0200, Ralf Hildebrandt wrote: > Currently I'm using smtp_fallback_relay but I don't want Address > verification probes to take that particular path. > > How can I disable smtp_fallback_relay for the address verification > probes? Specify a different verification transport (clones of "smtp" and/or "relay") and override smtp_fallback_relay in master.cf. -- Viktor.
Re: Address verification probes & smtp_fallback_relay
* Viktor Dukhovni : > On Mon, Sep 29, 2014 at 12:00:04PM +0200, Ralf Hildebrandt wrote: > > > Currently I'm using smtp_fallback_relay but I don't want Address > > verification probes to take that particular path. > > > > How can I disable smtp_fallback_relay for the address verification > > probes? > > Specify a different verification transport (clones of "smtp" and/or > "relay") and override smtp_fallback_relay in master.cf. Thought so, thanks. I was just wondering why every parameter had a address_verify_* equivalent but this one. -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: Address verification probes & smtp_fallback_relay
Ralf Hildebrandt: > * Viktor Dukhovni : > > On Mon, Sep 29, 2014 at 12:00:04PM +0200, Ralf Hildebrandt wrote: > > > > > Currently I'm using smtp_fallback_relay but I don't want Address > > > verification probes to take that particular path. > > > > > > How can I disable smtp_fallback_relay for the address verification > > > probes? > > > > Specify a different verification transport (clones of "smtp" and/or > > "relay") and override smtp_fallback_relay in master.cf. > > Thought so, thanks. I was just wondering why every parameter had a > address_verify_* equivalent but this one. None of the SMTP client parameters (*) has an address_verify_* equivalent. The address_verify_* equivalents exist for parameters that determine the selection of mssage delivery transports and relayhosts. Wietse
Re: Address verification probes & smtp_fallback_relay
On 9/29/2014 6:18 AM, Wietse Venema wrote: > Ralf Hildebrandt: >> * Viktor Dukhovni : >>> On Mon, Sep 29, 2014 at 12:00:04PM +0200, Ralf Hildebrandt wrote: >>> Currently I'm using smtp_fallback_relay but I don't want Address verification probes to take that particular path. How can I disable smtp_fallback_relay for the address verification probes? >>> >>> Specify a different verification transport (clones of "smtp" and/or >>> "relay") and override smtp_fallback_relay in master.cf. >> >> Thought so, thanks. I was just wondering why every parameter had a >> address_verify_* equivalent but this one. > > None of the SMTP client parameters (*) has an address_verify_* equivalent. > > The address_verify_* equivalents exist for parameters that determine > the selection of mssage delivery transports and relayhosts. > > Wietse > Is smtp_fallback_relay even used with a verification probe? I would expect the probe to fail before it tries the fallback. -- Noel Jones
Re: Add --version option to postfix
On 9/28/2014 3:01 PM, LuKreme wrote: > Yes, it’s (postfinger) a separate package. Yeah, and unavailable in gentoo repo... :(
Re: Address verification probes & smtp_fallback_relay
Am 29.09.2014 um 13:45 schrieb Noel Jones: > On 9/29/2014 6:18 AM, Wietse Venema wrote: >> Ralf Hildebrandt: >>> * Viktor Dukhovni : On Mon, Sep 29, 2014 at 12:00:04PM +0200, Ralf Hildebrandt wrote: > Currently I'm using smtp_fallback_relay but I don't want Address > verification probes to take that particular path. > > How can I disable smtp_fallback_relay for the address verification > probes? Specify a different verification transport (clones of "smtp" and/or "relay") and override smtp_fallback_relay in master.cf. >>> >>> Thought so, thanks. I was just wondering why every parameter had a >>> address_verify_* equivalent but this one. >> >> None of the SMTP client parameters (*) has an address_verify_* equivalent. >> >> The address_verify_* equivalents exist for parameters that determine >> the selection of mssage delivery transports and relayhosts. >> >> Wietse >> > > Is smtp_fallback_relay even used with a verification probe? I would > expect the probe to fail before it tries the fallback. hm... http://www.postfix.org/ADDRESS_VERIFICATION_README.html By default, Postfix sends address verification probe messages via the same route as regular mail, > > > -- Noel Jones > Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: Add --version option to postfix
On Mon, Sep 29, 2014 at 08:13:38AM -0400, Charles Marcus wrote: > On 9/28/2014 3:01 PM, LuKreme wrote: > > Yes, it’s (postfinger) a separate package. > > Yeah, and unavailable in gentoo repo... :( It is a shell script. You can just download and run it on your system. -- Eray
Re: Address verification probes & smtp_fallback_relay
On 9/29/2014 7:40 AM, Robert Schetterer wrote: > Am 29.09.2014 um 13:45 schrieb Noel Jones: >> On 9/29/2014 6:18 AM, Wietse Venema wrote: >>> Ralf Hildebrandt: * Viktor Dukhovni : > On Mon, Sep 29, 2014 at 12:00:04PM +0200, Ralf Hildebrandt wrote: > >> Currently I'm using smtp_fallback_relay but I don't want Address >> verification probes to take that particular path. >> >> How can I disable smtp_fallback_relay for the address verification >> probes? > > Specify a different verification transport (clones of "smtp" and/or > "relay") and override smtp_fallback_relay in master.cf. Thought so, thanks. I was just wondering why every parameter had a address_verify_* equivalent but this one. >>> >>> None of the SMTP client parameters (*) has an address_verify_* equivalent. >>> >>> The address_verify_* equivalents exist for parameters that determine >>> the selection of mssage delivery transports and relayhosts. >>> >>> Wietse >>> >> >> Is smtp_fallback_relay even used with a verification probe? I would >> expect the probe to fail before it tries the fallback. > > hm... > > http://www.postfix.org/ADDRESS_VERIFICATION_README.html > > By default, Postfix sends address verification probe messages via the > same route as regular mail, Yes, but it also says: Probe messages are like normal mail, except that they are never delivered, deferred or bounced - and - Postfix assumes that an address is undeliverable when the nearest MTA for the address rejects the probe, regardless of the reason for rejection It doesn't seem generally useful to probe a fallback relay, so I'm looking for clarification. -- Noel Jones
Re: Address verification probes & smtp_fallback_relay
> Yes, but it also says: > > Probe messages are like normal mail, except that they are never > delivered, deferred or bounced Wait what? > - and - > Postfix assumes that an address is undeliverable when the nearest > MTA for the address rejects the probe, regardless of the reason for > rejection > > > It doesn't seem generally useful to probe a fallback relay, so I'm > looking for clarification. Sound like it would never make it to the fallback_relay, since a TEMPFAIL on the first delivery attempt would mean "deferral", which is explicitly excluded?! -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: Address verification probes & smtp_fallback_relay
Am 29.09.2014 um 15:53 schrieb Noel Jones: > On 9/29/2014 7:40 AM, Robert Schetterer wrote: >> Am 29.09.2014 um 13:45 schrieb Noel Jones: >>> On 9/29/2014 6:18 AM, Wietse Venema wrote: Ralf Hildebrandt: > * Viktor Dukhovni : >> On Mon, Sep 29, 2014 at 12:00:04PM +0200, Ralf Hildebrandt wrote: >> >>> Currently I'm using smtp_fallback_relay but I don't want Address >>> verification probes to take that particular path. >>> >>> How can I disable smtp_fallback_relay for the address verification >>> probes? >> >> Specify a different verification transport (clones of "smtp" and/or >> "relay") and override smtp_fallback_relay in master.cf. > > Thought so, thanks. I was just wondering why every parameter had a > address_verify_* equivalent but this one. None of the SMTP client parameters (*) has an address_verify_* equivalent. The address_verify_* equivalents exist for parameters that determine the selection of mssage delivery transports and relayhosts. Wietse >>> >>> Is smtp_fallback_relay even used with a verification probe? I would >>> expect the probe to fail before it tries the fallback. >> >> hm... >> >> http://www.postfix.org/ADDRESS_VERIFICATION_README.html >> >> By default, Postfix sends address verification probe messages via the >> same route as regular mail, > > Yes, but it also says: > > Probe messages are like normal mail, except that they are never > delivered, deferred or bounced > - and - > Postfix assumes that an address is undeliverable when the nearest > MTA for the address rejects the probe, regardless of the reason for > rejection > > > It doesn't seem generally useful to probe a fallback relay, so I'm > looking for clarification. Guess its a defintion question, fallback relay = same route as regular mail that, might be wanted eleswhere, but youre right its a litte bit "unclear" in the docs , perhaps of historical reasons, dont know if it might be usefull to have some exeption parameter for it, perhaps not ,cause it might configured with transport where such parameter exists, so fixing some "unclearness" here may introduce some unclearness elsewhere I guess its better "gurus" may answer this question in more detail. > > > > -- Noel Jones > Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: Address verification probes & smtp_fallback_relay
Robert Schetterer: > Am 29.09.2014 um 13:45 schrieb Noel Jones: > > Is smtp_fallback_relay even used with a verification probe? I would > > expect the probe to fail before it tries the fallback. > > hm... > > http://www.postfix.org/ADDRESS_VERIFICATION_README.html > > By default, Postfix sends address verification probe messages via the > same route as regular mail, Indeed. For maximal realism, probe delivery is intentionally the same as real mail delivery. The difference is that probes are never delivered (SMTP interruptus), and that failed probes are never returned to the mail queue. There is no reason to keep failed probes in the mail queue (and it would be unwise). Wietse
Re: Address verification probes & smtp_fallback_relay
Am 29.09.2014 um 16:04 schrieb Ralf Hildebrandt: >> Yes, but it also says: >> >> Probe messages are like normal mail, except that they are never >> delivered, deferred or bounced > > Wait what? > >> - and - >> Postfix assumes that an address is undeliverable when the nearest >> MTA for the address rejects the probe, regardless of the reason for >> rejection >> >> >> It doesn't seem generally useful to probe a fallback relay, so I'm >> looking for clarification. > > Sound like it would never make it to the fallback_relay, since a > TEMPFAIL on the first delivery attempt would mean "deferral", which is > explicitly excluded?! > sounds plausible Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: Add --version option to postfix
On 9/29/2014 9:02 AM, Eray Aslan wrote: > On Mon, Sep 29, 2014 at 08:13:38AM -0400, Charles Marcus wrote: >> On 9/28/2014 3:01 PM, LuKreme wrote: >>> Yes, it’s (postfinger) a separate package. >> Yeah, and unavailable in gentoo repo... :( > It is a shell script. You can just download and run it on your system. Which is all well and good, but totally beside the point. The fact is it is not a part of the standard postfix sources/install (at least in 2.10.x), and I was talking about adding new functionality that could/would be backported to all prior (but only supported versions of course), to make troubleshooting *all* of the currently supported versions of postfix easier... And this would of course also entail changing/updating the troubleshooting tips in the list welcome message (and any website support pages)... But again... it is just an opinion/suggestion from a lowly user...
Re: Address verification probes & smtp_fallback_relay
Noel Jones: > > By default, Postfix sends address verification probe messages via the > > same route as regular mail, > > Yes, but it also says: > > Probe messages are like normal mail, except that they are never > delivered, deferred or bounced > - and - > Postfix assumes that an address is undeliverable when the nearest > MTA for the address rejects the probe, regardless of the reason for > rejection This text needs to be updated. The old Postfix SMTP client behaved as if smtp_mx_session_limit=1, that is, there was only one SMTP session per delivery request (it tried to connect to each MX until one responded, and then it would not try any of the other MXes). Why is it better to skip the fallback relay and reply with "4XX"? Wietse
Re: Address verification probes & smtp_fallback_relay
On 9/29/2014 9:06 AM, Wietse Venema wrote: > Robert Schetterer: >> Am 29.09.2014 um 13:45 schrieb Noel Jones: >>> Is smtp_fallback_relay even used with a verification probe? I would >>> expect the probe to fail before it tries the fallback. >> >> hm... >> >> http://www.postfix.org/ADDRESS_VERIFICATION_README.html >> >> By default, Postfix sends address verification probe messages via the >> same route as regular mail, > > Indeed. For maximal realism, probe delivery is intentionally the > same as real mail delivery. > > The difference is that probes are never delivered (SMTP interruptus), > and that failed probes are never returned to the mail queue. There > is no reason to keep failed probes in the mail queue (and it would > be unwise). > > Wietse > Sorry if I'm just too dense this morning, but this still isn't clear to me. Do probes use the smtp_fallback_relay or do they fail at the first TEMPFAIL that would cause the fallback to be used? My (quite possibly flawed) interpretation of the docs makes me think the probe will fail and not use the fallback. And seems to me using the fallback would not be generally useful. -- Noel Jones
Re: Address verification probes & smtp_fallback_relay
* Wietse Venema : > Robert Schetterer: > > Am 29.09.2014 um 13:45 schrieb Noel Jones: > > > Is smtp_fallback_relay even used with a verification probe? I would > > > expect the probe to fail before it tries the fallback. > > > > hm... > > > > http://www.postfix.org/ADDRESS_VERIFICATION_README.html > > > > By default, Postfix sends address verification probe messages via the > > same route as regular mail, > > Indeed. For maximal realism, probe delivery is intentionally the > same as real mail delivery. And alas, we want that :) > The difference is that probes are never delivered (SMTP interruptus), > and that failed probes are never returned to the mail queue. There > is no reason to keep failed probes in the mail queue (and it would > be unwise). You mean they would clutter the queue? -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: Address verification probes & smtp_fallback_relay
Ralf Hildebrandt: > > The difference is that probes are never delivered (SMTP interruptus), > > and that failed probes are never returned to the mail queue. There > > is no reason to keep failed probes in the mail queue (and it would > > be unwise). > > You mean they would clutter the queue? Massively. There is no point in retrying the probe because the sender may never come back (address verification is a form of greylisting). Wietse
postscreen log scanner script updated
I cleaned up my pslogscan.sh script a bit. Aside from some general cleanup, I did some re-formatting of the output to make it look a bit cleaner, and allow for some flexibility in display widths. I also went from linear processing of multiple items to loop processing of those items. You can download the script from here: http://archive.mgm51.com/sources/pslogscan.html Sample output, showing Postscreen rejecting about 18% of the incoming mail. Note the postscreen portion of this maillog is about 340MB in size, about 3 million postscreen log records. The results of the time command are shown after the sample output. Scanning /var/log/maillog Screening status log records: CONNECT: 705024 PASS NEW: 31104 PASS OLD: 228096 WHITELISTED: 316224 BLACKLISTED: 0 rejected: 129600 (18%) Protocol error log records: HANGUP: 57024 PREGREET: 10368 BARE NEWLINE: 0 COMMAND TIME LIMIT: 0 COMMAND PIPELINING: 0 DNS black list log records: zen.spamhaus.org: 160704 bl.spamcop.net: 51840 b.barracudacentral.org: 98496 DNSBL NOQUEUE log records: DNSBL rank 1: 0 DNSBL rank 2: 0 DNSBL rank 3: 10368 DNSBL rank 4: 0 DNSBL rank 5: 10368 DNSBL rank 6: 51840 DNSBL rank 7: 0 DNSBL rank 8: 46656 DNSBL rank 9: 0 DNSBL rank 10+: 0 DNSBL NOQUEUE by domain: example.com: 36288 example.net: 15552 example.org: 0 Time command results for the above sample: real0m8.112s user0m3.350s sys 0m3.703s
Re: Address verification probes & smtp_fallback_relay
On 9/29/2014 9:28 AM, Wietse Venema wrote: > Noel Jones: >>> By default, Postfix sends address verification probe messages via the >>> same route as regular mail, >> >> Yes, but it also says: >> >> Probe messages are like normal mail, except that they are never >> delivered, deferred or bounced >> - and - >> Postfix assumes that an address is undeliverable when the nearest >> MTA for the address rejects the probe, regardless of the reason for >> rejection > > This text needs to be updated. The old Postfix SMTP client behaved > as if smtp_mx_session_limit=1, that is, there was only one SMTP > session per delivery request (it tried to connect to each MX until > one responded, and then it would not try any of the other MXes). > > Why is it better to skip the fallback relay and reply with "4XX"? > > Wietse > My impression is a typical smtp_fallback_relay would not validate recipients, therefore unable to give a meaningful answer. Conversely, if the fallback is an alternate path to internal storage it may have all the answers. Postfix currently has a method to turn off smtp_fallback_relay for verification probes (by using a separate transport) but it's not clear this is necessary. If the fallback is *not* used by design, there wouldn't be any way to turn it on in case it was desired. I know we can't document everything postfix *doesn't* do, but I think this needs clarification. -- Noel Jones
Long parameter settings in master.cf (was: Per-policy settings)
Wietse Venema:
> This is now implemented for policy protocol clients. The basic idea
> is the same: instead of inet:host:port or unix:path/name, you specify
> { inet:host:port, name=value, ... }. There is a provision to specify
> values that contain spaces, which may be needed with the default_action
> attribute.
>
> Source code release: postfix-2.12-20140928.
>
> Documentation:
> http:/www.porcupine.org/postfix-mirror/MILTER_README.html#per-milter
> http:/www.porcupine.org/postfix-mirror/SMTPD_POLICY_README.html#advanced
I forgot to mention (and document) that master.cf now supports
whitespace in daemon command lines, for example:
smtpd -o { parameter = value with whitespace } ...
Also, the { ... } form is now available for non-option command-line
arguments in master.cf, for example:
pipe ... argv=command { argument with whitespace } ...
This took only a two-line change in the master(8) source code,
because the support for "{ text }" was already implemented for the
other features.
I can only wish that I had the cycles to design these improvements
a few years earlier.
Wietse
Re: Address verification probes & smtp_fallback_relay
On September 29, 2014 12:00:04 PM Ralf Hildebrandt wrote: Currently I'm using smtp_fallback_relay but I don't want Address verification probes to take that particular path. How can I disable smtp_fallback_relay for the address verification probes? Add it to verify service in master.cf as a ovrrride to not use failback, see example for relay in master.cf
Re: postscreen log scanner script updated
On 9/29/2014 at 10:44 AM Mike. wrote:
|I cleaned up my pslogscan.sh script a bit. Aside from some general
|cleanup, I did some re-formatting of the output to make it look a
bit
|cleaner, and allow for some flexibility in display widths. I also
|went from linear processing of multiple items to loop processing of
|those items.
[snip]
=
Someone found a typo that the FreeBSD shell seems to be OK with, but
Debian (wheezy) dislikes.
Version 1.8 has been uploaded to
http://archive.mgm51.com/sources/pslogscan.html
If you don't want to download, here's the description:
I fixed line 144 with :
if [ ${DeepProtocolTestsEnabled} = "no" ] ; then
instead of
if [ ${DeepProtocolTestsEnabled} == "no" ] ; then
(I guess I've been programming in c too much of late. :) )
Thanks to AE for the bug report.
How to disable Unix users?
:-) Maybe a stupid question... I'd like to allow incoming (or local) mail only addressed to aliases specified in `vitual_alias_maps' and `alias_map' but reject recipient addresses using user names. For example I have a user `smithj' which has an alias (or virtual) `john.smith'(@...). I'd like to accept mail to `john.smith@...' but reject mail to `smithj@...'. Maybe I'm blind but I can't find the option / way how to do it... Best regrads, Marek
Re: How to disable Unix users?
Marek Kozlowski: > Maybe a stupid question... > I'd like to allow incoming (or local) mail only addressed to aliases > specified in `vitual_alias_maps' and `alias_map' but reject recipient > addresses using user names. /etc/postfix/main.cf: local_recipient_maps = This blocks direct mail over SMTP to UNIX accounts. wietse > For example I have a user `smithj' which has an alias (or virtual) > `john.smith'(@...). I'd like to accept mail to `john.smith@...' but > reject mail to `smithj@...'. Maybe I'm blind but I can't find the option > / way how to do it... > Best regrads, > Marek >
Re: How to disable Unix users?
On 09/29/2014 08:30 PM, Wietse Venema wrote: > Marek Kozlowski: >> Maybe a stupid question... >> I'd like to allow incoming (or local) mail only addressed to aliases >> specified in `vitual_alias_maps' and `alias_map' but reject recipient >> addresses using user names. > > /etc/postfix/main.cf: > local_recipient_maps = Do you mean: local_recipient_maps = $vitual_alias_maps, $alias_maps ? Best regards, /m
Re: How to disable Unix users?
Marek Kozlowski: [ Charset ISO-8859-2 converted... ] > On 09/29/2014 08:30 PM, Wietse Venema wrote: > > Marek Kozlowski: > >> Maybe a stupid question... > >> I'd like to allow incoming (or local) mail only addressed to aliases > >> specified in `vitual_alias_maps' and `alias_map' but reject recipient > >> addresses using user names. > > > > /etc/postfix/main.cf: > > local_recipient_maps = > > > Do you mean: > > local_recipient_maps = $vitual_alias_maps, $alias_maps No. I mean what I wrote. Wietse
Re: How to disable Unix users?
Wietse Venema: > Marek Kozlowski: > [ Charset ISO-8859-2 converted... ] > > On 09/29/2014 08:30 PM, Wietse Venema wrote: > > > Marek Kozlowski: > > >> Maybe a stupid question... > > >> I'd like to allow incoming (or local) mail only addressed to aliases > > >> specified in `vitual_alias_maps' and `alias_map' but reject recipient > > >> addresses using user names. > > > > > > /etc/postfix/main.cf: > > > local_recipient_maps = > > > > > > Do you mean: > > > > local_recipient_maps = $vitual_alias_maps, $alias_maps > > No. I mean what I wrote. However this disables the "unknown recipient" check, so use instead a table that is empty. /etc/postfix/main.cf: local_recipient_maps = hash:/etc/postfix/empty /etc/postfix/empty # nothing here That is, a table with no content. Wietse
Re: How to disable Unix users?
On 09/29/2014 08:39 PM, Wietse Venema wrote: > Marek Kozlowski: > [ Charset ISO-8859-2 converted... ] >> On 09/29/2014 08:30 PM, Wietse Venema wrote: >>> Marek Kozlowski: Maybe a stupid question... I'd like to allow incoming (or local) mail only addressed to aliases specified in `vitual_alias_maps' and `alias_map' but reject recipient addresses using user names. >>> >>> /etc/postfix/main.cf: >>> local_recipient_maps = >> >> >> Do you mean: >> >> local_recipient_maps = $vitual_alias_maps, $alias_maps > > No. I mean what I wrote. I don't understand :-( "Don't do this on systems that receive mail directly from the Internet. With today's worms and viruses, Postfix will become a backscatter source: it accepts mail for non-existent recipients and then tries to return that mail as "undeliverable" to the often forged sender address." http://www.postfix.org/LOCAL_RECIPIENT_README.html /m
Re: How to disable Unix users?
Am 29.09.2014 um 20:43 schrieb Marek Kozlowski: > On 09/29/2014 08:39 PM, Wietse Venema wrote: >> Marek Kozlowski: >> [ Charset ISO-8859-2 converted... ] >>> On 09/29/2014 08:30 PM, Wietse Venema wrote: Marek Kozlowski: > Maybe a stupid question... > I'd like to allow incoming (or local) mail only addressed to aliases > specified in `vitual_alias_maps' and `alias_map' but reject recipient > addresses using user names. /etc/postfix/main.cf: local_recipient_maps = >>> >>> >>> Do you mean: >>> >>> local_recipient_maps = $vitual_alias_maps, $alias_maps >> >> No. I mean what I wrote. > > I don't understand :-( > > "Don't do this on systems that receive mail directly from the Internet. > With today's worms and viruses, Postfix will become a backscatter > source: it accepts mail for non-existent recipients and then tries to > return that mail as "undeliverable" to the often forged sender address." > > http://www.postfix.org/LOCAL_RECIPIENT_README.html just list all your valid addresses in local_recipient_maps and you are done - in fact there is no need for virtual and what not - it just works that way for some hundret domains over 6 years now and you can do the same with files instead of mysql - the inbound MX in fact creats postmaps files from that data append_dot_mydomain = no parent_domain_matches_subdomains = mydestination = mysql:/etc/postfix/mysql-mydestination.cf local_recipient_maps = mysql:/etc/postfix/mysql-recipients.cf transport_maps = mysql:/etc/postfix/mysql-transport.cf cat /etc/postfix/mysql-mydestination.cf user = dbmailro password = * dbname = dbmail hosts= unix:/var/lib/mysql/mysql.sock query= select transport from dbma_mta where mydestination='%s'; cat /etc/postfix/mysql-recipients.cf user = dbmailro password = * dbname = dbmail hosts= unix:/var/lib/mysql/mysql.sock query= select alias from dbma_recipients where alias='%s'; cat /etc/postfix/mysql-transport.cf user = dbmailro password = * dbname = dbmail hosts= unix:/var/lib/mysql/mysql.sock query= select transport from dbma_transports where mydestination='%s' or mydestination='%d' order by transport desc limit 1;
Re: How to disable Unix users?
Wietse Venema: > Wietse Venema: > > Marek Kozlowski: > > [ Charset ISO-8859-2 converted... ] > > > On 09/29/2014 08:30 PM, Wietse Venema wrote: > > > > Marek Kozlowski: > > > >> Maybe a stupid question... > > > >> I'd like to allow incoming (or local) mail only addressed to aliases > > > >> specified in `vitual_alias_maps' and `alias_map' but reject recipient > > > >> addresses using user names. > > > > > > > > /etc/postfix/main.cf: > > > > local_recipient_maps = > > > > > > > > > Do you mean: > > > > > > local_recipient_maps = $vitual_alias_maps, $alias_maps > > > > No. I mean what I wrote. If you want /etc/aliases to keep working: /etc/postfix/main.cf: local_recipient_maps = $alias_maps. Postfix always accepts mail for virtual aliases. Wietse
Re: How to disable Unix users?
On 09/29/2014 08:51 PM, Wietse Venema wrote: > Wietse Venema: >> Wietse Venema: >>> Marek Kozlowski: >>> [ Charset ISO-8859-2 converted... ] On 09/29/2014 08:30 PM, Wietse Venema wrote: > Marek Kozlowski: >> Maybe a stupid question... >> I'd like to allow incoming (or local) mail only addressed to aliases >> specified in `vitual_alias_maps' and `alias_map' but reject recipient >> addresses using user names. > > /etc/postfix/main.cf: > local_recipient_maps = Do you mean: local_recipient_maps = $vitual_alias_maps, $alias_maps >>> >>> No. I mean what I wrote. > > If you want /etc/aliases to keep working: > > /etc/postfix/main.cf: > local_recipient_maps = $alias_maps. > > Postfix always accepts mail for virtual aliases. IMHO disabling aliases is not a good idea. `MAILER-DAEMON' and `postmaster' should be present... Best regards, Marek
Re: localhost.com
Am 28.09.2014 um 08:23 schrieb Ruben Safir: >> >> That will work. Another solution is setting append_dot_mydomain=no, >> so that user@localhost will become u...@localhost.com. >> > > > > > Yes - I am confused by this a little bit. Why would postfix want to add > a dot com to any outgoing email? Because it tries to make e-mail messaging just work for those who choose to abstain from reading documentation or set up their systems in ways that are useful for e-mail.
Re: Thanks: Input requested: append_dot_mydomain default change
Am 24.09.2014 um 16:29 schrieb Wietse Venema:
> The implementation will probably be a compatibility_level parameter
> that is 1 for installations that pre-date this feature, that is 2
> for new installations, and that is incremented by 1 for each
> compatibility break. People who don't care can set this to 99
> and never hear a peep about compatibility breaks.
First of all, thanks for 15+ years of smooth Postfix rides.
Whenever I needed to give an example that smooth upgrades and
compatibility are possible, Postfix is the reference project.
A few thoughts on the deployment, more of practical matter:
1 - Is changing the default - even if only applied to fresh installs - a
case for calling the first Postfix release to flip the 3.0 so people
will lift their heads to see if they're walking into pitfalls?
2 - sorry, this thought has two preceding ones that will make it look
like legalese:
2a - from talking about anonymous "change requests" in my daytime
(non systems admin) job where most people need to ask back "what is
CR088A all about?";
2b - still trusting you to get us a proper document that nicely lists
all the incompatible changes that caused this integer to be bumped:
Do you think an integer serves the purpose? What happens if, despite
all good intention, due diligence and care, something that breaks
compatibility needs to be back ported? Would this want to be a set of
mnemonic flags or semantic version numbers instead?
3 - is there a useful way to log warnings about unqualified domains when
they are observed and qualified in mid-flight, so that people have
something to watch for before flipping the switch? It seems there
already is, check_{sender,recipient}_access + WARN action + regexp map -
so canonical information how to enable this ahead of time already now
might help smooth out the migration even more.
Re: Thanks: Input requested: append_dot_mydomain default change
Matthias Andree:
> 3 - is there a useful way to log warnings about unqualified domains when
> they are observed and qualified in mid-flight, so that people have
> something to watch for before flipping the switch? It seems there
> already is, check_{sender,recipient}_access + WARN action + regexp map -
> so canonical information how to enable this ahead of time already now
> might help smooth out the migration even more.
Such logging might help people to decide that it is safe to flip
the switch and adopt the new default. However the Postfix code that
rewrites addresses has no information about the message delivery
context (queue ID, SMTP client, sender, recipient), and that is not
going to change.
As for bumping the Postfix version to 3.0, that is a decision that
will be separate from append_dot_mydomain. It will be made for
different reasons.
The whole point of the new compatibility stuff is to *avoid*
disruption when people upgrade, whether is is the upcoming stable
release, or some future stable release. We can't bump the major
version every time some default changes.
About back-porting incompatible emergency fixes, that falls outside
the scope of the Postfix compatibility guarantee.
Wietse
Re: Add --version option to postfix
On 09/28/2014 04:07 AM, Wietse Venema wrote: > Would an updated postfinger command help? Would it be asking too much for a simple -v (or -V) flag to be added to postconf, and if possible, the "postfix" binary, and other binaries included with postfix that would output something like the following: This is Postfix version 2.10.0 copyright (blah blah) released on (blah blah) and built with the following configuration flags: -foo -bar, etc. For more information about Postfix please refer to the included documentation or http://www.postfix.org. This being just an example of some useful stuff you'd expect to see in a version command, possibly including other useful info which can be taken in part from the postconf -d variables and presented in one or two easy paragraphs of user-readable text. This would work well for anyone not familiar with Postfix. Peter
