Re: Implementation of compression technology

[Patrick Ben Koetter]

* Ashok Kumar J :
> I want to implement the compression technology in postfix mail server. so
> that the mails which are all sending from the mail client will be the plain
> text and it should be compressed in the postfix mail server automatically.
> then it will send to the another mail server. there all the mails are
> decompressed in their mail server  and send to the reciever(plain text).
> this will not be noticed to the end users.  how i can implement it.
> 
> *simply speaking,* i want to reduce the size of the message and attachments
> by doing compression. so that it reduce the transfer rate of bytes in the
> data channel.

Don't change Postfix. Write a MILTER that does that.

p@rick

-- 
All technical questions asked privately will be automatically answered on the
list and archived for public access unless privacy is explicitely required and
justified.

saslfinger (debugging SMTP AUTH):

Re: Implementation of compression technology

[Ralf Hildebrandt]

* Patrick Ben Koetter :
> * Ashok Kumar J :
> > I want to implement the compression technology in postfix mail server. so
> > that the mails which are all sending from the mail client will be the plain
> > text and it should be compressed in the postfix mail server automatically.
> > then it will send to the another mail server. there all the mails are
> > decompressed in their mail server  and send to the reciever(plain text).
> > this will not be noticed to the end users.  how i can implement it.
> > 
> > *simply speaking,* i want to reduce the size of the message and attachments
> > by doing compression. so that it reduce the transfer rate of bytes in the
> > data channel.
> 
> Don't change Postfix. Write a MILTER that does that.

Personally, I'd go for mandatory TLS between the two machines with no encryption
(but compression) - I guess Victor will correct me, but I think
that should work.

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de

Re: Implementation of compression technology

[Ashok Kumar J]

Hi Ralf Hildebrandt,

  ok i try to implement. thanks a lot.

On Mon, Jan 9, 2012 at 1:33 PM, Ralf Hildebrandt <
ralf.hildebra...@charite.de> wrote:

> * Patrick Ben Koetter :
> > * Ashok Kumar J :
> > > I want to implement the compression technology in postfix mail server.
> so
> > > that the mails which are all sending from the mail client will be the
> plain
> > > text and it should be compressed in the postfix mail server
> automatically.
> > > then it will send to the another mail server. there all the mails are
> > > decompressed in their mail server  and send to the reciever(plain
> text).
> > > this will not be noticed to the end users.  how i can implement it.
> > >
> > > *simply speaking,* i want to reduce the size of the message and
> attachments
> > > by doing compression. so that it reduce the transfer rate of bytes in
> the
> > > data channel.
> >
> > Don't change Postfix. Write a MILTER that does that.
>
> Personally, I'd go for mandatory TLS between the two machines with no
> encryption
> (but compression) - I guess Victor will correct me, but I think
> that should work.
>
> --
> Ralf Hildebrandt
>  Geschäftsbereich IT | Abteilung Netzwerk
>  Charité - Universitätsmedizin Berlin
>  Campus Benjamin Franklin
>  Hindenburgdamm 30 | D-12203 Berlin
>  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
>  ralf.hildebra...@charite.de | http://www.charite.de
>
>


-- 
with regards

Ashok Kumar J

Re: Implementation of compression technology

[Robert Schetterer]

Am 09.01.2012 09:39, schrieb Ashok Kumar J:
> Hi Ralf Hildebrandt,
> 
>   ok i try to implement. thanks a lot.
> 
> On Mon, Jan 9, 2012 at 1:33 PM, Ralf Hildebrandt
> mailto:ralf.hildebra...@charite.de>> wrote:
> 
> * Patrick Ben Koetter  >:
> > * Ashok Kumar J  >:
> > > I want to implement the compression technology in postfix mail
> server. so
> > > that the mails which are all sending from the mail client will
> be the plain
> > > text and it should be compressed in the postfix mail server
> automatically.
> > > then it will send to the another mail server. there all the
> mails are
> > > decompressed in their mail server  and send to the
> reciever(plain text).
> > > this will not be noticed to the end users.  how i can implement it.
> > >
> > > *simply speaking,* i want to reduce the size of the message and
> attachments
> > > by doing compression. so that it reduce the transfer rate of
> bytes in the
> > > data channel.
> >
> > Don't change Postfix. Write a MILTER that does that.
> 
> Personally, I'd go for mandatory TLS between the two machines with
> no encryption
> (but compression) - I guess Victor will correct me, but I think
> that should work.
> 
> --
> Ralf Hildebrandt
>  Geschäftsbereich IT | Abteilung Netzwerk
>  Charité - Universitätsmedizin Berlin
>  Campus Benjamin Franklin
>  Hindenburgdamm 30 | D-12203 Berlin
>  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
>  ralf.hildebra...@charite.de  |
> http://www.charite.de
> 
> 
> 
> 
> -- 
> with regards
> 
> Ashok Kumar J
> 

