Question regarding VRFY

2018-02-27 Thread J Doe 
Hi,

I read in both the Postfix man file (man 5 postconf), and the SMTP RFC (5321), 
that VRFY can be disabled on a site-by-site basis.

I disabled this on my server for port 25 but am wondering if I should leave 
this enabled on my Postfix instance that provides submission (587) ?  I have 
confirmed that by editing main.cf and master.cf it is only available on 
submission and requires SASL authentication before working.

Are there modern MUA’s that authenticated users may use that make use of VRFY 
(perhaps by checking e-mail address validity before sending, while the message 
body is still being composed), or am I better off leaving it disabled 
everywhere ?

Thanks,

- J

Quota status to Postfix in distributed environment

2018-02-27 Thread SAAHIL IFTEKHAR 
Hi

My setup contains Postfix 2.10.1, Dovecot 2.2.10 on RHEL 7.3. The feature I
tried to implement is "quota status to postfix".

The configuration for this feature needs to be done both in dovecot and
postfix. Though more configuration are from dovecot side but error is
coming from postfix side configuration.

I have implemented Quota status to postfix in our setup. I have an imap
server (dovecot) and mail server (postfix) in every node. I am able to send
quota status to postfix and mails are rejected after 100% mail quota is
crossed. This rejection is happening both in across the nodes and within
the nodes.

The problem is if I am sending mails to any node and if any other node's
dovecot is down, mails are not going. For example, I am sending an email
within the system but if some other node's dovecot is down then email
within the system also will not go.

My dovecot version is 2.2.10.
My postfix version is 2.1.10.

*doveconf -n output is below:-*

# 2.2.10: /etc/dovecot/dovecot.conf
# OS: Linux 3.10.0-514.el7.x86_64 x86_64 Red Hat Enterprise Linux Server
release 7.3 (Maipo) xfs
auth_debug = yes
base_dir = /var/run/dovecot/
first_valid_gid = 5000
first_valid_uid = 5000
hostname = CmdHQ
login_greeting = ^^Dovecot ready^^
mail_debug = yes
mail_gid = 6000
mail_location = Maildir:/var/mail/vmail/tcs.mil.in/%n
mail_plugins = " quota"
mail_uid = 6000
mbox_write_locks = fcntl
passdb {
  args = /etc/dovecot/dovecot-ldap.conf
  driver = ldap
}
plugin {
  quota = maildir:User quota
  quota_rule = *:storage=8KB
  quota_rule2 = *:messages=12B
  quota_status_nouser = DUNNO
  quota_status_overquota = 552 5.2.2 Mailbox is over quota / mailbox is full
  quota_status_success = DUNNO
  quota_warning = storage=80%% quota-warning 80 %u
}
postmaster_address = postmas...@tcs.mil.in
service auth {
  unix_listener auth-userdb {
mode = 0600
user = postfix
  }
}
service lmtp {
  unix_listener /var/spool/postfix/private/dovecot-lmtp {
group = postfix
mode = 0600
user = postfix
  }
}
service quota-status {
  client_limit = 1
  executable = quota-status -p postfix
  inet_listener {
port = 54317
  }
}
service quota-warning {
  executable = script /usr/local/bin/quota-warning.sh
  unix_listener quota-warning {
group = postfix
mode = 0666
user = postfix
  }
  user = postfix
}
ssl = required
ssl_ca = 
Feb 22 12:43:24 1CorpHQ postfix/trivial-rewrite[7330]: match_list_match:
transport_maps: no match
Feb 22 12:43:24 1CorpHQ postfix/trivial-rewrite[7330]: match_list_match:
transport_maps: no match
Feb 22 12:43:24 1CorpHQ postfix/trivial-rewrite[7330]: In dict_changed_name
Feb 22 12:43:24 1CorpHQ postfix/trivial-rewrite[7330]:
match_list_match:tcs.mil.in: no match
Feb 22 12:43:24 1CorpHQ postfix/trivial-rewrite[7330]:
match_list_match:tcs.mil.in: no match
Feb 22 12:43:24 1CorpHQ postfix/trivial-rewrite[7330]:
match_list_match:tcs.mil.in: no match
Feb 22 12:43:24 1CorpHQ postfix/trivial-rewrite[7330]:
match_list_match:tcs.mil.in: no match
Feb 22 12:43:24 1CorpHQ postfix/smtpd[7326]: In valid verify sender addr
Feb 22 12:43:24 1CorpHQ postfix/smtpd[7326]: text 250 2.1.0 Ok
Feb 22 12:43:24 1CorpHQ postfix/smtpd[7326]: text RCPT
TO:
Feb 22 12:43:24 1CorpHQ postfix/trivial-rewrite[7330]:
match_list_match:tcs.mil.in: no match
Feb 22 12:43:24 1CorpHQ postfix/trivial-rewrite[7330]:
match_list_match:tcs.mil.in: no match
Feb 22 12:43:24 1CorpHQ postfix/trivial-rewrite[7330]:
match_list_match:tcs.mil.in: no match
Feb 22 12:43:24 1CorpHQ postfix/trivial-rewrite[7330]:
match_list_match:tcs.mil.in: no match
Feb 22 12:43:24 1CorpHQ postfix/smtpd[7326]: In valid verify sender addr
Feb 22 12:43:24 1CorpHQ postfix/smtpd[7326]: match_list_match:
permit_mynetworks: no match
Feb 22 12:43:24 1CorpHQ dovecot: quota-status: Debug: Loading modules from
directory: /usr/lib64/dovecot
Feb 22 12:43:24 1CorpHQ dovecot: quota-status: Debug: Module loaded:
/usr/lib64/dovecot/lib10_quota_plugin.so
Feb 22 12:43:24 1CorpHQ dovecot: auth: Debug: Loading modules from
directory: /usr/lib64/dovecot/auth
Feb 22 12:43:24 1CorpHQ dovecot: auth: Debug: Module loaded:
/usr/lib64/dovecot/auth/libdriver_sqlite.so
Feb 22 12:43:24 1CorpHQ dovecot: auth: Debug: Loading modules from
directory: /usr/lib64/dovecot/auth
Feb 22 12:43:24 1CorpHQ dovecot: auth: Debug: Module loaded:
/usr/lib64/dovecot/auth/libauthdb_ldap.so
Feb 22 12:43:24 1CorpHQ dovecot: auth: Debug: Read auth token secret from
/var/run/dovecot//auth-token-secret.dat
Feb 22 12:43:24 1CorpHQ dovecot: auth: Debug: master in:
USER#0111#011co.1cor...@tcs.mil.in#011service=quota-status
Feb 22 12:43:24 1CorpHQ dovecot: auth: Debug: ldap(co.1cor...@tcs.mil.in):
user search: base=dc=tcs,dc=mil,dc=in scope=subtree
filter=(&(objectClass=person)(uid=co.1corphq))
fields=homeDirectory,uidNumber,gidNumber
Feb 22 12:43:24 1CorpHQ dovecot: auth: Debug: ldap(co.1cor...@tcs.mil.in):
no fields returned by the server
Feb 22 12:43:24 1CorpHQ dovecot: auth: Debug: ldap(co.1cor...@tcs.mil.in):
resul

