bitdefender

[David Mehler]

Hello,

I'm running a postfix mail server. One of it's components is
antivirus. For that I'm running clamav. I'd like to have a second
scanner as backup. Does anyone have any experience with bitdefender?
If not any other suggestions?

Thanks.
Dave.

Re: gmail servers on blacklists?

[David Mehler]

Hi,

Much thanks. Lost ahbl, and glad to see it go.

Thanks.
Dave.


On 3/17/17, /dev/rob0  wrote:
> On Fri, Mar 17, 2017 at 05:12:07PM -0400, David Mehler wrote:
>> I'm starting to see blocks on my messages to my mail server. For some
>> reason postscreen is not letting any gmail servers send mail, it's
>> blocking them.
>>
>> Has anyone got an idea or have you seen this?
>
> Typically you would SHOW LOGS of the blocking when asking for help,
> but in your case it's pretty obvious.
>
>> Here's my postscreen setup:
>>
>> # postscreen(8) settings
>> ### Before-220 tests
>> postscreen_greet_action = enforce
>> postscreen_blacklist_action = enforce
>> postscreen_dnsbl_action = enforce
>> postscreen_access_list = permit_mynetworks
>> cidr:/usr/local/etc/postfix/postscreen_access.cidr
>> postscreen_dnsbl_reply_map =
>> pcre:/usr/local/etc/postfix/postscreen_dnsbl_reply_map.pcre
>> postscreen_dnsbl_sites = zen.spamhaus.org*3
>>  b.barracudacentral.org*2
>>  bl.spameatingmonkey.net*2
>>  dnsbl.ahbl.org*2
>
> Closed as of 2015-01-01 when it began flagging EVERYTHING by means of
> a DNS wildcard.
>
> Read:
>   http://www.ahbl.org/ (click through to the main page) and
>   http://rob0.nodns4.us/postscreen.html
>
> In the latter start with the BIG FAT WARNING and then take special
> note of what it says about AHBL in the "Last Changes" section.
>
>>bl.spamcop.net
>>  dnsbl.sorbs.net
>>  psbl.surriel.com
>>  bl.mailspike.net
>>  swl.spamhaus.org*-4
>>  list.dnswl.org=127.[0..255].[0..255].0*-2
>>  list.dnswl.org=127.[0..255].[0..255].1*-3
>>  list.dnswl.org=127.[0..255].[0..255].[2..255]*-4
>
> These are as I published them but they are wrong.  Better:
>list.dnswl.org=127.0.[2..15].0*-2
>list.dnswl.org=127.0.[2..15].1*-3
>list.dnswl.org=127.0.[2..15].[2..3]*-4
> This corresponds to DNSWL.org's own usage instructions.
>
>> postscreen_dnsbl_threshold = 2
>> postscreen_dnsbl_whitelist_threshold = -2
>
> Looks familiar except you changed these two threshold values.  Just
> stick with what I have:
>   postscreen_dnsbl_threshold = 3
>   postscreen_dnsbl_whitelist_threshold = -1
>
> Your lower postscreen_dnsbl_threshold value caused every single AHBL
> listing (which, in case you didn't understand, now includes the
> entirety of the Internet) to be a rejection unless offset by a
> whitelist entry.
>
> Your higher whitelist threshold makes it more difficult to avoid the
> after-220 tests ...
>
>> ### End of before-220 tests
>> ### After-220 tests
>> ### WARNING -- See "Tests after the 220 SMTP server greeting" in the
>> ### Postscreen Howto and *UNDERSTAND* it *BEFORE* you enable the
>> ### following tests!
>> #postscreen_bare_newline_action = drop
>> #postscreen_bare_newline_enable = yes
>> #postscreen_non_smtp_command_action = drop
>> #postscreen_non_smtp_command_enable = yes
>> #postscreen_pipelining_enable = yes
>> #postscreen_pipelining_action = drop
>> ### ADDENDUM: Any one of the foregoing three *_enable settings may cause
>> ### significant and annoying mail delays.
>
> ... which in your case doesn't matter because you didn't enable them.
>
>> Any assistance appreciated.
>
> Lose AHBL.
> --
>   http://rob0.nodns4.us/
>   Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
>

Re: gmail servers on blacklists?

[/dev/rob0]

On Fri, Mar 17, 2017 at 05:12:07PM -0400, David Mehler wrote:
> I'm starting to see blocks on my messages to my mail server. For some
> reason postscreen is not letting any gmail servers send mail, it's
> blocking them.
> 
> Has anyone got an idea or have you seen this?

Typically you would SHOW LOGS of the blocking when asking for help, 
but in your case it's pretty obvious.

> Here's my postscreen setup:
> 
> # postscreen(8) settings
> ### Before-220 tests
> postscreen_greet_action = enforce
> postscreen_blacklist_action = enforce
> postscreen_dnsbl_action = enforce
> postscreen_access_list = permit_mynetworks
> cidr:/usr/local/etc/postfix/postscreen_access.cidr
> postscreen_dnsbl_reply_map =
> pcre:/usr/local/etc/postfix/postscreen_dnsbl_reply_map.pcre
> postscreen_dnsbl_sites = zen.spamhaus.org*3
>  b.barracudacentral.org*2
>  bl.spameatingmonkey.net*2
>  dnsbl.ahbl.org*2

Closed as of 2015-01-01 when it began flagging EVERYTHING by means of 
a DNS wildcard.

Read:
  http://www.ahbl.org/ (click through to the main page) and
  http://rob0.nodns4.us/postscreen.html

In the latter start with the BIG FAT WARNING and then take special 
note of what it says about AHBL in the "Last Changes" section.

>bl.spamcop.net
>  dnsbl.sorbs.net
>  psbl.surriel.com
>  bl.mailspike.net
>  swl.spamhaus.org*-4
>  list.dnswl.org=127.[0..255].[0..255].0*-2
>  list.dnswl.org=127.[0..255].[0..255].1*-3
>  list.dnswl.org=127.[0..255].[0..255].[2..255]*-4

These are as I published them but they are wrong.  Better:
   list.dnswl.org=127.0.[2..15].0*-2
   list.dnswl.org=127.0.[2..15].1*-3
   list.dnswl.org=127.0.[2..15].[2..3]*-4
This corresponds to DNSWL.org's own usage instructions.

> postscreen_dnsbl_threshold = 2
> postscreen_dnsbl_whitelist_threshold = -2