Just as an idea for test , try using openvpn with lzo compression
between 2 servers may be more easy to implement, no idea if this would
fit and work like you want it

-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

RE: Implementation of compression technology

[Terry Gilsenan]

>
>From: owner-postfix-us...@postfix.org [owner-postfix-us...@postfix.org] On 
>Behalf Of Ashok Kumar J [ashok.jagathe...@gmail.com]
>Sent: Monday, 9 January 2012 5:55 PM
>To: postfix-users@postfix.org
>Subject: Re: Implementation of compression technology
>
>Hi Ralf.Hildebrandt,
>
>
>I want to implement the compression technology in postfix mail server. so that 
>the mails which are all sending from the mail client will be the plain text 
>and it should be compressed in >the postfix mail server automatically. then it 
>will send to the another mail server. there all the mails are decompressed in 
>their mail server  and send to the reciever(plain text). this will >not be 
>noticed to the end users.  how i can implement it.
>
>simply speaking, i want to reduce the size of the message and attachments by 
>doing compression. so that it reduce the transfer rate of bytes in the data 
>channel.

Hi,

If you control both ends, you could use SSH tunnel or OpenVPN tunnel with 
compression.

I do this and it works fine.

Regards,
T

On Mon, Jan 9, 2012 at 1:14 PM, Ralf Hildebrandt 
mailto:ralf.hildebra...@charite.de>> wrote:
* Ashok Kumar J mailto:ashok.jagathe...@gmail.com>>:
> Hi ,
>
>  I would like to know about any compression technology implemented and used
> in the postfix mail queue.

What should be compressed?
The queue-files on disk?

What problem are you trying to solve?

--
Ralf Hildebrandt
 Geschäftsbereich IT | Abteilung Netzwerk
 Charité - Universitätsmedizin Berlin
 Campus Benjamin Franklin
 Hindenburgdamm 30 | D-12203 Berlin
 Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
 ralf.hildebrandt@chariteNOTE: URL removed for security purposes - contact 
terry.gilse...@interoil.com for support. 
arite.de




--
with regards

Ashok Kumar J

Re: strange log issue

[Barbara M.]

On Sun, 8 Jan 2012, Jim Seymour wrote:


On Sun, 8 Jan 2012 19:41:07 +0100
Ralf Hildebrandt  wrote:

[snip]


"delay=0," changed into "delay=0.04, delays=0.01/0.01/0/0.02,"

Did you update pflogsumm as well?


Yup.  You need Pflogsumm-1.1.1, at least, looks like.  1.1.3 has been
released for nearly two years.


Fetching 1.1.3 seems solve the "problem" ;-)
I suppose same problem for other analisys tools ;-)

Thanks to all for support.

Regards, B.

Re: outbound postfix for customers

[lst_hoe02]

Zitat von polloxx :


Dear list,

We want to setup a outbound postfix server in our datacenter dedicated
to our customers.
We want separate logs, separate spool directories, possibility to set
mail quota per customer,
Didicated IP addresses per customer.

Do you guys have experience with this kind of setup?

I was thinking of using multiple instances for each customer and using
policyd for quota.

Idea's are very welcome.


Maybe you better use some form of light weight hypervisor like  
openvz/paralles with dedicated container with postfix included per  
customer because you don't share anything anyway...


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Implementation of compression technology

[Stan Hoeppner]

On 1/9/2012 2:45 AM, Robert Schetterer wrote:

> Just as an idea for test , try using openvpn with lzo compression
> between 2 servers may be more easy to implement, no idea if this would
> fit and work like you want it

If the data pipe in question is site-to-site, i.e. a private link, not
internet, I'd implement the compression at the edge device of both
sites.  This way you compress ALL traffic, not just SMTP.

-- 
Stan

Re: outbound postfix for customers

[Wietse Venema]

polloxx:
> Dear list,
> 
> We want to setup a outbound postfix server in our datacenter dedicated
> to our customers.
> We want separate logs, separate spool directories, possibility to set
> mail quota per customer,
> Didicated IP addresses per customer.
> 
> Do you guys have experience with this kind of setup?

I have experience only on a small scale, i.e. with a test machine
that runs multiple Postfix instances on top of the same OS instance.
Each has its own IP address, queue and configuration files, and
logging prefix (the volume is small enough that separate logfiles
would not make things easier).

> I was thinking of using multiple instances for each customer and using
> policyd for quota.

I think that running Postfix is the easiest part. The work is with
integrating all the management stuff, so that you can run Postfix
N times, without having to work N times harder.

Wietse

> Idea's are very welcome.
> 
> p.
> 

Postfix as a Smart Host for Exchange 2010 with TLS

