Re: Sharing a domain with Exchange

2017-05-05 Thread John Anderson
Viktor,

Thanks so much! I will digest and rework! Thanks again!!

Sent from my iPhone

> On May 5, 2017, at 7:23 PM, Viktor Dukhovni  
> wrote:
>
>
>> On May 5, 2017, at 5:21 PM, John Anderson  
>> wrote:
>>
>> My first post to a mailing list, I am sure this is a simple thing that I am 
>> overlooking, but even a two week old case with RHEL and I am not hitting on 
>> the answer. Please help if you can/want.
>>
>> Situation:
>> Single postfix server and an exchange 2013 server. The company is wanting to 
>> keep the same domain across both systems. I am using ldap lookups for 
>> virtual domains, this is working great. Internet bound email is also working 
>> great. I attempted using an ldap transport lookup keying off a group (the 
>> idea is a user not in the group relay to the exchange FE for internal 
>> routing).
>
> The only sane way to share a single virtual domain across two mail stores is
> to use virtual_alias_maps to rewrite envelope recipient addresses from the
> share domain to two distinct domains one per mail store.
>
> Ideally both mail stores support internal names for each recipient:
>
># External form Internal Form
>us...@example.comus...@store1.example.com
>us...@example.comus...@store2.example.com
>
> Each of the mail stores would recognize the internal address
> form as a valid address for the user whose "public" address
> lies in the shared domain namespace.
>
> Exchange supports this easily via multi-valued proxyAddresses:
>
>; A mailbox-enabled user
>mail: us...@example.com
>proxyAddresses: smtp:us...@example.com
>proxyAddresses: smtp:us...@store1.example.com
>mailRoutingAddress: us...@store1.example.com
>
>; A non-mailbox-enabled user
>mail: us...@example.com
>proxyAddresses: smtp:us...@example.com
>proxyAddresses: smtp:us...@store2.example.com
>mailRoutingAddress: us...@store2.example.com
>targetAddress: smtp:us...@store2.example.com
>
> The "mailRoutingAddress" attribute may need to be added
> to the Active Directory schema.  You can use any name that
> works for you, but the idea is that Postfix will query LDAP
> for "proxyAddresses -> mailRoutingAddress" mappings as its
> LDAP-based virtual alias table.
>
> You make the primary domain of Exchange be "store1.example.com"
> (for which it is then fully authoritative).  The users whose
> mail is not stored in Exchange get contact objects that route
> to "us...@store2.example.com".
>
> Your Postfix transport table is then trivial, all the magic is
> in the virtual alias table.
>
> --
>Viktor.
>
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you have received this email in error please notify the system manager 
immediately. Please note that any views or opinions presented in this email are 
solely those of the author and do not necessarily represent those of Chickasaw 
Nation Industries, Inc. and any of its subsidiaries. Recipient should check 
this email and any attachments for the presence of viruses. Chickasaw Nation 
Industries, Inc. and its subsidiaries accept no liability for any damage caused 
by any virus transmitted by this email.


Re: Different LMTP configuration for different clients

2017-05-05 Thread Peter
On 04/05/17 18:13, Angel L. Mateo wrote:
> My problem is that I can't classify by recipient. I should do it by
> client IP. Is this possible in a transport map?

No, instead use smtpd_client_restrictions with check_client_access and a
FILTER result pointing to the correct transport.  See postconf(5) and
access(5) for details.


Peter


Re: Sharing a domain with Exchange

2017-05-05 Thread Viktor Dukhovni

> On May 5, 2017, at 5:21 PM, John Anderson  wrote:
> 
> My first post to a mailing list, I am sure this is a simple thing that I am 
> overlooking, but even a two week old case with RHEL and I am not hitting on 
> the answer. Please help if you can/want.
> 
> Situation:
> Single postfix server and an exchange 2013 server. The company is wanting to 
> keep the same domain across both systems. I am using ldap lookups for virtual 
> domains, this is working great. Internet bound email is also working great. I 
> attempted using an ldap transport lookup keying off a group (the idea is a 
> user not in the group relay to the exchange FE for internal routing). 