Looks familiar except you changed these two threshold values.  Just 
stick with what I have:
  postscreen_dnsbl_threshold = 3
  postscreen_dnsbl_whitelist_threshold = -1

Your lower postscreen_dnsbl_threshold value caused every single AHBL 
listing (which, in case you didn't understand, now includes the 
entirety of the Internet) to be a rejection unless offset by a 
whitelist entry.

Your higher whitelist threshold makes it more difficult to avoid the 
after-220 tests ...

> ### End of before-220 tests
> ### After-220 tests
> ### WARNING -- See "Tests after the 220 SMTP server greeting" in the
> ### Postscreen Howto and *UNDERSTAND* it *BEFORE* you enable the
> ### following tests!
> #postscreen_bare_newline_action = drop
> #postscreen_bare_newline_enable = yes
> #postscreen_non_smtp_command_action = drop
> #postscreen_non_smtp_command_enable = yes
> #postscreen_pipelining_enable = yes
> #postscreen_pipelining_action = drop
> ### ADDENDUM: Any one of the foregoing three *_enable settings may cause
> ### significant and annoying mail delays.

... which in your case doesn't matter because you didn't enable them.

> Any assistance appreciated.

Lose AHBL.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: policyd-spf and temperrors

[James B. Byrne]

On Fri, March 17, 2017 12:57, Thomas Leuxner wrote:
> * James B. Byrne  2017.03.17 17:44:
>
>> Mar 17 12:31:22 inet08 postfix/spawn[14598]: warning: command
>> /usr/libexec/postfix/policyd-spf exit status 1
>
> It is spawned per mail in my configuration:
>
> $ postconf -nf | grep -A1 private/policyd
> check_policy_service { unix:private/policyd-spf, timeout=10s,
> default_action=DUNNO }
>
> $ postconf -Mf | grep policyd
> policyd-spf unix -   n   n   -   0   spawn
> user=policyd-spf
> argv=/usr/bin/policyd-spf
>
> As its written in Python it depends on a working environment. Any
> chance this recently has been updated on this machine?
>
> Regards
> Thomas
>

The host system runs under CentOS-6.  Other than Postfix itself all
the packages on this system are either from CentOS or EPEL.  Python
was last updated in September 2016.  pypolicd-spf was last updated
January 2017.  These problems only evidenced themselves very recently:

[root@inet08 ~]# ll  /var/log/maillog*
-rw---. 1 root root 53522676 Mar 17 17:27 /var/log/maillog
-rw---. 1 root root 40029710 Feb 19 03:10 /var/log/maillog-20170219
-rw---. 1 root root 53658030 Feb 26 03:45 /var/log/maillog-20170226
-rw---. 1 root root 53710015 Mar  5 03:32 /var/log/maillog-20170305
-rw---. 1 root root 48568993 Mar 12 03:39 /var/log/maillog-20170312

[root@inet08 ~]# grep Temperror /var/log/maillog-20170219 | wc -l
187
[root@inet08 ~]# grep Temperror /var/log/maillog-20170226 | wc -l
72
[root@inet08 ~]# grep Temperror /var/log/maillog-20170305 | wc -l
107
[root@inet08 ~]# grep Temperror /var/log/maillog-20170312 | wc -l
134
[root@inet08 ~]# grep Temperror /var/log/maillog | wc -l
11615

The issue was first noticed yesterday. but appears to have started on
the 15th.

[root@inet08 ~]# grep Temperror /var/log/maillog | grep 'Mar 12' | wc -l
2
[root@inet08 ~]# grep Temperror /var/log/maillog | grep 'Mar 13' | wc -l
3
[root@inet08 ~]# grep Temperror /var/log/maillog | grep 'Mar 14' | wc -l
4
[root@inet08 ~]# grep Temperror /var/log/maillog | grep 'Mar 15' | wc -l
1516
[root@inet08 ~]# grep Temperror /var/log/maillog | grep 'Mar 16' | wc -l
3696
[root@inet08 ~]# grep Temperror /var/log/maillog | grep 'Mar 17' | wc -l
6394

Moving to the most recent version of pypolicyd-spf requires upgrading
python.  Since the YUM package manager on CentOS-6 requires python 2.6
this is a non-starter.

We are in the process of moving off Linux to FreeBSD in any case.  I
will spin up a BHyve FreeBSD instance for Postfix and migrate our MX
address to the new server.  So much for the weekend.


-- 
***  e-Mail is NOT a SECURE channel  ***
Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3

Re: gmail servers on blacklists?

[Christian Kivalo]

On 2017-03-17 22:12, David Mehler wrote:

Hello,

I'm starting to see blocks on my messages to my mail server. For some
reason postscreen is not letting any gmail servers send mail, it's
blocking them.

Has anyone got an idea or have you seen this?
You could use postwhite https://github.com/stevejenkins/postwhite to 
whitelist gmail.

The map is created by postwhite from gmails spf records.

--
 Christian Kivalo

Re: policyd-spf and temperrors

[James B. Byrne]

On Fri, March 17, 2017 16:49, Scott Kitterman wrote:
>
>
> On March 17, 2017 12:20:11 PM EDT, "James B. Byrne"
>  wrote:
>>I have just noticed this error.  I suspect this points to the root of
>>our problems.  What does it mean?
>>
>>
>>Mar 17 12:16:58 inet08 postfix-p25/smtpd[14495]: connect from
>>russian-caravan.cloud9.net[168.100.1.4]
>>Mar 17 12:16:59 inet08 postfix-p25/smtpd[14529]: warning: problem
>>talking to server private/policyd-spf: Connection timed out
>
> You didn't say what version of the policy server you are running.
> There was a design issue that caused it to make multiple, sequential
> lookups of the same domain.  Depending on how fast your DNS is and the
> configuration, it could cause these kinds of problems.
>
> I reworked all that in version 2.0.  If you are running an earlier
> version, upgrading will likely help.
>
> You also didn't mention if there's a caching resolver on the server.
> That would also help since the redundant lookups would at least hit
> the local cache.
>
> You can ask questions or file bugs specific to this policy server at
> https://launchpad.net/pypolicyd-spf
>
> Scott K
>

Installed Packages
Name: pypolicyd-spf
Arch: noarch
Version : 1.3.2
Release : 1.el6
Size: 106 k
Repo: installed
>From repo   : epel
Summary : SPF Policy Server for Postfix (Python implementation)
URL : https://launchpad.net/pypolicyd-spf
License : ASL 2.0