[Ben Curtis]

Hi all,

I've been scouring the internet trying to find someone who's done this
before, and am at a loss.

I've got Postfix set up as a Smart Host for sending SMTP email from
Exchange 2010 (Small Business Server 2011). My problem is that I can't
get TLS to work. The error message I get back in Exchange is:

[451 4.4.0 Primary target IP address responded with: "454 4.7.5
Certificate validation failure." Attempted failover to alternate host,
but that did not succeed. Either there are no alternate hosts, or
delivery failed to all alternate hosts.]

Postfix doesn't seem to be reporting any errors. I am using
self-signed certs on both the Exchange server and the Postfix server,
and have added both signed-cert.crt and ca.crt to the trusted
certificate store in Exchange.

Below are key areas of main.cf:

# SASL
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = no
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain =

# TLS parameters
smtp_tls_security_level = may
smtpd_tls_security_level = may
smtp_tls_note_starttls_offer = yes
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom
smtpd_tls_cert_file = /etc/postfix/certs/signed-cert.crt
smtpd_tls_key_file = /etc/postfix/certs/cert.key
smtp_tls_CAfile = /etc/postfix/certs/ca.crt

Any thoughts? Anything else I can post to aid in debug?

Thanks,
Ben

Re: Postfix as a Smart Host for Exchange 2010 with TLS

[Robert Schetterer]

Am 09.01.2012 17:19, schrieb Ben Curtis:
> Hi all,
> 
> I've been scouring the internet trying to find someone who's done this
> before, and am at a loss.
> 
> I've got Postfix set up as a Smart Host for sending SMTP email from
> Exchange 2010 (Small Business Server 2011). My problem is that I can't
> get TLS to work. The error message I get back in Exchange is:
> 
> [451 4.4.0 Primary target IP address responded with: "454 4.7.5
> Certificate validation failure." Attempted failover to alternate host,
> but that did not succeed. Either there are no alternate hosts, or
> delivery failed to all alternate hosts.]
> 
> Postfix doesn't seem to be reporting any errors. I am using
> self-signed certs on both the Exchange server and the Postfix server,
> and have added both signed-cert.crt and ca.crt to the trusted
> certificate store in Exchange.
> 
> Below are key areas of main.cf:
> 
> # SASL
> smtpd_sasl_auth_enable = yes
> broken_sasl_auth_clients = no
> smtpd_sasl_security_options = noanonymous
> smtpd_sasl_local_domain =
> 
> # TLS parameters
> smtp_tls_security_level = may
> smtpd_tls_security_level = may
> smtp_tls_note_starttls_offer = yes
> smtpd_tls_loglevel = 1
> smtpd_tls_received_header = yes
> smtpd_tls_session_cache_timeout = 3600s
> tls_random_source = dev:/dev/urandom
> smtpd_tls_cert_file = /etc/postfix/certs/signed-cert.crt
> smtpd_tls_key_file = /etc/postfix/certs/cert.key
> smtp_tls_CAfile = /etc/postfix/certs/ca.crt
> 
> Any thoughts? Anything else I can post to aid in debug?
> 
> Thanks,
> Ben

Hi Ben, all i can say that i have
Exchange 2003 Servers that using submission port with tls
for relay at postfix, so if it is no microsoft magic feature or bug
my bet would go to some exchange config problem, i see no postfix
problem on your config by fast overflow, so consult technet/ exchange
logs etc for find more

hm perhaps take the default for
smtp_tls_note_starttls_offer (default: no)
but i guess this isnt the problem

anyway perhaps post the whole postfix config
and/or existing log entries ( if exist )
-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

Re: Postfix as a Smart Host for Exchange 2010 with TLS

[Noel Jones]

On 1/9/2012 10:19 AM, Ben Curtis wrote:
> Hi all,
> 
> I've been scouring the internet trying to find someone who's done this
> before, and am at a loss.
> 
> I've got Postfix set up as a Smart Host for sending SMTP email from
> Exchange 2010 (Small Business Server 2011). My problem is that I can't
> get TLS to work. The error message I get back in Exchange is:
> 
> [451 4.4.0 Primary target IP address responded with: "454 4.7.5
> Certificate validation failure." Attempted failover to alternate host,
> but that did not succeed. Either there are no alternate hosts, or
> delivery failed to all alternate hosts.]
> 

Test postfix TLS with openssl to make sure postfix is working correctly.

For port 25 (or 587) with STARTTLS
# openssl s_client -connect example.com:25 -starttls smtp

Or if you've enabled master.cf port 465 TLS wrappermode (sometimes
mistakenly referred to as SSL in mail client software):
# openssl s_client -connect example.com:465

Openssl will print a couple pages of garbage-looking handshake info
that ends with postfix's 250 greeting.