The only sane way to share a single virtual domain across two mail stores is
to use virtual_alias_maps to rewrite envelope recipient addresses from the
share domain to two distinct domains one per mail store.

Ideally both mail stores support internal names for each recipient:

# External form Internal Form
us...@example.com   us...@store1.example.com
us...@example.com   us...@store2.example.com

Each of the mail stores would recognize the internal address
form as a valid address for the user whose "public" address
lies in the shared domain namespace.

Exchange supports this easily via multi-valued proxyAddresses:

; A mailbox-enabled user
mail: us...@example.com
proxyAddresses: smtp:us...@example.com
proxyAddresses: smtp:us...@store1.example.com
mailRoutingAddress: us...@store1.example.com

; A non-mailbox-enabled user
mail: us...@example.com
proxyAddresses: smtp:us...@example.com
proxyAddresses: smtp:us...@store2.example.com
mailRoutingAddress: us...@store2.example.com
targetAddress: smtp:us...@store2.example.com

The "mailRoutingAddress" attribute may need to be added
to the Active Directory schema.  You can use any name that
works for you, but the idea is that Postfix will query LDAP
for "proxyAddresses -> mailRoutingAddress" mappings as its
LDAP-based virtual alias table.

You make the primary domain of Exchange be "store1.example.com"
(for which it is then fully authoritative).  The users whose
mail is not stored in Exchange get contact objects that route
to "us...@store2.example.com".

Your Postfix transport table is then trivial, all the magic is
in the virtual alias table.

-- 
Viktor.



Sharing a domain with Exchange

2017-05-05 Thread John Anderson
Greetings,


My first post to a mailing list, I am sure this is a simple thing that I am 
overlooking, but even a two week old case with RHEL and I am not hitting on the 
answer. Please help if you can/want.


Situation:

Single postfix server and an exchange 2013 server. The company is wanting to 
keep the same domain across both systems. I am using ldap lookups for virtual 
domains, this is working great. Internet bound email is also working great. I 
attempted using an ldap transport lookup keying off a group (the idea is a user 
not in the group relay to the exchange FE for internal routing). Output of 
telnet gives me:

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 nmnpfx01.chickasaw.com ESMTP Postfix
helo localhost
250 nmnpfx01.chickasaw.com
mail from:
250 2.1.0 Ok
rcpt to:
450 4.1.1 : Recipient address rejected: User 
unknown in virtual mailbox table
quit

### postconf -n ###
[johnanderson@nmnpfx01 ~]$ postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd 
$daemon_directory/$process_name $process_id & sleep 5
fallback_transport = smtp:[relay.chickasaw.com]:25
html_directory = no
inet_interfaces = all
inet_protocols = ipv4
local_recipient_maps =
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
mydestination = $myhostname, localhost.$mydomain, localhost
myhostname = nmnpfx01.chickasaw.com
mynetworks = all
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.10.1/README_FILES
relay_domains = chickasaw.com
relayhost = [relay.chickasaw.com]
sample_directory = /usr/share/doc/postfix-2.10.1/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
soft_bounce = yes
transport_maps = ldap:/etc/postfix/ldap_transport.cf
unknown_local_recipient_reject_code = 550
virtual_gid_maps = static:1001
virtual_mailbox_base = /home/vmail/
virtual_mailbox_domains = chickasaw.com
virtual_mailbox_maps = ldap:/etc/postfix/ldap-users.cf
virtual_uid_maps = static:1001

### ldap-users.cf ###
## LDAP LOOKUP FILE
## CREATED 4-10-2017
...omitted
result_format = %d/%u/Maildir/
...omitted
###

### ldap_transport ###
## LDAP Remote Exchange LOOKUP FILE
## CREATED 4-10-2017
...omitted
result_format =%s relay:[relay.chickasaw.com]:25
...omitted