We currently run a DNS service on that host.  It is operating
correctly as far as I can see.

In the meantime I have had to disable SPF checking entirely as it was
preventing the delivery of any mail whatsoever.

-- 
***  e-Mail is NOT a SECURE channel  ***
Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3

gmail servers on blacklists?

[David Mehler]

Hello,

I'm starting to see blocks on my messages to my mail server. For some
reason postscreen is not letting any gmail servers send mail, it's
blocking them.

Has anyone got an idea or have you seen this?

Here's my postscreen setup:

# postscreen(8) settings
### Before-220 tests
postscreen_greet_action = enforce
postscreen_blacklist_action = enforce
postscreen_dnsbl_action = enforce
postscreen_access_list = permit_mynetworks
cidr:/usr/local/etc/postfix/postscreen_access.cidr
postscreen_dnsbl_reply_map =
pcre:/usr/local/etc/postfix/postscreen_dnsbl_reply_map.pcre
postscreen_dnsbl_sites = zen.spamhaus.org*3
 b.barracudacentral.org*2
 bl.spameatingmonkey.net*2
 dnsbl.ahbl.org*2
   bl.spamcop.net
 dnsbl.sorbs.net
 psbl.surriel.com
 bl.mailspike.net
 swl.spamhaus.org*-4
 list.dnswl.org=127.[0..255].[0..255].0*-2
 list.dnswl.org=127.[0..255].[0..255].1*-3
 list.dnswl.org=127.[0..255].[0..255].[2..255]*-4
postscreen_dnsbl_threshold = 2
postscreen_dnsbl_whitelist_threshold = -2
### End of before-220 tests
### After-220 tests
### WARNING -- See "Tests after the 220 SMTP server greeting" in the
### Postscreen Howto and *UNDERSTAND* it *BEFORE* you enable the
### following tests!
#postscreen_bare_newline_action = drop
#postscreen_bare_newline_enable = yes
#postscreen_non_smtp_command_action = drop
#postscreen_non_smtp_command_enable = yes
#postscreen_pipelining_enable = yes
#postscreen_pipelining_action = drop
### ADDENDUM: Any one of the foregoing three *_enable settings may cause
### significant and annoying mail delays.
# For sharing a tempoary whitelist of addresses
postscreen_cache_map = proxy:btree:${data_directory}/postscreen_cache
postscreen_cache_cleanup_interval = 0
   # Rules are evaluated in the order as specified.
   # Blacklist 192.168.* except 192.168.0.1.

# /usr/local/etc/postfix/postscreen_access.cidr 2011-02-27
# A simple combined white/blacklist
# Only "permit", "reject" and "dunno" work on the RHS
# This is a CIDR table, so see cidr_table(5) for LHS syntax

# Permit local clients
127.0.0.0/8 permit

# 2011-05-17 brute force attack
# May 17 05:35:14 cardinal postfix/anvil[3667]: statistics: max
# connection count 47 for (smtpd:66.23.228.27) at May 17 05:31:38
66.23.228.27reject
# a lot from here including some DBL hits
108.62.112.160/29   reject
# 2011-08-09 eWayDirect whitelisted, but hitting spamtraps
# was having PREGREET protocol errors before today
207.45.161.0/24 reject
##
# 2011-11-22 brute force mail attacks, smtp and imap
61.175.253.59   reject
# 2012-09-23 spammer not in DNSBLs
66.7.197.45 reject
# 2012-11-19 hillapex.com spammer
184.173.107.11  reject
# Allow gmail server through
74.125.82.43permit

Any assistance appreciated.

Thanks.
Dave.

Re: policyd-spf and temperrors

[Scott Kitterman]

On March 17, 2017 12:20:11 PM EDT, "James B. Byrne"  
wrote:
>I have just noticed this error.  I suspect this points to the root of
>our problems.  What does it mean?
>
>
>Mar 17 12:16:58 inet08 postfix-p25/smtpd[14495]: connect from
>russian-caravan.cloud9.net[168.100.1.4]
>Mar 17 12:16:59 inet08 postfix-p25/smtpd[14529]: warning: problem
>talking to server private/policyd-spf: Connection timed out

You didn't say what version of the policy server you are running.  There was a 
design issue that caused it to make multiple, sequential lookups of the same 
domain.  Depending on how fast your DNS is and the configuration, it could 
cause these kinds of problems.

I reworked all that in version 2.0.  If you are running an earlier version, 
upgrading will likely help.

You also didn't mention if there's a caching resolver on the server.  That 
would also help since the redundant lookups would at least hit the local cache.

You can ask questions or file bugs specific to this policy server at 
https://launchpad.net/pypolicyd-spf

Scott K

Re: policyd-spf and temperrors

[Noel Jones]

On 3/17/2017 1:09 PM, Wietse Venema wrote:
> Thomas Leuxner:
> 
> Checking application/pgp-signature: FAILURE
> -- Start of PGP signed section.
>> * James B. Byrne  2017.03.17 17:20:
>>
>>> Mar 17 12:16:58 inet08 postfix-p25/smtpd[14495]: connect from
>>> russian-caravan.cloud9.net[168.100.1.4]
>>> Mar 17 12:16:59 inet08 postfix-p25/smtpd[14529]: warning: problem
>>> talking to server private/policyd-spf: Connection timed out
> 
> It times out after 1 second. That seems very short to me, even for
> UNIX-domain.
> 
>   Wietse
> 

different process numbers above.


  -- Noel Jones

Re: policyd-spf and temperrors

[Wietse Venema]

Thomas Leuxner:

Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.
> * James B. Byrne  2017.03.17 17:20:
> 
> > Mar 17 12:16:58 inet08 postfix-p25/smtpd[14495]: connect from
> > russian-caravan.cloud9.net[168.100.1.4]
> > Mar 17 12:16:59 inet08 postfix-p25/smtpd[14529]: warning: problem
> > talking to server private/policyd-spf: Connection timed out

It times out after 1 second. That seems very short to me, even for
UNIX-domain.

Wietse

Re: Monitoring Postfix Mail queue with SNMP

[Viktor Dukhovni]

> On Mar 17, 2017, at 1:06 PM, Sean Son  
> wrote:
> 
> Hello all
> 
> We would like to monitor Postfix mail queues using SMNP so we can receive 
> alerts whenever the mail queue reaches a certain threshold. What OID and MIB 
> would we have to use to be able to monitor Postfix mail queues?