At that point you should be able to type in "EHLO myname" and get a
response from postfix.  If you get that far, postfix TLS is working
correctly.

If postfix checks out OK, the problem is with the Exchange
configuration.

Maybe Exchange needs to import the private root CA you used to
generate your certificates?  Maybe Exchange is trying to use
wrappermode on a port configured for STARTTLS (or vice versa)?


> 
> Below are key areas of main.cf:

If you need more help with postfix, show "postconf -n" output and
relevant log entries.




  -- Noel Jones

Re: Implementation of compression technology

[Viktor Dukhovni]

On Mon, Jan 09, 2012 at 09:03:23AM +0100, Ralf Hildebrandt wrote:

> Personally, I'd go for mandatory TLS between the two machines with no 
> encryption
> (but compression) - I guess Victor will correct me, but I think
> that should work.

That would be fine provided the OpenSSL libraries on both sides
are built with zlib support. The bandwidth overhead of encryption
and integrity is rather low, and configuring eNULL ciphers is a
pain, so I'd just enable TLS (opportunistic is sufficient) and
compression will automatically kick in when both sides support it.

One should however avoid overly large certificates that can add a
lot of extra data to small messages (which are still the norm).

If TLS is enabled selectively just between two systems (not
opportunistically to all destinations), then if both systems
are Postfix, and the security level is "encrypt" or "may", no
bloated certificates will be exchanged.

-- 
Viktor.

Re: Ok. I'm finding a small issue on my server.

[Jeroen Geilman]

On 2012-01-08 15:16, Bjørn Ruberg wrote:

On 01/08/2012 08:19 AM, Peter wrote:

On 08/01/12 20:00, Bjørn Ruberg wrote:

On 01/08/2012 03:26 AM, Benny Pedersen wrote:

On Tue, 27 Dec 2011 08:22:47 +0100, Bjørn Ruberg wrote:

Be advised that if you plan to reject
*sender addresses* claiming to originate from your own domain, you
might break legitimate mails.

how ?

Mailing lists like this one, for instance. When you post to the
postfix-users list, your message is redistributed from the list's
servers having your address as the originating address. The message 
will
originate from outside of your systems but will have your From: 
address.

If you block this, you won't see your own postings to the list.

This is an excerpt from the headers in your e-mail:

  From: Benny Pedersen
  To:
  Subject: Re: Ok. I'm finding a small issue on my server.

This is a common misconception.  The envelope sender is not the same as
the From: header.  This is the envelope sender for your message (and
indeed for every message from this mailing list):

Return-Path:



While your point is valid for envelope sender and this mailing list in 
particular,


No, his point is valid for any MAIL FROM: address, and any mailling list.

I can't seem to recollect that I specified the envelope sender vs 
header from, 


You explicitly emphasized *sender addresses* above.

This means the envelope or MAIL FROM: sender address, which A. must be 
valid, and B. must be allowed to send mail via this mail host.


Many people (me and most of this list included) reject impersonation of 
the sender address unless it is on an encrypted submission port; this is 
the norm rather than the exception nowadays.

Spam really sucks, in case you hadn't noticed.

nor claimed they are the same. Nor did the OP say anything about which 
of those the OP wanted to check. When/if rejecting e-mails based on 
header from (e.g. using header_checks), I think my argument is valid.


Rejecting (and, more importantly, accepting) mail based *solely* on 
header values is a bad strategy.




When it comes to envelope sender, perhaps you can shed some light on 
whether this quote from http://linxnet.com/misc/postfix-anti-UCE.txt 
is also a "common misconception"?


Q5. Couldn't one do the same thing with check_sender_access
(envelope-sender) as with the check_helo_access with regards to
checking for somebody spoofing ones own domain?

A5. Dangerous.  There are a number of scenarios where a sender from
outside mynetworks might legitimately have an envelope-sender
address in (one of) your domain(s).  E.g.:



Actual Answer 5: yes, you can do that.
However, it would be prudent to provide your (mostly roaming) users with 
access to an encrypted submission(8) port that uniquely links their 
login to allowable sender addresses.

Postfix fully supports this.


f...@yourdom.ain sends mail to j...@example.com

But j...@example.com has, unknown to fred, a .forward pointing
to j...@yourdom.ain

That results in example.com's mailserver legitimately sending
that email with yourdom.ain in the envelope-sender




The above is incorrect.
A user's .forward file is processed by the mail Delivery agent (MDA), 
not the mail Transfer agent (MTA).
In the case of a default postfix installation, this is the Local 
Delivery Agent (LDA), local(8).


This means that as far as the MTA is concerned, once it is passed off to 
the MDA/LDA, the message has been delivered; the MTA is not involved in 
processing the .forward file.