###
postmap here works if the user is NOT a member of the above group.
john.ander...@chickasaw.com relay:[relay.chickasaw.com]:25




What we want is for co-existence with exchange, i just dont know what i am 
missing. I have searched for similar situations and havent found one that had 
enough detail to help me see what I am missing. Any pointers, tips, or help 
will be greatly appreciated!




Thanks in advance!



John Anderson, Security and Server Engineer
Chickasaw Nation Industries
Direct (405) 253-8253 john.ander...@chickasaw.com
Connect with us: www.chickasaw.com | 
Facebook | 
LinkedIn

This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you have received this email in error please notify the system manager 
immediately. Please note that any views or opinions presented in this email are 
solely those of the author and do not necessarily represent those of Chickasaw 
Nation Industries, Inc. and any of its subsidiaries. Recipient should check 
this email and any attachments for the presence of viruses. Chickasaw Nation 
Industries, Inc. and its subsidiaries accept no liability for any damage caused 
by any virus transmitted by this email.


Re: Very strange DNS Problem; MX not found

2017-05-05 Thread Jörg Backschues

On 05.05.2017 at 14:48h Georg Sotsas wrote:


The mails sent to .x...@guilford.com 
remain in the queue with this error:
Host or domain name not found. Name service error for name=guilford.com
 type=MX: Host not found, try again


Just working here:

user@host:~$ postconf mail_version
mail_version = 2.11.0

May  5 22:33:14 mx0.backschues.net postfix/smtp[3794]: 3wKNrR6HSqz3Q: 
to=, 
relay=smtp.notes.na.collabserv.com[158.85.210.111]:25, delay=2.6, 
delays=0.02/0.01/2/0.59, dsn=2.0.0, status=sent (250 OK 
<17050520-8244---DBF7FB26>)


--
Regards Jörg



Re: Very strange DNS Problem; MX not found

2017-05-05 Thread Wietse Venema
Viktor Dukhovni:
> 
> > On May 5, 2017, at 11:31 AM, Wietse Venema  wrote:
> > 
> > I would not exclude the possibility that the OP is using a greedy
> > resolver that tries to look up A records when asked for MX, and
> > then reports an MX lookup problem when it was actually the A query
> > that failed because of the large response to that query.
> 
> Perhaps, but I would not have expected this.  The additional records
> in this case are not "in bailiwick", and would be ignored by any
> downstream recursive resolver in a chain of resolvers, so including
> such additional records would be often pointless.
> 
> Also, while there are many A records, there are not so many that I
> would expect UDP issues.  The entire A RRset fits in 505 bytes, with
> EDNS0:

I was seeing ';; Truncated, retrying in TCP mode' with the host(1)
and dig(1) command-line utilities on my aging server.

Still wondering, though, whether some resolver isn't returning
failure because some unsolicited lookup didn't work out.

There is some prior art for this. Some SunOS versions used to have
a gethostbyaddr() implementation that would return failure if the
forward lookup result did not match, as a defense against spoofing. 

Wietse


Re: Very strange DNS Problem; MX not found

2017-05-05 Thread Viktor Dukhovni

> On May 5, 2017, at 11:31 AM, Wietse Venema  wrote:
> 
> I would not exclude the possibility that the OP is using a greedy
> resolver that tries to look up A records when asked for MX, and
> then reports an MX lookup problem when it was actually the A query
> that failed because of the large response to that query.

Perhaps, but I would not have expected this.  The additional records
in this case are not "in bailiwick", and would be ignored by any
downstream recursive resolver in a chain of resolvers, so including
such additional records would be often pointless.

Also, while there are many A records, there are not so many that I
would expect UDP issues.  The entire A RRset fits in 505 bytes, with
EDNS0:

$ dig +novc +nosearch +dnssec +noans +nocl +nottl +nosplit +norecur -t a 
smtp.notes.na.collabserv.com @169.50.133.132
...
;; MSG SIZE  rcvd: 505