I don't recall a specific MIB that covers mail queues, however
I recommend against monitoring the queue's message count, too
many false alarms from spikes in traffic.  What is more useful
to monitor is average time from queue entry to queue exit, and
also average age in the active queue.

See QSHAPE_README and also monitor the "c+d" delay sum from
the "delays=a/b/c/d" log entries (de-duping for multi-recipient
deliveries of a single message).  At prior employer, we computed
a slowly exponentially decaying moving average of the "c+d" times
as indicators of current congestion, and queue age as indicators
of "stuck" messages.

Just counting messages is not terribly useful IMHO.

-- 
Viktor.

Re: policyd-spf and temperrors

[Viktor Dukhovni]

> On Mar 17, 2017, at 12:20 PM, James B. Byrne  wrote:
> 
> I have just noticed this error.  I suspect this points to the root of
> our problems.

Not the cause, but a related symptom...

> What does it mean?

DNS lookups in policyd-spf are sufficient slow to not keep up with
demand.  You may need to raise the process limit on the service,
or make sure that it does non-blocking DNS lookups and is willing
to have more outstanding queries...


> 
> Mar 17 12:16:58 inet08 postfix-p25/smtpd[14495]: connect from
> russian-caravan.cloud9.net[168.100.1.4]
> Mar 17 12:16:59 inet08 postfix-p25/smtpd[14529]: warning: problem
> talking to server private/policyd-spf: Connection timed out
> 

-- 
Viktor.

Monitoring Postfix Mail queue with SNMP

[Sean Son]

Hello all

We would like to monitor Postfix mail queues using SMNP so we can receive
alerts whenever the mail queue reaches a certain threshold. What OID and
MIB would we have to use to be able to monitor Postfix mail queues?


Thank you for all of your help in this post and other posts of mine!


Sean

Re: policyd-spf and temperrors

[Thomas Leuxner]

* James B. Byrne  2017.03.17 17:44:

> Mar 17 12:31:22 inet08 postfix/spawn[14598]: warning: command
> /usr/libexec/postfix/policyd-spf exit status 1

It is spawned per mail in my configuration:

$ postconf -nf | grep -A1 private/policyd
check_policy_service { unix:private/policyd-spf, timeout=10s,
default_action=DUNNO }

$ postconf -Mf | grep policyd
policyd-spf unix -   n   n   -   0   spawn user=policyd-spf
argv=/usr/bin/policyd-spf

As its written in Python it depends on a working environment. Any chance this 
recently has been updated on this machine?

Regards
Thomas


signature.asc
Description: Digital signature

Re: policyd-spf and temperrors

[James B. Byrne]

I have also seen this:

Mar 17 12:31:22 inet08 postfix/spawn[14598]: warning: command
/usr/libexec/postfix/policyd-spf exit status 1


However, these message only began to appear yesterday evening.  This
is the first occurrence found in logs going back to February 12:

var/log/maillog:Mar 16 17:15:09 inet08 postfix-p25/smtpd[17270]:
warning: problem talking to server private/policyd-spf: Connection
timed out

Temperrors have apparently being going on forever. Often related to
outbound.protection.outlook.com.  So it is possible that there really
is no problem.  But there are lots of regular correspondents that are
suddenly having this problem delivering their mail to us so I remain
suspicious that we have a problem somewhere in our setup.


-- 
***  e-Mail is NOT a SECURE channel  ***
Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3

Re: policyd-spf and temperrors

[Thomas Leuxner]

* James B. Byrne  2017.03.17 17:20:

> Mar 17 12:16:58 inet08 postfix-p25/smtpd[14495]: connect from
> russian-caravan.cloud9.net[168.100.1.4]
> Mar 17 12:16:59 inet08 postfix-p25/smtpd[14529]: warning: problem
> talking to server private/policyd-spf: Connection timed out

It means Postfix is unable to communicate with the UNIX socket policy-spf is 
supposed to listen on.

Regards
Thomas


signature.asc
Description: Digital signature

Re: policyd-spf and temperrors

[James B. Byrne]

I have just noticed this error.  I suspect this points to the root of
our problems.  What does it mean?


Mar 17 12:16:58 inet08 postfix-p25/smtpd[14495]: connect from
russian-caravan.cloud9.net[168.100.1.4]
Mar 17 12:16:59 inet08 postfix-p25/smtpd[14529]: warning: problem
talking to server private/policyd-spf: Connection timed out



-- 
***  e-Mail is NOT a SECURE channel  ***
Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3

Re: Problems with lmtp

[Thomas Leuxner]

* chaouche yacine  2017.03.17 14:52:

> Thank you Thomas, so if I understand correctly in Viktor's config dovecot is 
> only used by postfix as a backend to query for valid virtual email addresses ?

Hi Yassine,

one of the benefits of using Dovecot's MDAs besides Sieve, is that they update 
the metadata and indexes upon delivery which improves its IMAP performance. You 
also get a broader choice of mailstorage formats which offer new features 
compared to the older maildir format.

Regards
Thomas


signature.asc
Description: Digital signature

Re: policyd-spf and temperrors

[Viktor Dukhovni]

> On Mar 17, 2017, at 12:08 PM, James B. Byrne  wrote:
> 
> Mar 17 11:39:47 inet08 policyd-spf[13505]: Temperror; identity=helo;
> client-ip=69.89.30.42; helo=gproxy3-pub.mail.unifiedlayer.com;
> envelope-from=p...@thecargosolutionscanada.com;
> receiver=b...@harte-lyne.ca
> . . .
> Mar 17 11:42:52 inet08 policyd-spf[13032]: Temperror; identity=helo;
> client-ip=168.100.1.4; helo=russian-caravan.cloud9.net;
> envelope-from=owner-postfix-us...@postfix.org;
> receiver=b...@harte-lyne.ca
> . . .
> Mar 17 11:51:36 inet08 policyd-spf[13709]: Temperror; identity=helo;
> client-ip=66.135.215.173; helo=mxslcpool71.ebay.com;
> envelope-from=e...@ebay.com; receiver=b...@harte-lyne.ca
> 
> They cannot all be suddenly affected by a DNS outage?

Well, just today a notice was posted by the RIPE NCC (see below
my signature) announcing an outage in reverse delegations from
ARIN to RIPE.  It is not clear whether that could contribute to
tempfails in your SPF policy daemon (I'd rather expect spurious
NXDOMAIN results for PTR lookups), but bulk outages can certainly
happen.