The From: *header* will still be f...@yourdom.ain, but the envelope 
sender MAIL FROM: address used in the *new* message originating from the 
machine processing the .forward file will be the forwarding users' own.
The message is /re-sent/ by the MDA to the forwarding address, and 
enters the MTA as a new message.


Quoting the man page for local(8):

*MAIL FORWARDING*
For the sake of reliability, forwarded mail is re-submitted as a 
new message, so that each recipient has a separate on-file delivery 
status record.
In order to stop mail forwarding loops early, the software adds an 
optional *Delivered-To:* header with the final envelope recipient address.
If mail arrives for a recipient that is already listed in a 
*Delivered-To:* header, the message is bounced.



And yes, it's a common misconception.



(Thanks a tip o' the hat to Andrew of SuperNews for pointing
 this gotcha out.)



--
J.

Re: Postfix as a Smart Host for Exchange 2010 with TLS

[Ben Curtis]

First off, thanks for the help everyone!

>Test postfix TLS with openssl to make sure postfix is working correctly.
>
>For port 25 (or 587) with STARTTLS
># openssl s_client -connect example.com:25 -starttls smtp
>

I'm using 587, and this seemed to functioned just fine from a remote host:

--
[root@server ~]# openssl s_client -connect mail.MYDOMAIN.com:587 -starttls smtp
CONNECTED(0003)
depth=0 C = US, ST = North Carolina, L = Apex, O = MYDOMAIN, CN =
mail.MYDOMAIN.com
verify error:num=18:self signed certificate
verify return:1
depth=0 C = US, ST = North Carolina, L = Apex, O = MYDOMAIN, CN =
mail.MYDOMAIN.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=North Carolina/L=Apex/O=MYDOMAIN/CN=mail.MYDOMAIN.com
   i:/C=US/ST=North Carolina/L=Apex/O=MYDOMAIN/CN=mail.MYDOMAIN.com
---
Server certificate
-BEGIN CERTIFICATE-
*
-END CERTIFICATE-
subject=/C=US/ST=North Carolina/L=Apex/O=MYDOMAIN/CN=mail.MYDOMAIN.com
issuer=/C=US/ST=North Carolina/L=Apex/O=MYDOMAIN/CN=mail.MYDOMAIN.com
---
No client certificate CA names sent
---
SSL handshake has read 1871 bytes and written 346 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
Protocol  : TLSv1
Cipher: DHE-RSA-AES256-SHA
Session-ID: 
Session-ID-ctx:
Master-Key: ***
Key-Arg   : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
TLS session ticket:
**

Compression: 1 (zlib compression)
Start Time: 1326139550
Timeout   : 300 (sec)
Verify return code: 18 (self signed certificate)
---
250 DSN
ehlo MYDOMAIN
250-mail.MYDOMAIN.com
250-PIPELINING
250-SIZE 1024
250-ETRN
250-AUTH PLAIN DIGEST-MD5 LOGIN CRAM-MD5
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
quit
221 2.0.0 Bye
closed
--

>Or if you've enabled master.cf port 465 TLS wrappermode (sometimes
>mistakenly referred to as SSL in mail client software):
># openssl s_client -connect example.com:465
>

I'm not using 465, so this doesn't seem to be it.


>If postfix checks out OK, the problem is with the Exchange
>configuration.
>
>Maybe Exchange needs to import the private root CA you used to
>generate your certificates?  Maybe Exchange is trying to use
>wrappermode on a port configured for STARTTLS (or vice versa)?
>

I completely agree this is probably something specific to Exchange
2010, but I'm not even sure how I would figure this out from the
Exchange side. Exchange doesn't exactly have a lot of "settings" like
Postfix does. I can either turn TLS on or off, but there doesn't
appear to be any other related configuration. What I've tried to find
out in Exchange forums has been useless, unfortunately.

>If you need more help with postfix, show "postconf -n" output and
>relevant log entries.
>

Below is the output of postconf, and under that is a log level 7 TLS
negotiation.

"postconf -n"
--
alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases
append_at_myorigin = no
broken_sasl_auth_clients = no
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = amavis:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
delay_warning_time = 48h
disable_vrfy_command = yes
html_directory = no
inet_interfaces = all
inet_protocols = all
local_recipient_maps =
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
masquerade_domains = ** ** **
masquerade_exceptions = root
maximal_backoff_time = 8000s
maximal_queue_lifetime = 16d
minimal_backoff_time = 1000s
mydestination = $myhostname, localhost.$mydomain, localhost
myhostname = mail.**.com
mynetworks_style = host
myorigin = *.com
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.6.6/README_FILES
relay_domains = proxy:mysql:$config_directory/mysql_relay_domains_maps.cf
relay_recipient_maps =
proxy:mysql:$config_directory/mysql_relay_recipient_maps.cf
relayhost =
sample_directory = /usr/share/doc/postfix-2.6.6/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_helo_timeout = 60s
smtp_tls_CAfile = /etc/postfix/certs/ca.crt
smtp_tls_note_starttls_offer = yes
smtp_tls_security_level = may
smtpd_banner = $myhostname ESMTP
smtpd_client_restrictions = reject_rbl_client sbl.spamhaus.org,
reject_rbl_client blackholes.easynet.nl, reject_rbl_client
dnsbl.njabl.org
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_delay_reject = yes
smtpd_hard_error_limit = 12
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, warn_if_reject
reje