Or without EDNS0 in 494 bytes, however, without EDNS0 I do see a truncated 
response
from the authoritative server and dig then performs a TCP retry (which works).

$ dig +noedns +nosearch +nodnssec +noans +nocl +nottl +nosplit +norecur -t a 
smtp.notes.na.collabserv.com @169.50.133.132
;; Truncated, retrying in TCP mode.
...
;; MSG SIZE  rcvd: 494

If the OP's resolver is having trouble with this, it is a rather poorly
implemented resolver, no EDNS0 support, chokes on TCP retries, fails when
it can't obtain additional records, that's quite a collection of issues.

   http://dilbert.com/strip/1995-06-24

-- 
Viktor.



Re: Very strange DNS Problem; MX not found

2017-05-05 Thread Wietse Venema
Viktor Dukhovni:
> 
> > On May 5, 2017, at 8:48 AM, Georg Sotsas  wrote:
> > 
> > The mails sent to .x...@guilford.com remain in the queue with this 
> > error: 
> > Host or domain name not found. Name service error for name=guilford.com 
> > type=MX: Host not found, try again
> 
> This sounds like an error with *outbound* mail, please show the unredacted
> log entries (from the mail log, not "mailq" output), not just the error
> message.  You can obfuscate email addresses, while otherwise leaving the
> error message intact.
> 
> [ Wietse, this error was not related to the largish IP address count of
>   the MX   host, it was the actual MX RRset lookup that servfailed.

There is only one MX record for guilford.com, an that reply with
authority and additional records takes only 139 bytes.

I would not exclude the possibility that the OP is using a greedy
resolver that tries to look up A records when asked for MX, and
then reports an MX lookup problem when it was actually the A query
that failed because of the large response to that query.

Wietse


Re: Message-ID: / In-Reply-To: ID continuity through mail servers

2017-05-05 Thread Viktor Dukhovni

> On May 5, 2017, at 8:16 AM, Richard Sass  wrote:
> 
> For a simple example using Postfix and our application as the client sending
> will the “Message-ID:” outbound from my application message be retained as
> it passes through Postfix, unaltered arriving at the destination mailbox on
> the same Postfix server?

Yes.  Altering Message-ID headers breaks "threading" in mail clients and
makes message tracking more difficult.  Postfix does not alter message ids,
nor should any other MTA.

> Will a reply from the destination mailbox using MS Outlook contain the
> unaltered original message ID in the “In-Reply-To:” field?

Likely so.  That header is typically supported, and contains just
the message id of the original message.

Things are a bit more complicated with the "References" header, 
after sufficiently many messages back and forth the "References:"
header may get too long to fit in one SMTP maximum length (998
bytes) line, and "folding" may "corrupt" some of the ids in the
"References:" header.  It would be prudent of MUAs to keep only
a small number of the most recent "References:" elements, or fold
the header properly, but I don't know whether any/which MUAs do
that.

-- 
Viktor.



Re: TLS security rules - perfect setup and issue with anonymous cipher

2017-05-05 Thread Viktor Dukhovni

> On May 5, 2017, at 7:07 AM, Zalezny Niezalezny  
> wrote:
> 
> I have a security question. My Postfix 2.10.1

Postfix 3.2, 3.1, 3.0 and 2.11 are all available.

   http://cdn.postfix.johnriley.me/mirrors/postfix-release/index.html

while Postfix 2.10 is no longer supported.  If you want to keep up with
best practice, upgrade.


> Server TLS configuration looks like this at the moment.
> 
> #TLS Server configuration
> smtpd_tls_security_level = may
> smtpd_tls_cert_file = /etc/postfix/ssl/2017.cer
> smtpd_tls_key_file = /etc/postfix/ssl/2017.key

You should have, if not already default values with your 2.10.1
(with some vendor patch backports?) Postfix release:

smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_ciphers = medium
smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_ciphers = medium

smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_ciphers = medium
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3
smtp_tls_mandatory_ciphers = medium

Some people add:

smtp_tls_exclude_ciphers = MD5, aDSS, kECDH, kDH, SEED, IDEA, RC2, RC5

to trim obsolete baggage from the list of ciphers offered by the SMTP client
to remote servers.  This can actually improve interoperability in some edge 
cases,
and should not cause any loss of ability to negotiate TLS with remote systems.
That said, this is not required.  You can, if you wish, include RC4 in that 
list,
but it is not as bad as it is made out to be, and would only be negotiated when
nothing else better is available, almost all systems prefer AES these days, when
available.

> One time per month some external company doing security scan on all Postfix 
> instances. Last time there was a big discussion about anonymous Ciphers. 
> 
> Do I need to disable them ?

No. See https://tools.ietf.org/html/rfc7672#section-8.2

> What else should I configured for public server?

Not much.  TLS in SMTP is opportunistic and unauthenticated in the vast majority
of cases.  Therefore, liberal settings, considered "insecure" in some quarters 
are
entirely appropriate.

> Maybe somebody will be so kind and paste here some perfect, working TLS 
> configuration for public server?

There's no such thing as "perfect", but speaking of "perfect" see

   http://www.postfix.org/FORWARD_SECRECY_README.html#quick-start

with Postfix >= 3.2 leave "smtpd_tls_eecdh_grade = auto" in place, that's better
than choosing a fixed "curve" (Diffie Hellman group of the "elliptic curve" 
kind).

Also make sure your OpenSSL runtime is up to date.  OpenSSL 1.0.1 and earlier 
are
no longer supported, so use a system with 1.0.2 or 1.1.0 patched up to date.

-- 
Viktor.



Re: Very strange DNS Problem; MX not found

2017-05-05 Thread Viktor Dukhovni

> On May 5, 2017, at 8:48 AM, Georg Sotsas  wrote:
> 
> The mails sent to .x...@guilford.com remain in the queue with this error: 
> Host or domain name not found. Name service error for name=guilford.com 
> type=MX: Host not found, try again

This sounds like an error with *outbound* mail, please show the unredacted
log entries (from the mail log, not "mailq" output), not just the error
message.  You can obfuscate email addresses, while otherwise leaving the
error message intact.

[ Wietse, this error was not related to the largish IP address count of
  the MX   host, it was the actual MX RRset lookup that servfailed.
  Perhaps something stale in the OP's DNS cache, or chroot issues.

 src/dns/dns_lookup.c(481): 
vstring_sprintf(why, "Host or domain name not found. "
"Name service error for name=%s type=%s: %s",
name, dns_strtype(type), dns_strerror(h_errno));
]

> The DNS resolution is working fine (and all the other Emails leave the mail 
> relay without any problems):
> https://gist.github.com/anonymous/a282b54e74c3cbbbe31c2b0391fc0c97

Why pollute github with junk unrelated to software development?  And make
readers of the list jump through hoops chasing link.  Please post relevant
data with your message.

> I've tried to run postfix (smtp/submission) with and without chroot.

These handle *inbound* mail, assuming you're referring to "smtp inet ... smtpd",
and "submission inet ... smtpd".  The relevant service for outbound email is
"smtp unix ... smtp".

> But finally I have no clue on what is going wrong with this domain.

Perhaps a chroot issue anyway.

-- 
Viktor.



Re: Very strange DNS Problem; MX not found

2017-05-05 Thread Wietse Venema
Georg Sotsas:
> Hello,
> we are encountering a very strange problem on our Postfix (2.11.0-1ubuntu1)
> Mail Relay.
> 
> The mails sent to .x...@guilford.com remain in the queue with this
> error:
> Host or domain name not found. Name service error for name=guilford.com
> type=MX: Host not found, try again

Looks like a local problem. it resolves fine here.

> The DNS resolution is working fine (and all the other Emails leave the mail
> relay without any problems):
> https://gist.github.com/anonymous/a282b54e74c3cbbbe31c2b0391fc0c97

Did you notice smtp.notes.na.collabserv.com resolves to 28 address
records? That requires either using TCP or using a large UDP datagram.

Perhaps you have a DNS resolver (local or up-stream) that can't
handle that, or some 'security' system that blocks such queries.

Wietse


Re: Message-ID: / In-Reply-To: ID continuity through mail servers

2017-05-05 Thread Wietse Venema
I suggest that you build on conventions that are valid across
multiple mail software implementations, not just Postfix.

Of particular interest are In-Reply-To: and References:.

Search the web for "site:ietf.org references in-reply-to", and read
the documents that come up, in particular RFC 2822 and RFC 4021.

Wietse


Advice on spam & virus checking (again)

2017-05-05 Thread Peter West
I’m currently running postfix, dovecot and mailman on a Ubuntu 16.04 server, to 
which a number of domains resolve. There is a mailman list associated with one 
of the domains. The volumes are very low. After some adventures I got 
spamassassin running, but my attempts to run clamav, either through amavisd-new 
or clamsmtp have caused me problems.  Unfortunately, it was a while ago, and I 
did not make notes of the failures.

Essentially then, I would like recommendations on the best approach(es) to 
this, and the best associated documentation or recipes.  I have found a 
bewildering variety of recipes for setting such a system up, some of which 
contradict one another.  Even mailman comes with two different setups.

I have been reading the current related thread, and may simply be asking for a 
repetition, but setting these things up seems to be very delicate business.

postfinger:

postfinger - postfix configuration on Tue Apr 25 20:06:59 AEST 2017
version: 1.30

--Packaging information--
looks like this postfix comes from deb package: postfix-3.1.0-3

--main.cf non-default parameters--
alias_maps = hash:/etc/aliases hash:/var/lib/mailman/data/aliases
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
delay_warning_time = 4h
home_mailbox = Maildir/
inet_protocols = ipv4
mailbox_command = /usr/lib/dovecot/deliver -c 
/etc/dovecot/conf.d/01-dovecot-postfix.conf -m "${EXTENSION}"
mailbox_size_limit = 0
message_size_limit = 5120
mydestination = localhost, localhost.localdomain, e.id.au, oz-e.id.au, 
y.org.au, top.com.au, p.id.au
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
recipient_delimiter = +
smtp_bind_address = 99.99.99.99
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
smtpd_recipient_restrictions = reject_unknown_sender_domain 
reject_unknown_recipient_domain reject_unauth_pipelining permit_mynetworks 
permit_sasl_authenticated reject_unauth_destination
smtpd_relay_restrictions = reject_unknown_sender_domain 
reject_unknown_recipient_domain reject_unauth_pipelining permit_mynetworks 
permit_sasl_authenticated reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_path = private/dovecot-auth
smtpd_sasl_type = dovecot
smtpd_sender_restrictions = reject_unknown_sender_domain
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/letsencrypt/live/e.id.au/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/e.id.au/privkey.pem
smtpd_tls_mandatory_protocols = !SSLv3, !SSLv2
smtpd_tls_received_header = yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
virtual_alias_domains = lists.y.org.au
virtual_alias_maps = hash:/etc/postfix/virtual, 
hash:/var/lib/mailman/data/virtual-mailman

--master.cf--
smtp   inet  n   -   y   -   -   smtpd
  -o content_filter=spamassassin
submission inet  n   -   y   -   -   smtpd
smtps  inet  n   -   y   -   -   smtpd
pickup fifo  n   -   y   60  1   pickup
cleanupunix  n   -   y   -   0   cleanup
qmgr  fifo  n   -   n   300 1   qmgr
tlsmgr unix  -   -   y   1000?   1   tlsmgr
rewriteunix  -   -   y   -   -   trivial-rewrite
bounce unix  -   -   y   -   0   bounce
defer  unix  -   -   y   -   0   bounce
trace  unix  -   -   y   -   0   bounce
verify unix  -   -   y   -   1   verify
flush  unix  n   -   y   1000?   0   flush
proxymap  unix  -   -   n   -   -   proxymap
proxywrite unix -   -   n   -   1   proxymap
smtp   unix  -   -   y   -   -   smtp
relay  unix  -   -   y   -   -   smtp
-o smtp_fallback_relay=
showq  unix  n   -   y   -   -   showq
error  unix  -   -   y   -   -   error
retry  unix  -   -   y   -   -   error
discardunix  -   -   y   -   -   discard
local unix  -   n   n   -   -   local
virtual   unix  -   n   n   -   -   virtual
lmtp   unix  -   -   y   -   -   lmtp
anvil  unix  -   -   y   -   1   anvil
scache unix  -   -   y   -   1   scache
maildrop  unix  -   n   n   -   -   pipe
  flags=DRhu user=vmail argv=/usr/bin/maildrop -d ${recipient}
uucp  unix  -   n   n   -   -   pipe
  flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
bsmtp unix  -   n   n   -   -   pipe
  flags=Fq. user=bsmtp argv=/usr/lib/bsmtp/bsmtp -t$nexthop -f$sender 

Very strange DNS Problem; MX not found

2017-05-05 Thread Georg Sotsas
Hello,
we are encountering a very strange problem on our Postfix (2.11.0-1ubuntu1)
Mail Relay.

The mails sent to .x...@guilford.com remain in the queue with this
error:
Host or domain name not found. Name service error for name=guilford.com
type=MX: Host not found, try again

The DNS resolution is working fine (and all the other Emails leave the mail
relay without any problems):
https://gist.github.com/anonymous/a282b54e74c3cbbbe31c2b0391fc0c97

I've tried to run postfix (smtp/submission) with and without chroot.

But finally I have no clue on what is going wrong with this domain.

Some help is very welcome-
Thanks in advance


Message-ID: / In-Reply-To: ID continuity through mail servers

2017-05-05 Thread Richard Sass
We have a project to write an automated email client which is required to
link reply messages sent back in response to its original message, what is
the best method to provide this linkage? I am using Postfix (2.11) as my
test bed.

For a simple example using Postfix and our application as the client sending
will the “Message-ID:” outbound from my application message be retained as
it passes through Postfix, unaltered arriving at the destination mailbox on
the same Postfix server?

Will a reply from the Destination mailbox using MS Outlook contain the
unaltered original message ID in the “In-Reply-To:” field?

Is there a mail server standard around Message-ID: / In-Reply-To: formatting
that would support using Message-ID: and In-Reply-To: to form the original
-> reply linkage?

We have read many articles about other mail servers which alter the
Message-ID: field outbound to mask the client identity somewhat (not reveal
internal host names for example).

Is there a list somewhere which talks about the Message-ID: integrity
between Postfix and various platforms?

Our end goal is to ensure that the originating mailbox gets a response that
it can marry up to the reply in the event that more than one message has
been sent to the destination and one or more replies received from that
client.




TLS security rules - perfect setup and issue with anonymous cipher

2017-05-05 Thread Zalezny Niezalezny
Hi,

first of all I would like to say "thank You" for the answers on my previous
questions. I read all of them, they were helpful but I missed to say "BIG
THANKS!"


I have a security question. My Postfix 2.10.1 Server TLS configuration
looks like this at the moment.


#TLS Server configuration
smtpd_tls_security_level = may
smtpd_tls_cert_file = /etc/postfix/ssl/2017.cer
smtpd_tls_key_file = /etc/postfix/ssl/2017.key


One time per month some external company doing security scan on all Postfix
instances. Last time there was a big discussion about anonymous Ciphers.

Do I need to disable them ?

What else should I configured for public server ?
Maybe somebody will be so kind and paste here some perfect, working TLS
configuration for public server ?



Cheers

Zalezny