Enable more detailed logging in the SPF policy daemon and perhaps
also your resolver.

-- 
Viktor.

Dear colleagues,

Between 17:00 UTC yesterday and 10:00 UTC today, we had an issue that
affected some reverse DNS delegations. The delegations in the
RIPE Database where the parent zone is operated by ARIN were affected.

RIPE NCC publishes zonelet files containing these delegations, and these
are picked up by ARIN's DNS provisioning system periodically. At the end
of these zonelet files is a summary of the counts of various types of
DNS records. A bug in our code accidentally published these summaries
with zero counts, and as a result, the ARIN DNS provisioning system
appears to have removed the delegations.

We have corrected this bug, and the zonelet files now contain the
correct counts. They have been published on the RIPE NCC FTP server, and
ARIN's DNS provisioning system has picked them up and reintroduced the
delegations.

We apologise for any inconvenience caused by this. This is the first
time that such an issue has occurred with delegations that are exchanged
by the zonelet mechanism, and we will try to engineer monitoring to
prevent such an outage in the future.

RIPE NCC's delegations in the following ARIN-operated zones were
affected. The majority of the other delegations in these zones come from
ARIN and the other registries, and were not affected.

104.in-addr.arpa.
107.in-addr.arpa.
128.in-addr.arpa.
129.in-addr.arpa.
130.in-addr.arpa.
131.in-addr.arpa.
132.in-addr.arpa.
134.in-addr.arpa.
135.in-addr.arpa.
136.in-addr.arpa.
137.in-addr.arpa.
138.in-addr.arpa.
139.in-addr.arpa.
13.in-addr.arpa.
140.in-addr.arpa.
143.in-addr.arpa.
144.in-addr.arpa.
146.in-addr.arpa.
147.in-addr.arpa.
148.in-addr.arpa.
149.in-addr.arpa.
152.in-addr.arpa.
156.in-addr.arpa.
157.in-addr.arpa.
158.in-addr.arpa.
159.in-addr.arpa.
160.in-addr.arpa.
161.in-addr.arpa.
164.in-addr.arpa.
165.in-addr.arpa.
166.in-addr.arpa.
168.in-addr.arpa.
169.in-addr.arpa.
170.in-addr.arpa.
173.in-addr.arpa.
198.in-addr.arpa.
199.in-addr.arpa.
206.in-addr.arpa.
209.in-addr.arpa.
216.in-addr.arpa.
23.in-addr.arpa.
24.in-addr.arpa.
45.in-addr.arpa.
52.in-addr.arpa.
65.in-addr.arpa.
66.in-addr.arpa.

Re: policyd-spf and temperrors

[James B. Byrne]

On Fri, March 17, 2017 11:41, Viktor Dukhovni wrote:
>
>> On Mar 17, 2017, at 11:31 AM, James B. Byrne 
>> wrote:
>>
>> mohawkglobalta.com. 1476IN  TXT "v=spf1
>> include:spf.protection.outlook.com ip4:208.33.203.70/31 -all"
>
> Don't forget the lookups needed to process the "include:" clause, and
> the fact that DNS observations vary with time.
>
> $ dig +short -t txt spf.protection.outlook.com
> "v=spf1 ip4:207.46.101.128/26 ip4:207.46.100.0/24 ip4:207.46.163.0/24
> ip4:65.55.169.0/24 ip4:157.56.110.0/23 ip4:157.55.234.0/24
> ip4:213.199.154.0/24 ip4:213.199.180.0/24
> include:spfa.protection.outlook.com -all"
>
> $ dig +short -t txt spfa.protection.outlook.com
> "v=spf1 ip4:157.56.112.0/24 ip4:207.46.51.64/26 ip4:157.55.158.0/23
> ip4:64.4.22.64/26 ip4:40.92.0.0/14 ip4:40.107.0.0/17
> ip4:40.107.128.0/18 ip4:134.170.140.0/24
> include:spfb.protection.outlook.com -all"
>
> $ dig +short -t txt spfb.protection.outlook.com
> "v=spf1 ip6:2a01:111:f400::/48 ip4:23.103.128.0/19 ip4:23.103.198.0/23
> ip4:65.55.88.0/24 ip4:104.47.0.0/17 ip4:23.103.200.0/21
> ip4:23.103.208.0/21 ip4:23.103.191.0/24 ip4:216.32.180.0/23
> ip4:94.245.120.64/26 -all"
>
> [ These have a 10 minute TTL ]
>

However, dig lookups performed on these exact domains return virtually
instantaneously on our MX server running spf.  I can set the spf
timeout higher than 20 seconds but I suspect that something else is at
work here.

This Temperror is also affecting these sites and many more:

Mar 17 11:39:47 inet08 policyd-spf[13505]: Temperror; identity=helo;
client-ip=69.89.30.42; helo=gproxy3-pub.mail.unifiedlayer.com;
envelope-from=p...@thecargosolutionscanada.com;
receiver=b...@harte-lyne.ca
. . .
Mar 17 11:42:52 inet08 policyd-spf[13032]: Temperror; identity=helo;
client-ip=168.100.1.4; helo=russian-caravan.cloud9.net;
envelope-from=owner-postfix-us...@postfix.org;
receiver=b...@harte-lyne.ca
. . .
Mar 17 11:51:36 inet08 policyd-spf[13709]: Temperror; identity=helo;
client-ip=66.135.215.173; helo=mxslcpool71.ebay.com;
envelope-from=e...@ebay.com; receiver=b...@harte-lyne.ca

They cannot all be suddenly affected by a DNS outage?

(P.S. thecargosolutionscanada.com would fail anyway due to too many
DNS lookups, but it does not get that far in the process.)


-- 
***  e-Mail is NOT a SECURE channel  ***
Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3

Re: policyd-spf and temperrors

[Viktor Dukhovni]

> On Mar 17, 2017, at 11:31 AM, James B. Byrne  wrote:
> 
> mohawkglobalta.com. 1476IN  TXT "v=spf1 
> include:spf.protection.outlook.com ip4:208.33.203.70/31 -all"

Don't forget the lookups needed to process the "include:" clause, and the fact 
that DNS observations vary with time.

$ dig +short -t txt spf.protection.outlook.com
"v=spf1 ip4:207.46.101.128/26 ip4:207.46.100.0/24 ip4:207.46.163.0/24 
ip4:65.55.169.0/24 ip4:157.56.110.0/23 ip4:157.55.234.0/24 ip4:213.199.154.0/24 
ip4:213.199.180.0/24 include:spfa.protection.outlook.com -all"