Re: Question regarding VRFY

2018-02-27 Thread John Fawcett 
On 27/02/18 20:36, J Doe wrote:
> Hi,
>
> I read in both the Postfix man file (man 5 postconf), and the SMTP RFC 
> (5321), that VRFY can be disabled on a site-by-site basis.
>
> I disabled this on my server for port 25 but am wondering if I should leave 
> this enabled on my Postfix instance that provides submission (587) ?  I have 
> confirmed that by editing main.cf and master.cf it is only available on 
> submission and requires SASL authentication before working.
>
> Are there modern MUA’s that authenticated users may use that make use of VRFY 
> (perhaps by checking e-mail address validity before sending, while the 
> message body is still being composed), or am I better off leaving it disabled 
> everywhere ?
>
> Thanks,
>
> - J

I can't think of a compelling reason either to enable VRFY or to disable
it. Disabling it stops people abusing it, but then they can just use
RCPT TO to get the same information in most cases. I disabled it since I
can't see any use for it.

John

Re: Quota status to Postfix in distributed environment

2018-02-27 Thread Noel Jones 
On 2/27/2018 2:06 PM, SAAHIL IFTEKHAR wrote:
> Hi
> 
> My setup contains Postfix 2.10.1, Dovecot 2.2.10 on RHEL 7.3. The
> feature I tried to implement is "quota status to postfix". 
> 
> The configuration for this feature needs to be done both in dovecot
> and postfix. Though more configuration are from dovecot side but
> error is coming from postfix side configuration.
> 
> I have implemented Quota status to postfix in our setup. I have an
> imap server (dovecot) and mail server (postfix) in every node. I am
> able to send quota status to postfix and mails are rejected after
> 100% mail quota is crossed. This rejection is happening both in
> across the nodes and within the nodes.
> 
> The problem is if I am sending mails to any node and if any other
> node's dovecot is down, mails are not going. For example, I am
> sending an email within the system but if some other node's dovecot
> is down then email within the system also will not go.
> 
> My dovecot version is 2.2.10.
> My postfix version is 2.1.10.
> 
> *doveconf -n output is below:-*

... dovecot config irrelevant.

> Here "service quota status" is the concerned section in conf file.
> 
> 
> *Postfix configuration is below:- *
> 
> smtpd_relay_restrictions =
>   check_policy_service inet:201.123.80.9:54317 
> 
>   check_policy_service inet:201.123.80.23:54317 
> 


Nitpick: this should really be in smtpd_recipient_restrictions, not
relay restrictions.

(unneeded debug output stripped)