Selecting Client Name Based On IP Version

[Sabahattin Gucukoglu]

One of my Postfix installs runs behind a NAT box.  The host name for the local 
private IP is in the .local domain, not suitable for public use in SMTP 
sessions but suitable for trace fields.  However, on IPv6, the host is a 
first-class citizen on the net and has its own host name.

Can I arrange it so that the SMTP client uses different names in the EHLO/HELO 
command based on the protocol (IPv4 or IPv6) I am connecting with?  I do not 
want IPv6 servers to know my server as "natbox.mydomain", but 
"Bloodstone.mydomain".  (natbox is the NAT box, anything could run behind that.)

more generally: can I arrange it so that I can select the EHLO/HELO name based 
on the destination host and protocol?  Then intra-domain communication can use 
a local domain name.

Cheers,
Sabahattin

Re: Postfix as a Smart Host for Exchange 2010 with TLS

[Noel Jones]

On 1/9/2012 2:24 PM, Ben Curtis wrote:
> First off, thanks for the help everyone!
> 
>> Test postfix TLS with openssl to make sure postfix is working correctly.
>>
>> For port 25 (or 587) with STARTTLS
>> # openssl s_client -connect example.com:25 -starttls smtp
>>
> 
> I'm using 587, and this seemed to functioned just fine from a remote host:
> 
> --
> [root@server ~]# openssl s_client -connect mail.MYDOMAIN.com:587 -starttls 
> smtp
> CONNECTED(0003)
...

> 250 DSN
> quit
> 221 2.0.0 Bye
> closed

OK, postfix TLS is working correctly.


> Below is the output of postconf, and under that is a log level 7 TLS
> negotiation.