$ dig +short -t txt spfa.protection.outlook.com
"v=spf1 ip4:157.56.112.0/24 ip4:207.46.51.64/26 ip4:157.55.158.0/23 
ip4:64.4.22.64/26 ip4:40.92.0.0/14 ip4:40.107.0.0/17 ip4:40.107.128.0/18 
ip4:134.170.140.0/24 include:spfb.protection.outlook.com -all"

$ dig +short -t txt spfb.protection.outlook.com
"v=spf1 ip6:2a01:111:f400::/48 ip4:23.103.128.0/19 ip4:23.103.198.0/23 
ip4:65.55.88.0/24 ip4:104.47.0.0/17 ip4:23.103.200.0/21 ip4:23.103.208.0/21 
ip4:23.103.191.0/24 ip4:216.32.180.0/23 ip4:94.245.120.64/26 -all"

[ These have a 10 minute TTL ]

-- 
Viktor.

policyd-spf and temperrors

[James B. Byrne]

OS=CentOS-6.8 (Linux)

postconf -d | grep mail_version # version
mail_version = 2.11.1
milter_macro_v = $mail_name $mail_version


We are currently experiencing an outage at a remote site that happens
to provide two of our four DNS services.  We have also recently, I am
tempted to write co-incidentally, begun to reject mail from many sites
due to policyd-spf DNS timeout errors similar to the following:


Mar 17 10:57:58 inet08 policyd-spf[12275]: Temperror; identity=helo;
client-ip=208.33.203.70; helo=mgmx.mohawkglobal.com;
envelope-from=usern...@mohawkglobalta.com;
receiver=usern...@harte-lyne.ca

Mar 17 10:58:18 inet08 policyd-spf[12275]: Temperror;
identity=mailfrom; client-ip=208.33.203.70;
helo=mgmx.mohawkglobal.com; envelope-from=usern...@mohawkglobalta.com;
receiver=usern...@harte-lyne.ca


When I test our policyd-spf.conf this is what I see:


/usr/libexec/postfix/policyd-spf /etc/python-policyd-spf/policyd-spf.conf
protocol_name=SMTP
protocol_state=RCPT
request=smtpd_access_policy
client_address=208.33.203.70
client_name=mgmx.mohawkglobal.com
helo_name=mgmx.mohawkglobal.com
sender=usern...@mohawkglobalta.com
recipient=usern...@harte-lyne.ca

action=prepend Received-SPF: Temperror (SPF Temporary Error: DNS
Timeout) identity=mailfrom;
  client-ip=208.33.203.70;
  helo=mgmx.mohawkglobal.com;
  envelope-from=usern...@mohawkglobalta.com;
  receiver=usern...@harte-lyne.ca


However if I dig the sender's address from the same host then I see no
delay:

dig mohawkglobalta.com TXT

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6_8.4 <<>>
mohawkglobalta.com TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34357
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 1

;; QUESTION SECTION:
;mohawkglobalta.com.IN  TXT

;; ANSWER SECTION:
mohawkglobalta.com. 1476IN  TXT "v=spf1
include:spf.protection.outlook.com ip4:208.33.203.70/31 -all"
mohawkglobalta.com. 1476IN  TXT "MS=ms37967191"

;; AUTHORITY SECTION:
mohawkglobalta.com. 10552   IN  NS  ns1190.dns.dyn.com.
mohawkglobalta.com. 10552   IN  NS  ns3159.dns.dyn.com.
mohawkglobalta.com. 10552   IN  NS  ns2166.dns.dyn.com.
mohawkglobalta.com. 10552   IN  NS  ns4181.dns.dyn.com.

;; ADDITIONAL SECTION:
ns4181.dns.dyn.com. 1603IN  A   208.76.61.181

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Mar 17 11:12:20 2017
;; MSG SIZE  rcvd: 250


Suddenly began getting these Temperrors reports for multiple sites
while there has been no changes made to our mail server or
configuration for some time.  This does not appear to be a problem
with the senders but I cannot fathom what local issue could be causing
the problem.

To short-circuit the issue I have set defaultSeedOnly = 0 in 
/etc/python-policyd-spf/policyd-spf.conf.  However, this is a
temporary measure and I need to uncover and deal with the underlying
issue quickly.

Does anyone have a clue as to why this is happening and how to correct
it?

Configuration files follow:


postconf -nf
alias_maps = hash:/etc/aliases
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd
$daemon_directory/$process_name $process_id & sleep 5
delay_warning_time = 15m
disable_vrfy_command = yes
header_checks = regexp:/etc/postfix/header_checks.regexp
home_mailbox = Maildir/
html_directory = no
ignore_mx_lookup_error = no
inet_interfaces = localhost, inet08.hamilton.harte-lyne.ca
inet_protocols = all
local_transport = smtp
mail_spool_directory = /var/spool/mail
mailman_destination_recipient_limit = 1
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 2048
milter_default_action = accept
milter_protocol = 2
mydestination =
mynetworks = 216.185.71.0/26, 216.185.71.64/27, 209.47.176.0/26,
192.168.216.0/24, 192.168.8.0/24, 192.168.7.0/24, 192.168.6.0/24,
127.0.0.0/8
newaliases_path = /usr/bin/newaliases.postfix
non_smtpd_milters = $smtpd_milters
policyd-spf_time_limit = 3600
queue_minfree = 4096
rbl_reply_maps = hash:/etc/postfix/rbl_reply
readme_directory = /usr/share/doc/postfix-2.11.1/README_FILES
recipient_delimiter = +
relay_clientcerts = hash:/etc/postfix/relay_clientcerts
relay_domains = hash:/etc/postfix/relay_domains
sample_directory = /usr/share/doc/postfix-2.11.1/samples
sender_canonical_maps = hash:/etc/postfix/canonical
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_dns_support_level = dnssec
smtp_host_lookup = dns
smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtp_tls_cert_file = /etc/pki/tls/certs/ca.harte-lyne.smtp.crt
smtp_tls_ciphers = medium
smtp_tls_exclude_ciphers = MD5, aDSS, SRP, PSK, aECDH, aDH, SEED,
IDEA, RC2, 

Re: Problems with lmtp

[Viktor Dukhovni]

> On Mar 17, 2017, at 9:52 AM, chaouche yacine  wrote:
> 
> Thank you Thomas, so if I understand correctly in Viktor's config dovecot is 
> only used by postfix as a backend to query for valid virtual email addresses ?