> Feb 22 12:43:25 1CorpHQ postfix/smtpd[7326]: warning: problem talking to
> server 201.123.80.9:54317 : Connection refused
> Feb 22 12:43:25 1CorpHQ postfix/smtpd[7326]: NOQUEUE: reject: RCPT from
> 1CorpHQ[201.123.80.23]: 451 4.3.5 Server configuration problem; from=<
> cdr.1cor...@tcs.mil.in > 
> to=mailto:co.1cor...@tcs.mil.in>> proto=ESMTP
> helo=<1CorpHQ>

Postfix here does the only reasonable thing: mail is deferred to the
sender to try again later.


Instead of asking every server about quota for every recipient, just
ask the server where the recipient resides.

Something like (untested, but the general idea is sound):
# main.cf
smtpd_restriction_classes =
  quota_server9
  quota_server23

quota_server9 =
   check_policy_service inet:201.123.80.9:54317

quota_server23 =
   check_policy_service inet:201.123.80.23:54317

smtpd_relay_restrictions =
(use what is appropriate for your site, such as:)
   permit_mynetworks
   permit_sasl_authenticated

smtpd_recipient_restrictions =
   check_recipient_access hash:/etc/postfix/check_quota
... other restrictions as appropriate


# /etc/postfix/check_quota
us...@example.com   quota_server9
us...@example.com   quota_server9
us...@example.com   quota_server23
us...@example.com   quota_server23


This example uses a hash: map, but any supported map type can be used.

This example method will scale nicely to a few servers.  If you have
hundreds of servers, the postfix config will become unmanageable and
require a different solution.


Reference:
http://www.postfix.org/RESTRICTION_CLASS_README.html
http://www.postfix.org/SMTPD_POLICY_README.html
http://www.postfix.org/DATABASE_README.html
http://www.postfix.org/documentation.html




  -- Noel Jones

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

ETRN use and Postfix configuration

2018-02-27 Thread J Doe 
Hello,

I read the “Postfix ETRN Howto” [1] as well as man 5 postconf with regards to:

postscreen_discard_ehlo_keywords
smtpd_discard_ehlo_keywords

... and disabled the announcement of ETRN via:

postscreen_discard_ehlo_keywords = ETRN
smtpd_discard_ehlo_keywords = ETRN

I then restarted the server and observed an inbound connection from Gmail:

Feb 27 21:12:19 server postfix/smtpd[2369]: connect from 
mail-oi0-x22f.google.com
Feb 27 21:12:19 server postfix/smtpd[2369]: discarding EHLO keywords: ETRN
Feb 27 21:12:19 server postfix/smtpd[2369]: Trusted TLS connection established 
...
Feb 27 21:12:19 server postfix/smtpd[2369]: discarding EHLO keywords: ETRN

My question is:

** Is the Gmail SMTP server attempting to use ETRN on the first, unencrypted 
SMTP session with my server and then attempting to request it again after 
STARTTLS when the TLS connection is established and this is why it is logging 
that it is discarding ETRN each time or ...

** Is Postfix logging that ETRN is disabled on the first, unencrypted SMTP 
session and then logging this again for the encrypted session (ie: Postfix is 
just logging I disabled this and Google is not attempting to issue ETRN each 
time) ?

Thanks,

- J

Sources:
[1] www.postfix.org/ETRN_README.html

Re: ETRN use and Postfix configuration

2018-02-27 Thread Noel Jones 
On 2/27/2018 8:29 PM, J Doe wrote:
> Hello,
> 
> I read the “Postfix ETRN Howto” [1] as well as man 5 postconf with regards to:
> 
> postscreen_discard_ehlo_keywords
> smtpd_discard_ehlo_keywords
> 
> ... and disabled the announcement of ETRN via:
> 
> postscreen_discard_ehlo_keywords = ETRN
> smtpd_discard_ehlo_keywords = ETRN
> 
> I then restarted the server and observed an inbound connection from Gmail:
> 
> Feb 27 21:12:19 server postfix/smtpd[2369]: connect from 
> mail-oi0-x22f.google.com
> Feb 27 21:12:19 server postfix/smtpd[2369]: discarding EHLO keywords: ETRN
> Feb 27 21:12:19 server postfix/smtpd[2369]: Trusted TLS connection 
> established ...
> Feb 27 21:12:19 server postfix/smtpd[2369]: discarding EHLO keywords: ETRN
> 
> My question is:
> 
> ** Is the Gmail SMTP server attempting to use ETRN on the first, unencrypted 
> SMTP session with my server and then attempting to request it again after 
> STARTTLS when the TLS connection is established and this is why it is logging 
> that it is discarding ETRN each time or ...

Not this.

> 
> ** Is Postfix logging that ETRN is disabled on the first, unencrypted SMTP 
> session and then logging this again for the encrypted session (ie: Postfix is 
> just logging I disabled this and Google is not attempting to issue ETRN each 
> time) ?

Yes, this. The informative message is logged as soon as the client
sends EHLO, and before the client sends any other commands.

Now that you know it's working, you can use the silent_discard
keyword to clean up the logs.



  -- Noel Jones