tls log levels above 1 are generally useless unless you are an
expert in openssl (which I'm not sufficiently).

Likewise with verbose logging in postfix; the vast majority of
postfix config problems can be debugged with normal logging.

> 
> "postconf -n"
> 

no glaring errors in postconf.

> --
> 
> 
> maillog with log level 7 (I just noticed the "QUIT" message below, but
> not sure how to interpret it)

everything reasonably normal up to here.

> Jan  9 20:12:18  postfix/smtpd[11743]: Read 6 chars: QUIT??

Remote site (Exchange) didn't like something and issued QUIT.  No
reason for the QUIT is given nor expected in the postfix logs.

> Jan  9 20:12:18  postfix/smtpd[11743]: disconnect from
> **[***]

remote site disconnected.


FWIW, it appears the TLS negotiation between postfix and exchange
worked since Exchange was able to send the QUIT over the encrypted
link, but Exchange didn't like something about the connection and so
disconnected.  Since Exchange logs the message about an untrusted
certificate, there's no reason at this point to not believe that
message is accurate.

Sorry, can't help any more.  You might google around how to import a
certificate in Exchange, or how to mark a particular client as trusted.



  -- Noel Jones

Re: Ok. I'm finding a small issue on my server.

[Noel Jones]

On 1/9/2012 1:24 PM, Jeroen Geilman wrote:
> Many people (me and most of this list included) reject impersonation
> of the sender address unless it is on an encrypted submission port;
> this is the norm rather than the exception nowadays.

Be aware this may reject some legit mail.  Feel free to do it as a
local policy, just understand it's not 100% safe.  Safer to use
SpamAssassin to add points to internal domains that fail SPF.  And I
strongly suspect the "most of this list" you claim is skewed towards
smaller sites and schools, with larger businesses and ISPs tending
to not do this.

Examples are web sites such as news sites "send article to a friend"
and external calendar/reminder services.  Airlines used to do this
with flight notices, but I think most of them have fixed it.  Some
"greeting ecard" web sites; it's debatable if you want those anyway,
but your users might.

While many of these have moved to (correctly) using their own
envelope and the internal From: header, there's still enough that
use the internal envelope sender that this is not a globally always
safe rule.

The mail list example given earlier is not applicable here; that's
an example of a From: header with an internal address, and should
not be rejected.


> Spam really sucks, in case you hadn't noticed.

The general admonition is don't fix mail by breaking it.



  -- Noel Jones

Re: Selecting Client Name Based On IP Version

[Wietse Venema]

Sabahattin Gucukoglu:
> One of my Postfix installs runs behind a NAT box.  The host name
> for the local private IP is in the .local domain, not suitable for
> public use in SMTP sessions but suitable for trace fields.  However,
> on IPv6, the host is a first-class citizen on the net and has its
> own host name.
>
> Can I arrange it so that the SMTP client uses different names in
> the EHLO/HELO command based on the protocol (IPv4 or IPv6) I am
> connecting with?  I do not want IPv6 servers to know my server as
> "natbox.mydomain", but "Bloodstone.mydomain".  (natbox is the NAT
> box, anything could run behind that.)
>
> more generally: can I arrange it so that I can select the EHLO/HELO
> name based on the destination host and protocol?  Then intra-domain
> communication can use a local domain name.

I don't understand the question.

- Intra-domain communication. Is this IPV4 only? IPv6 only? Both?

- IPv4 communication. To the local domain? To the outside world? Both?

- IPv6 communication. To the local domain? To the outside world? Both?

There currently exists no support for making parameters IP protocol
dependent - with almost 900 configuration parameters, it is already
quite complicated.

Wietse

Re: (no subject)

[Matthias Andree]

(note I've manually directed replies to the list - I do not desire
personal replies)

Am 09.01.2012 06:23, schrieb Ashok Kumar J:
>  I would like to know about any compression technology implemented and
> used in the postfix mail queue.

There is none.  As to the record format of the queue files, please
consult the sources - that's what open source software offers as its
advantage.

Re: Selecting Client Name Based On IP Version

[Lorens Kockum]

On Mon, Jan 09, 2012 at 08:37:48PM +, Sabahattin Gucukoglu wrote:
> One of my Postfix installs runs behind a NAT box.  The host
> name for the local private IP is in the .local domain, not
> suitable for public use in SMTP sessions but suitable for
> trace fields.  However, on IPv6, the host is a first-class
> citizen on the net and has its own host name.
>
> Can I arrange it so that the SMTP client uses different names
> in the EHLO/HELO command based on the protocol (IPv4 or IPv6)
> I am connecting with?  I do not want IPv6 servers to know
> my server as "natbox.mydomain", but "Bloodstone.mydomain".
> (natbox is the NAT box, anything could run behind that.)

In your place I would put the IPv6 domain name, and not worry
about the HELO being wrong when using IPv4. You could revise
that if you have problems with your correspondents actually
rejecting or downgrading your mail based upon the HELO string,
but I seriously doubt that will happen.

If, from some desire for ultimate perfection, you really want to
have the correct HELO name, then why not add another hostname
that points to the IPv4 address and the IPv6 address, and put
that as your mail server name?

HTH

Re: Ok. I'm finding a small issue on my server.

[Reindl Harald]

Am 09.01.2012 22:07, schrieb Noel Jones:
> On 1/9/2012 1:24 PM, Jeroen Geilman wrote:
>> Many people (me and most of this list included) reject impersonation
>> of the sender address unless it is on an encrypted submission port;
>> this is the norm rather than the exception nowadays.
> 
> Be aware this may reject some legit mail.

which?

> Feel free to do it as a
> local policy, just understand it's not 100% safe.

it is exactly as safe as a RBL

> Examples are web sites such as news sites "send article to a friend"
> and external calendar/reminder services.  Airlines used to do this
> with flight notices, but I think most of them have fixed it.  Some
> "greeting ecard" web sites; it's debatable if you want those anyway,
> but your users might.

in this case this is NOT legit mail, sites implementing this way
have to be rejected - a "greeting ecard" where you can enter
a e-mail-address which will be used as ENVELOPE sender is
badly broken

any web-application using a foreign ENVELOPE sender is badly broken





signature.asc
Description: OpenPGP digital signature

Re: Ok. I'm finding a small issue on my server.

[Noel Jones]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 1/9/2012 6:36 PM, Reindl Harald wrote:
> 
> 
> Am 09.01.2012 22:07, schrieb Noel Jones:
>> On 1/9/2012 1:24 PM, Jeroen Geilman wrote:
>>> Many people (me and most of this list included) reject
>>> impersonation of the sender address unless it is on an
>>> encrypted submission port; this is the norm rather than the
>>> exception nowadays.
>> 
>> Be aware this may reject some legit mail.
> 
> which?
> 
>> Feel free to do it as a local policy, just understand it's
>> not 100% safe.
> 
> it is exactly as safe as a RBL

Yes, it's fair to compare this with a random dnsbl you find
referred to somewhere online that you really know nothing about
other than some third-party saying it's great.

> 
>> Examples are web sites such as news sites "send article to a
>> friend" and external calendar/reminder services.  Airlines
>> used to do this with flight notices, but I think most of them
>> have fixed it.  Some "greeting ecard" web sites; it's
>> debatable if you want those anyway, but your users might.
> 
> in this case this is NOT legit mail, sites implementing this
> way have to be rejected - a "greeting ecard" where you can
> enter a e-mail-address which will be used as ENVELOPE sender
> is badly broken
> 
> any web-application using a foreign ENVELOPE sender is badly
> broken


I don't disagree that this is badly broken; nonetheless it's still
in use.  Unless one is in the enviable position to dictate and
enforce policy with regardless of
customer/user/management/owner/whatever input -- my way or the
highway as they say -- this and all other anti-spam techniques
need to be considered in a local cost vs. benefit.  Anti-spam is
never one-size-fits-all.

I dropped this rule when I realized that virtually all the spam
would still be rejected by other rules, leaving this rule to only
hit the occasional false-positive.  Not many, but enough to cause
some complaints.  Disabling it did not lead to a flood of spam
entering the system.

I gently remind you that just because something is broken doesn't
mean it can't or shouldn't be accepted.  Just because something
works great for you doesn't mean it's appropriate for everyone.



  -- Noel Jones
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPC7FpAAoJEJGRUHb5Oh6gKrwIANeyfz2p/S8w8R8ld9f140Vi
Kmq3AqwN2RcuwwhcChNmytHTLUwIxjlv2NLKH9ClhuQBBHhirBKwuvFHtqr7veh9
Fuw35ujmRaM+XqjkU8av/6CjfpxFPZoKwDXATmgOZ/r1o1Mqghlees1p36IK/TJx
7e+MJaTJrou7VKJE8bxEva0bWafrYdtq+UL0FfB2rBo85kjMEyxF1n3298D52aIv
F14hoaL4ejvf2ojI6gHm7RYEXa0Su1SUxS9RF6KdckWmd+w4mUncUh62Sb6UJfyd
DDzxaRlG0dsMNufmML3T9Yi9z0vXHmy+tYOu4Ce4vJd9RmuyZXDhceZOOdCVHXg=
=ie2Y
-END PGP SIGNATURE-

Re: Ok. I'm finding a small issue on my server.

[Reindl Harald]

Am 10.01.2012 04:32, schrieb Noel Jones:
>> in this case this is NOT legit mail, sites implementing this
>> way have to be rejected - a "greeting ecard" where you can
>> enter a e-mail-address which will be used as ENVELOPE sender
>> is badly broken
> 
>> any web-application using a foreign ENVELOPE sender is badly
>> broken
> 
> I don't disagree that this is badly broken; nonetheless it's still
> in use.  

and nobody will fi it as long enough accept it

> Unless one is in the enviable position to dictate and
> enforce policy with regardless of
> customer/user/management/owner/whatever input -- my way or the
> highway as they say -- this and all other anti-spam techniques
> need to be considered in a local cost vs. benefit.  Anti-spam is
> never one-size-fits-all.

that is right, but broken things should not be supported

> I dropped this rule when I realized that virtually all the spam
> would still be rejected by other rules, leaving this rule to only
> hit the occasional false-positive.  Not many, but enough to cause
> some complaints.  Disabling it did not lead to a flood of spam
> entering the system.

from the moment on where you set SPF records you should NEVER
accept forged senders because it is real bad practice set a
sign for all others that foreign senders can be rejected
and then accept them on the authoritative one

> I gently remind you that just because something is broken doesn't
> mean it can't or shouldn't be accepted.  

your opinion

in my opinion broken things which can be easily fixed and
where anybody can explain why exactly they are broken
MUST NOT be aceepted, reason below

> Just because something works great for you doesn't mean 
> it's appropriate for everyone

well, and as long way too much people tolerate broken things
the real big problems will still remain

would every server out there REJECT any forged messages
resulting in all people using their smtp matching to the
address from which they send and most domains implement
SPF it would be MUCH easier for all

it would result that not so many poor educated people are
setting up mailservers with broken configs/dns-records/ptr
and then start complain at me because i reject their crap
simply because nearly all would reject their crap

corrently the most complaints are coming to administrators
which are doing their work because to many are doing not
with the excuse "but it works"




signature.asc
Description: OpenPGP digital signature

Re: Ok. I'm finding a small issue on my server.

[Bastian Blank]

On Tue, Jan 10, 2012 at 01:36:42AM +0100, Reindl Harald wrote:
> Am 09.01.2012 22:07, schrieb Noel Jones:
> > On 1/9/2012 1:24 PM, Jeroen Geilman wrote:
> >> Many people (me and most of this list included) reject impersonation
> >> of the sender address unless it is on an encrypted submission port;
> >> this is the norm rather than the exception nowadays.
> > Be aware this may reject some legit mail.
> which?

Everything forwarded.

Bastian

-- 
Vulcans worship peace above all.
-- McCoy, "Return to Tomorrow", stardate 4768.3