Dovecot is used as an IMAP server.  Postfix does maildir delivery.

-- 
Viktor.

Re: Possibly o.t. Postfixadmin 3.x unable to log in

[Noel Jones]

On 3/17/2017 8:32 AM, David Mehler wrote:
> Hello,
> 
> Not sure if this is the right place for this question.
> 


You can get support for postfixadmin from their wiki and user forum.

Re: How to get mail relay to work

[paul.greene.va]

Thank you for responding. Problem turned out to be upstream; nothing 
wrong with postfix.



On 3/17/2017 8:50 AM, Larry Stone wrote:

Your original post did not indicate a problem you are having.

The only question you asked was "Besides /etc/postfix/main.cf, is there any 
other files that need to be edited to enable this mail relaying?”. Was this an 
oblique way of saying “it’s not working, what else do I need to change” or are you 
just asking what else needs to be changed? It’s not clear if you’re still setting up 
the new system or if you’ve tried to run it and there’s a problem.

The answer to your question is “master.cf as well as any files referenced in 
main.cf”.

The better way to compare the main.cf files is to do a postconf -n on both. 
That displays only the parameters that have been changed from their defaults. 
Easier than scanning through a long main.cf looking for uncommented lines.

OTOH, if you are trying to run it and it’s not working, providing more 
information as requested in the list’s welcome message will help. As it says 
there:
TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail
That includes a list of what is required.

Re: Problems with lmtp

[chaouche yacine]

Thank you Thomas, so if I understand correctly in Viktor's config dovecot is 
only used by postfix as a backend to query for valid virtual email addresses ?

Re: How to get mail relay to work

[Wietse Venema]

paul.greene.va:
> Hello All,
> 
> Apologies in advance - I'm brand new to postfix; hopefully this question 
> won't be too newbish.
> 
> I've been given a task to get a freshly installed postfix server to 
> forward mail from an application - i.e. when changes are made to an 
> application, the application is supposed to send an email notification 
> to a specified email address.
> 
> There is an existing functioning postfix server that this new one is 
> replacing - the old one is running on redhat 6, postfix version 2.6; the 
> new one is running on redhat 7, postfix version 2.10.
> 
> I grepped for all of the uncommented lines in /etc/postfix/main.cf on 
> both the old and the new server and compared them; the configuration was 
> the same on both. The "relayhost = " parameter and the "mynetworks =" 
> parameter was the same on both

This is going to be a really slow process, unless you are willing
to invest the effort as requested in the mailing list welcome
message.

TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail

TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html

Thank you for using Postfix.

Possibly o.t. Postfixadmin 3.x unable to log in

[David Mehler]

Hello,

Not sure if this is the right place for this question.

I have no previous experience with Postfixadmin for domain and user
management with postfix as I usually do my configuration file editing
manually.

I've got a project where i'm needing to run it. I've got a postfix
2.11 and Postfixadmin 3.0 install in a virtual machine. The setup.php
is complete, database connectivity works fine. I've generated the hash
password and put that line in config.local.php and an admin email. I
am told that the admin email was entered properly and I can log in.
Checking the postfix mysql database shows this is so.

The problem is I try to log in via a browser and nothing, no errors
just back to the login screen. I am trying to do so over the internet
and the vm is behind a primary box, both running apache, the primary
box using the proxy module to reverse proxy the connection.

Any ideas what might be going on or any information I can provide?

Any assistance appreciated.

Thanks.
Dave.

Re: How to get mail relay to work

[Larry Stone]

Your original post did not indicate a problem you are having. 

The only question you asked was "Besides /etc/postfix/main.cf, is there any 
other files that need to be edited to enable this mail relaying?”. Was this an 
oblique way of saying “it’s not working, what else do I need to change” or are 
you just asking what else needs to be changed? It’s not clear if you’re still 
setting up the new system or if you’ve tried to run it and there’s a problem.

The answer to your question is “master.cf as well as any files referenced in 
main.cf”.

The better way to compare the main.cf files is to do a postconf -n on both. 
That displays only the parameters that have been changed from their defaults. 
Easier than scanning through a long main.cf looking for uncommented lines.

OTOH, if you are trying to run it and it’s not working, providing more 
information as requested in the list’s welcome message will help. As it says 
there:
TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail
That includes a list of what is required.

-- 
Larry Stone
lston...@stonejongleux.com





> On Mar 17, 2017, at 7:36 AM, paul.greene.va  
> wrote:
> 
> Maybe you're in an environment where you get to decide which equipment, 
> applications, whatever you want to use, but for some of us, this was already 
> decided long before we got there. We are using postfix for a mail server, 
> that's a given. I already admitted I'm very new to running a mail server; 
> this postfix mail server is not relaying email the way its supposed to. This 
> is a "support" mailing list, is it not? People ask questions on a postfix 
> support mailing list because they're trying to figure out how to get postfix 
> to work correctly.
> 
> 
> On 3/16/2017 11:29 PM, D'Arcy Cain wrote:
>> On 2017-03-16 09:34 PM, paul.greene.va wrote:
>>> I've been given a task to get a freshly installed postfix server to
>>> forward mail from an application - i.e. when changes are made to an
>>> application, the application is supposed to send an email notification
>>> to a specified email address.
>> 
>> I'm not sure that this is even a Postfix question.  I assume that there is 
>> some trigger in the application that handles changes. That application just 
>> needs to send an email.  Whatever mail server you are using should be 
>> irrelevant.  In fact, you could punt elsewhere and not have a mail server at 
>> all.
>> 
>> Perhaps I am not understanding the challenge.
>> 
> 

Re: How to get mail relay to work

[paul.greene.va]

Maybe you're in an environment where you get to decide which equipment, 
applications, whatever you want to use, but for some of us, this was 
already decided long before we got there. We are using postfix for a 
mail server, that's a given. I already admitted I'm very new to running 
a mail server; this postfix mail server is not relaying email the way 
its supposed to. This is a "support" mailing list, is it not? People ask 
questions on a postfix support mailing list because they're trying to 
figure out how to get postfix to work correctly.



On 3/16/2017 11:29 PM, D'Arcy Cain wrote:

On 2017-03-16 09:34 PM, paul.greene.va wrote:

I've been given a task to get a freshly installed postfix server to
forward mail from an application - i.e. when changes are made to an
application, the application is supposed to send an email notification
to a specified email address.


I'm not sure that this is even a Postfix question.  I assume that 
there is some trigger in the application that handles changes. That 
application just needs to send an email.  Whatever mail server you are 
using should be irrelevant.  In fact, you could punt elsewhere and not 
have a mail server at all.


Perhaps I am not understanding the challenge.

Re: Execute linux commands after receive a mail...

[Ron Wheeler]

What would be the human reaction to a 15 second  latency (nothing to 
regular e-mail service) on a light switch - hit it again and again until 
the first message arrives.
Fun to imagine lights suddenly turning on and off in rapid succession as 
delayed e-mail starts to get delivered a few seconds after the initial 
request.


The fridge could e-mail the grocery list when the milk runs low but 
e-mail not a good fit for  most IoT applications.


Ron

On 17/03/2017 3:18 AM, Sean Greenslade wrote:

On Thu, Mar 16, 2017 at 05:48:49PM -0700, li...@lazygranch.com wrote:

I had no idea you could receive email on any port. I wonder how many
ISPs allow this.

Sure, you can run any service on any port. The default ports (e.g. 25
for SMTP) are simply there to make interoperability easy.

Most ISPs do nothing to block specific services on specific ports. The
only thing I've ever seen is some residential ISPs block all outgoing
connections on port 25 to hamstring spambots on infected home PCs. This
is typically a blanket port ban, so it doesn't matter if it's a SMTP
server on that port or not; nothing goes out port 25. This generally
doesn't effect home users, since they almost always use a submission
port or a webmail client to get to their mail relay.


In any event, would this be THE scheme to use for an IOT application?
That is send an email to turn on/off a sprinker, light, etc. The idea
being postfix et all does all the security, AKA the hard part.

While it would certainly be _A_ way of doing IoT, I certainly wouldn't
call it _THE_ way. Email is not particularly well-suited for command and
control type applications. Lots of protocol and message overhead, high
latency, unidirectional channels...overall not a great fit.

--Sean





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Problems with lmtp

[Thomas Leuxner]

* chaouche yacine  2017.03.17 10:25:

> > Or similar, yes.  I have:
> >
> >userdb {
> >args = uid=500 gid=500 home=/var/spool/virtual 
> > mail=maildir:/var/spool/virtual/%n
> >driver = static
> >}
> 
> 
> Sorry for asking this on a postfix list but Viktor it seems all your users 
> share the same home directory ? what about sieve scripts ? 
> 
> -- Yassine.

The example used by Viktor does not invoke Dovecot's LDA/LMTP as MDA. Postfix 
performs final delivery, thus Sieve scripts can't be used.

 vmbox:
user1@virtual.invalid   user1/
user2@virtual.invalid   user2/

Regards
Thomas


signature.asc
Description: Digital signature

Re: Problems with lmtp

[chaouche yacine]

On Thursday, March 16, 2017 4:09 PM, Viktor Dukhovni 
 wrote:
>> The problem is then getting dovecot to understand what to do with that
>> fully qualified user once it gets it.  For my case, since the 'user' that
>> postfix is mapping to is the same as the local Unix user I want it delivered
>> to, the answer is to put this in dovecot.conf: auth_username_format=%n
>
> Or similar, yes.  I have:
>
>userdb {
>args = uid=500 gid=500 home=/var/spool/virtual 
> mail=maildir:/var/spool/virtual/%n
>driver = static
>}


Sorry for asking this on a postfix list but Viktor it seems all your users 
share the same home directory ? what about sieve scripts ? 

-- Yassine.

Re: Execute linux commands after receive a mail...

[Sean Greenslade]

On Thu, Mar 16, 2017 at 05:48:49PM -0700, li...@lazygranch.com wrote:
> I had no idea you could receive email on any port. I wonder how many
> ISPs allow this.

Sure, you can run any service on any port. The default ports (e.g. 25
for SMTP) are simply there to make interoperability easy.

Most ISPs do nothing to block specific services on specific ports. The
only thing I've ever seen is some residential ISPs block all outgoing
connections on port 25 to hamstring spambots on infected home PCs. This
is typically a blanket port ban, so it doesn't matter if it's a SMTP
server on that port or not; nothing goes out port 25. This generally
doesn't effect home users, since they almost always use a submission
port or a webmail client to get to their mail relay.

> In any event, would this be THE scheme to use for an IOT application?
> That is send an email to turn on/off a sprinker, light, etc. The idea
> being postfix et all does all the security, AKA the hard part.

While it would certainly be _A_ way of doing IoT, I certainly wouldn't
call it _THE_ way. Email is not particularly well-suited for command and
control type applications. Lots of protocol and message overhead, high
latency, unidirectional channels...overall not a great fit.

--Sean

Re: cloud9 rejecting my mail

[Doug]

Viktor,

As you'll see from my original message, I have all of the prerequisites. 

The problem persists ...

Also, FWIW, I'm not alone with this issue. Another user contacted me privately 
to say that he's having the same problem. 

Doug


On Thu, 3/16/17, Viktor Dukhovni  wrote:

 Subject: Re: cloud9 rejecting my mail
 To: "Postfix users" 
 Date: Thursday, March 16, 2017, 12:11 PM
 
 
 >
 On Mar 16, 2017, at 2:37 PM, Wietse Venema 
 wrote:
 > 
 >> When
 trying to sign up for the list from my regular e-mail
 address
 >> (served by my Postfix mail
 server, on a vhost at Arp Networks) I
 >> got the following:
 >> 
 >> :
 host mail.cloud9.net[2604:8d00:0:1::4]
 >> said: 554 5.7.1 :
 Helo command rejected: Access denied
 >> (in reply to RCPT TO command)
 
 Note the use of IPv6 here. 
 Many large providers have chosen to set the
 bar higher for IPv6 than IPv4.  In
 particular:
 
   * PTR
 records are generally mandatory
   * SPF
 and/or DKIM records are often mandatory
 
 sadly, while CSA records would have been much
 more appropriate here,
 
  
 https://tools.ietf.org/html/draft-crocker-csv-csa-00
 
 that idea went nowhere, in the
 rush to "solve phishing", which of
 course did not happen with SPF/DKIM/...
 
 Anyway, it is quite possible
 that the problem is that Doug's server
 has IPv6 connectivity, and he either needs to
 jump through more hoops...
 or disable IPv6
 in Postfix:
 
    
 inet_protocols = ipv4.
 
 --
 
     Viktor.