from:"lst_hoe02"




Zitat von Wietse Venema :


lst_ho...@kwsoft.de:

What is the way to go to take part of the feature development? I looks
like we need a slight modification of the auth external as described.


Mailin glist discussions.

Eventually there will be a postfix--nonprod release that combines
all the code (jay) and none of the guarantees (bleh).

I am not convinced that stuffing arbitrary PKI identities into a
SASL identity is necessarily a good idea. Maybe it is safer to solve
this problem without PKI-to-SASL cross-talk.

Wietse


At least in my case no SASL would be needed. For me a  
relay_clientcerts able to list allowed validated CNs would be enough.  
The SASL stuff will be handy for tie a "identity" to certificates and  
assign additional rights/limits of course.


Andreas

Re: TLS client certificates and auth external




Zitat von Emmanuel Fusté :

You need the relay_clientcerts map with relay_clientcerts_auto mode.
Put the fingerprint or pkey_fingerprint and the mapped SASL identity  
in the file and it will work

For example:
43:B6:FE:07:BB:2E:BF:86:8A:4D:2A:DD:78:07:09:C6    xxx.kwsoft.de



Will try that, but for our final use case we have no way fix the  
fingerprint of the remote client, it can change any time. The only  
thing which should stay is the CN.



smtpd_tls_loglevel = 2
smtpd_tls_ask_ccert = yes
smtpd_sasl_auth_enable = yes

smtpd_use_tls=yes
smtpd_tls_CApath = /etc/ssl/certs

But this leads to
Apr 18 11:46:05 linux-test postfix/smtpd[4257]:  
kw-tools.hq.kwsoft.de[10.1.7.15]: subject_CN=xxx.kwsoft.de,  
issuer=SwissSign Server Silver CA 2014 - G22,  
fingerprint=B8:D9:ED:1F:33:FE:DB:36:11:A6:D9:3F:BA:B5:1D:44,  
pkey_fingerprint=43:B6:FE:07:BB:2E:BF:86:8A:4D:2A:DD:78:07:09:C6
Apr 18 11:46:05 linux-test postfix/smtpd[4257]: Trusted TLS  
connection established from kw-tools.hq.kwsoft.de[10.1.7.15]:  
TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Apr 18 11:46:05 linux-test postfix/smtpd[4257]: NOQUEUE: reject:  
RCPT from kw-tools.hq.kwsoft.de[10.1.7.15]: 454 4.7.1  
: Relay access denied; from=  
to= proto=ESMTP helo=
Apr 18 11:46:05 linux-test postfix/smtpd[4257]: disconnect from  
kw-tools.hq.kwsoft.de[10.1.7.15] ehlo=2 starttls=1 mail=1 rcpt=0/1  
data=0/1 rset=1 quit=1 commands=6/8


What i actually need is relaying based on validated certificate CN  
without forcing the client to use some form of authentication, so  
this would basically mean relay_clientcerts with CN lookup key or a  
relay_clientcerts_auto_cn to always skip AUTH and use the CN as  
username i guess.


Yes, if you don't want fingerprint to something maps, you need a  
"commonName_auto" mode which rely on SASL external provider to  
validate the user (provide the map of valid users) but auto triggered.
For that, you need to invoke SASL external auth directly in the  
smtpd sasl glue code as it is in the processing of the AUTH verb (a  
simplified single step version).
Will look at it if I have time, but I prefer to wait Viktor/Wietse  
comments before.


Emmanuel.


Thanks, so i will wait for comment if we can include our special case also.

Andreas

Re: TLS client certificates and auth external




Zitat von Emmanuel Fusté :


Hello,

Great piece of work ! It solve a big part of my problem, but sadly I  
need to go deeper.


Le 18/03/2019 à 22:45, Bastian Schmidt a écrit :
In the meantime I have completed a patch and sent it to Wietse and  
Victor, which adds an option smtpd_sasl_tls_ccert_username.

As the patch is rather small, I also attached it to this message.

This smtpd_sasl_tls_ccert_username option can be used in the following way:

Using smtpd_sasl_tls_ccert_username = commonName
After providing a verified client certificate, postfix advertises  
auth external and the user can authenticate with the username being  
the commonName of the certificate. This is for users having control  
over the CA issuing the certificates and resembles the way cyrus  
imap handles the situation.


Using smtpd_sasl_tls_ccert_username = relay_clientcerts
When a client presents a certificate, where the fingerprint matches  
in relay_clientcerts, the lookup value (previously unused) is used  
to get the username for sasl. The client can then perform an auth  
external with this username successfully. This is a solution for  
users, which cannot control the CAs or do not want to trust them or  
cope with crls, ... It fits in the way postfix currently handles  
client certificates.


I have to deal with products that do not support SMTP AUTH (big  
email security appliance provider .) but are able to present a  
TLS certificate.
On my platform, the use of the smtpd_sender_login_maps and  
associated restrictions (reject_sender_login_mismatch) is mandatory  
to achieve our goal.
At first, I was thinking about using the lookup value of  
relay_clientcerts to map a sasl username.
It is nicely done with your patch with smtpd_sasl_tls_ccert_username  
= relay_clientcerts, but I need to go one step further:
I need to completely bypass the sasl provider call and act as if the  
mapped user successfully authenticate.
It would be something like "smtpd_sasl_tls_ccert_username =  
relay_clientcerts_nosasl" or relay_clientcerts_saslbypass or other  
(I'm not good at finding good option naming ...)


The goal is to be as transparent as possible :
- if the client is not found in the relay_clientcerts, act as usual
- if the client is found in the relay_clientcerts, no longer  
announce AUTH support, the auth and identity mapping is already done  
by the relay_clientcerts map


I think it is not a big code complexity addition on top of your  
work, but before going further I would like to request for comments  
about this.

Viktor, Wietse, would you accept such addition ?

Emmanuel.


I tested this with a patched postfix for my usage scenario (relaying  
based on validated CN) but i fail to get it work. Note that i don't  
need a sasl username at all, but also tested with sasl username and  
check_sasl_access.


The config basically looks like this:

smtpd_relay_restrictions =
   permit_mynetworks,
   permit_sasl_authenticated,
   check_sasl_access hash://etc/postfix/check_sasl_access,
   defer_unauth_destination

# tested both
#smtpd_sasl_tls_ccert_username = commonName
smtpd_sasl_tls_ccert_username = relay_clientcerts_auto
#relay_clientcerts = hash://etc/postfix/relay_clientcerts
smtpd_tls_loglevel = 2
smtpd_tls_ask_ccert = yes
smtpd_sasl_auth_enable = yes

smtpd_use_tls=yes
smtpd_tls_CApath = /etc/ssl/certs

But this leads to
Apr 18 11:46:05 linux-test postfix/smtpd[4257]:  
kw-tools.hq.kwsoft.de[10.1.7.15]: subject_CN=xxx.kwsoft.de,  
issuer=SwissSign Server Silver CA 2014 - G22,  
fingerprint=B8:D9:ED:1F:33:FE:DB:36:11:A6:D9:3F:BA:B5:1D:44,  
pkey_fingerprint=43:B6:FE:07:BB:2E:BF:86:8A:4D:2A:DD:78:07:09:C6
Apr 18 11:46:05 linux-test postfix/smtpd[4257]: Trusted TLS connection  
established from kw-tools.hq.kwsoft.de[10.1.7.15]: TLSv1.2 with cipher  
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Apr 18 11:46:05 linux-test postfix/smtpd[4257]: NOQUEUE: reject: RCPT  
from kw-tools.hq.kwsoft.de[10.1.7.15]: 454 4.7.1 :  
Relay access denied; from= to=  
proto=ESMTP helo=
Apr 18 11:46:05 linux-test postfix/smtpd[4257]: disconnect from  
kw-tools.hq.kwsoft.de[10.1.7.15] ehlo=2 starttls=1 mail=1 rcpt=0/1  
data=0/1 rset=1 quit=1 commands=6/8


What i actually need is relaying based on validated certificate CN  
without forcing the client to use some form of authentication, so this  
would basically mean relay_clientcerts with CN lookup key or a  
relay_clientcerts_auto_cn to always skip AUTH and use the CN as  
username i guess.


Any other idea?

Thanks

Andreas

Any othe idea

Re: TLS client certificates and auth external




Zitat von Wietse Venema :


lst_ho...@kwsoft.de:

This sounds like the feature we will need. I doubt the client would be
able to do real AUTH, but we have to trust/relay based on the CN of a
validated certificate. Is there any progress merging this in the 3.5
line or do i have to poke around with patches some longer?


Yes and yes. It is ready when it is ready.

Wietser


What is the way to go to take part of the feature development? I looks  
like we need a slight modification of the auth external as described.


Thanks

Andreas

Re: TLS client certificates and auth external

2019-04-11 Thread lst_hoe02




Zitat von Emmanuel Fusté :


Le 27/03/2019 à 18:10, Emmanuel Fusté a écrit :

Le 27/03/2019 à 17:14, Viktor Dukhovni a écrit :

On Wed, Mar 27, 2019 at 04:31:33PM +0100, Emmanuel Fusté wrote:


The goal is to be as transparent as possible :
- if the client is not found in the relay_clientcerts, act as usual
- if the client is found in the relay_clientcerts, no longer announce
AUTH support, the auth and identity mapping is already done by the
relay_clientcerts map

I believe you're asking Postfix to (when configured to do that)
simulate "AUTH EXTERNAL" when the client has presented a client
certificate, but proceeds from "EHLO" to "MAIL FROM" with no
intevening explicit "AUTH".
Yes exactly, if a hash to sasl id/username mapping is found in the  
relay_clientcerts


The simulated "AUTH EXTERNAL" would never "fail" (5XX), it either
yields an authenticated user or proceeds with the user unauthenticated,
and acts accordingly.

Does that sound right?
Yes, in case of unauthenticated (not present in relay_clientcerts),  
the simulated "AUTH EXTERNAL" must ideally not be performed and  
AUTH support be announced as usual as this is perhaps a client with  
proper AUTH support (otherwise it would be listed with a mapping in  
relay_clientcerts).


Ok, patch attached.
Need to be applied on top of Bastian one.
Work well here, thanks to the hard part done by Bastian !
Please comment.

Emmanuel.


This sounds like the feature we will need. I doubt the client would be  
able to do real AUTH, but we have to trust/relay based on the CN of a  
validated certificate. Is there any progress merging this in the 3.5  
line or do i have to poke around with patches some longer?


Thanks

Andreas

Re: permit_tls_clientcerts with CN matching

2019-03-31 Thread lst_hoe02




Zitat von Wietse Venema :


lst_ho...@kwsoft.de:

Hello,

we need to authenticate a SMTP client connection base on the CN of the
(trusted) client certificate. The client is not under our control
(O365 connector), so we will get no notification if the key
fingerprint will change. As far as i can see Postfix is only able to
use certificate fingerprints to allow relaying, not the CN string, no?

Have i missed something or is this not considered a valid use case?


CN-based access checks are not built into Postfix, but the CN is
available in the policy delegation protocol's ccert_subject attribute,
if the client certificate can be verified with PKI.

There is a patch-in-progress (thread: TLS client certificates and
auth external) that provides the option to permit relaying based
on certificate info.

Wietse


Will this be available in the 3.5 experimental release or only later  
down the road for 3.6?


Thanks

Andreas

permit_tls_clientcerts with CN matching

2019-03-27 Thread lst_hoe02


Hello,

we need to authenticate a SMTP client connection base on the CN of the  
(trusted) client certificate. The client is not under our control  
(O365 connector), so we will get no notification if the key  
fingerprint will change. As far as i can see Postfix is only able to  
use certificate fingerprints to allow relaying, not the CN string, no?


Have i missed something or is this not considered a valid use case?

Regards

Andreas

Re: Postfix, Hotmail never arrive

2017-03-08 Thread lst_hoe02


Zitat von Maurizio Caloro :




Hello Together
Today i have contact Microsoft, but i dont have any News.


"My name is 123 and I work with the Outlook.com Deliverability Support Team.

We have reviewed your IP(s) *(*w.x.y.z*) *and determined that  
messages are being filtered (i.e. sent to the Junk folder) based on  
the recommendations of the SmartScreen  
®  
Filter.

"

I have:
-No IP blacklist (Spamhaus)
-DMARC is good
-SPF is good
-DKIM is good (OpenDkim, 2048, rsa-sha256)
-PTR records is good.
-Barracuda SpamScore = 0.0

but me Email will not appair to Hotmail/Outlook.com, and the mail  
also arn't visible in Spam folder?!

Please what i need to do ?


You might not like the answer but no one who cares about e-mail should  
use Hotmail or Yahoo. It is purely their decision what to drop/block  
whatever and only they can solve it. Nothing Postfix can do here.


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Mitigating From field spoofing (revised)

2016-07-05 Thread lst_hoe02



Zitat von Jack beanstallk :


Noel Jones  megan.vbhcs.org> writes:


This is not something built into postfix.

As an alternative, use SPF and DKIM to detect forged mail claiming
to be from your own domain.

  -- Noel Jones




Just to clarify is this something that is not built into postfix
with my current use case?
i.e because the postfix server is not authenticating users
it's just a relayhost?

If I made users authenticate against the postfix server
first should options
such as reject_sender_login_mismatch do
what I am trying to achieve?


This will check against the MAIL FROM smtp command, not the "From:"  
header. You might remove the header before cleanup and it will add  
this header with the information from the SMTP commands, but obviously  
not displayname and the like. Maybe someone has a smart regex which  
could do the job...


Regards

Andreas








smime.p7s
Description: S/MIME Cryptographic Signature

Re: reality-check on 2016 practical advice re: requiring inbound TLS?

2016-04-11 Thread lst_hoe02



Zitat von jaso...@mail-central.com:


On Sun, Apr 10, 2016, at 07:46 PM, Bill Cole wrote:

On a system where you know enough about all your users to know that they
don't want to get critical email from clueless sources, you can make
restrictive choices with no trouble. If you don't actually know that,
choosing to require senders to use rigorous security correctly will
often lead to unpleasant surprises.



Ya gotta break a few eggs to make an omelette ;-)


And if you don't want to receive e-mail you should not operate a mail  
server or even publish a mail address.






smime.p7s
Description: S/MIME Cryptographic Signature

Re: bad.psky.me RBL?

2016-04-06 Thread lst_hoe02



Zitat von Quanah Gibson-Mount :

Is anyone familiar with this RBL and its quality?  Not a whole lot  
of info at .  Terms seem probably ok  
.


If there isn't a lot of info, expect the worst. You should always be  
aware that you "outsource" at least parts of the ham/spam decision and  
you really should be careful about that.


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Questions about SSL for outgoing emails

2015-09-24 Thread lst_hoe02



Zitat von Michael Peter :


Hello,

smtpd_tls_security_level = encrypt
smtp_tls_security_level = encrypt

I configured postfix to use encryption for incoming and outgoing emails.

but incase the receipt  has untrusted certificate or self signed
certificate, postfix still deliver the email.

How to enforce postfix not to send the email incase the receipt
certificate is untrusted or self signed?

Many thanks

Michael Peter


You will need "verify" level for this :  
http://www.postfix.org/TLS_README.html#client_tls_verify


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Conditional Greylisting

2015-09-19 Thread lst_hoe02

Zitat von Bruce Marriner :

On Friday, September 18, 2015 04:59 PM CDT, "Bill Cole"
wrote:

On 18 Sep 2015, at 14:29, Bruce Marriner wrote:

> So I want to be able to set up Postfix so, if it passes DKIM or other
> checks that give me a high confidence then just skip the postgrey
> stuff
> entirely.

In what exactly does a valid DKIM signature give you high confidence? I
suspect that this is misplaced...

All a DKIM signature validation tells you is that a message was in fact
signed at the mail system where it claimed to have been signed by an
entity in control of the DNS for the domain identified the signature and
that none of the message fields specified in the DKIM header have been
changed in transit. Looking at the spam that has made it through my
filters this year, I see that 27% of those messages had a valid DKIM
signature, because in fact any spammer who can open a Yahoo account or
register a domain can send mail with a valid DKIM signature.

Ah, well. I think you might be right about misplaced. I've been
reading about this all day learning it and I've started to realize
the same thing. I would like

Now, why can't all the spammers just add a ThisIsSpam header. Sure
would make my life easier :)

I'd still like to reduce my dependency on postgrey. So, if has
valid SPF, valid DKIM, has a low SpamAssassin score, possible test heres> then I could skip it without raising spam too
much, or at all :).

Postgrey just works so well :) I mean, if I have that on I get
almost no spam. But sometimes somethings that should come though
don't and many things are delayed. When I turn it off, I get tons
of spam.

Use the auto-whitelist feature from Postgrey in a reasonable way. The
defaults for this feature are only useful for high traffic sites IMHO.
Use a longer greylisting time and whitelist after first pass with a
veeerrryy long expire time for whitelisted clients.

Regards

Andreas

smime.p7s
Description: S/MIME Cryptographic Signature

Re: Importance of keeping DANE TLSA records correct.

2015-08-22 Thread lst_hoe02



Zitat von Viktor Dukhovni postfix-us...@dukhovni.org:


Until now, most DANE deployments have been on small hobbyist
machines, by people who mostly don't correspond with each other.
So if a particular domain's TLSA RRs were broken, nobody noticed.

This is about to change.  The German email providers web.de and
gmx.de have announced upcoming DANE support (by the end of this
year).  What this means for the hobbyist early adopters is that
forgetting/failing to do key/cert rollover correctly will soon
lead to lost mail.  See:

https://dane.sys4.de/common_mistakes#3
https://tools.ietf.org/html/draft-ietf-dane-ops-16#section-8.1
https://tools.ietf.org/html/draft-ietf-dane-ops-16#section-8.4

If you don't create README files in your certificate directory,
add comments to Postfix configuration files, or otherwise create
reminders for yourself to not forget to do it right, perhaps DANE
is not right for you.  Deploy and forget does not work for TLSA
records if you ever change your certificate or public key.


As security is never Deploy and forget this should be obvious, no?  
DANE will uncover sloppiness which was until now tolerated by SMTP,  
but this is a good thing IMHO.


My proove will be on 24.09.2015, we will see if it fails ;-)

Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: SMTPUTF8 usage

2015-08-20 Thread lst_hoe02



Zitat von Mike Cardwell post...@lists.grepular.com:


* on the Thu, Aug 20, 2015 at 05:36:38PM +0200, Benny Pedersen wrote:


What mail products are SMTPUTF8-compliant at this time?



will it ever be needed ?, with idn domains it allready encoded into 7bit,
is postfix translate this to utf8 ?, dont know here since thunderbird works
with idn domains and postfix


SMTPUTF8 allows for UTF-8 characters in email address local parts. This is
pretty important for most of the people in the World who might want to use
Email.


The E-Mail address is simply a routing token, not the name of the  
owner or some descriptive text. UTF8 is important for the realname  
where people really need to type in all kind of charsets.


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Messagelabs rejects mails from my MTA - how to debug ?

2015-03-17 Thread lst_hoe02



Zitat von Marek Salwerowicz marek_...@wp.pl:


Hi list,

Yesterday I was informed by Users, that they can't send e-mails to  
one of the banking institutions (so  it's a little 'urgent' in  
businesses manner).


The mails are rejected by Messagelabs / Symantec Cloud System, but  
do not provide  any relevant information:



*Diagnostic information for administrators:*

Generating server: ccd1.root4.net

first_name.last_n...@bankdomain.com

#550 5.7.1 Delivery not authorized, message refused ##

Original message headers:

Return-Path: user@my_domain.pl
X-Env-Sender:user@my_domain.pl
X-Msg-Ref: server-7.tower-206.messagelabs.com!1426588985!11238237!1
X-Originating-IP: [my_mta_ip]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received:
X-StarScan-Version: 6.13.4; banners=-,-,-
X-VirusChecked: Checked
X-Virus-Scanned: Debian amavisd-new atmy_mta.my_domain.pl
Message-ID: 55080532.7090208@my_domain.pl
Date: Tue, 17 Mar 2015 11:42:58 +0100
From:User User  user@my_domain.pl
Reply-To: user@my_domain.pl
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0)  
Gecko/20100101 Thunderbird/31.5.0

MIME-Version: 1.0
To: first_name.last_n...@bankdomain.com
Subject:msg_subject
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit



I've already sent e-mails to postmas...@bankdomain.com, but not sure  
if anyone is going to answer it..


Do you have any ideas / online tools so I could check my MTA configuration ?

BTW: The reverse DNS and SPF record are set correctly



See something similar on occasion from Symantec. It took one of our  
customer which had his E-Mail hosted there around a week to get the  
block away. In the end it was our (correctly) S/MIME signing which  
lead to the error message relay denied from their side. Therefor  
don't expect too much from this hints:


http://www.symanteccloud.com/de/de/supportcentre/information/r_troublshooting#

Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Bandwidth choke issue between remote offices and SMPT server.

2015-03-13 Thread lst_hoe02



Zitat von jayesh shinde jayesh.shi...@netcore.co.in:


Hi ,

I am facing problem of bandwidth choke issue between remote
location and SMPT server.
Please giude for below. Want to know how the other busy   servers are
handling such issues.

scenario  :--
-
1) I have centralize high traffic SMTP server with
postfix-2.10.0-1.el6.x86_64  and different locations offices.
2) Branch users send the emails from different email clients like   MS
outlook or Thunderbird  etc ...
3) Currently we have set global 5 MB  message size restriction in
postfix's main.cf .
     If any one send email more than above 5 MB that get reject
and end user get notification pop-up in email client.

Problem :--
--
1) Some time few end users are sending more than 5 MB emails ,   which
getting travel from Location office to Server and utilizing   higher
bandwidth.
2) Server reject the emails when complete email get transfer i.e 
from email client to server.  But not before the actual mail
transfer.
3) When many different location users send such higher size email
traffic , the internet bandwidth is  either getting chock or utilizing
very  high.
4) Some time such higher size emails get stuck in outbox of email
clients , and after certain auto set send/receive interval the
email client sending that email again to server.

Expecting solution :--
---
1) If any one send email more than 5 MB  , then  server must   detect
the mail size before the actual  mail transfer  from   desktop or
server .
 And  base on that server must either  accept or reject the
email with define rule set. The rule set could be either for
email id or domain or IP.



2)  I came to know that every email client don't send the email
size information  in first mode of SMTP transaction  ( I am not
sure about this. )
 But if this is the case , then which are the standard email
client which send the email size information in first SMTP
transaction mode ?
    So that with some customized milter or 3rd party script the
size base restriction policy can apply and issue can control




The server has no way of detecting the size of a mail it has not yet  
received. The server announces the size it is willing to accept and  
the client have to detect that it won't fit. That's the way SMTP works.
Unfortunately there are Clients around (Outlook!!) which doesn't check  
for size and don't respect a no (permanent failure) as a no and  
simply retransmit the same message over and over again.



Is there any method / parameter in postfix config  by which I can
control this situation  ?



No, you can only scan the log and block offending/stupid clients by  
firewall or access list from using SMTP to your server at all.


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: FREAK cipher-suite hygiene for Postfix

2015-03-04 Thread lst_hoe02



Zitat von Viktor Dukhovni postfix-us...@dukhovni.org:


On Wed, Mar 04, 2015 at 07:53:18AM +, Viktor Dukhovni wrote:


Now that the FREAK attack is widely disclosed, those of you who
run SMTP servers that peer with clients that authenticate your
server (be it via the traditional PKI or via DANE), might want to
tighten-up your server cipher-suite settings just in-case:

smtpd_tls_exclude_ciphers = EXPORT, LOW

If nobody has yet elicited and factored any 512-bit RSA public keys
from your server then your unpatched clients will be safe from the
attack.  (Not clear how you'd know this).

If your server might have already signed one or more export RSA
keys then its clients are potentially exposed to the attack for
the lifetime of the server's long-term RSA keys.


It seems I substantially overstated the impact of the attack on
Postfix.  With export RSA key transport the server's signature of
the ephemeral RSA key also binds the ClientHello.random value (as
well as the ServerHello.random, but that could be replayed).

Therefore, the MiTM attacker would need to obtain a fresh signature
over the ephemeral RSA key for each client handshake, which requires
that the server continues to use the same ephemeral key.

This avoids turning each ephemeral key into a long-term key, the
attack only works for as long as the same key is still in use by
a given server and no longer.


So, *after disabling* export grade algorithms, it may be prudent
as appropriate to deploy new certificates.  If you've published
DANE TLSA records, follow the key rotation process described in:

https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.1


With Postfix each smtpd(8) process generates its own ephemeral RSA
key the first time EXPORT ciphers are requested.  Since Postfix
smtpd(8) processes run for a limited amount of time (they exit
after 100 client connections or 100s of idle time whichever is
sooner) the attack on any one key is only effective for the lifetime
of that process and only for additional connections to the *same*
process.

So if you disable EXPORT ciphers on the server, and postfix reload
you're done.  There is no need to replace long-term keys.


Thanks for explaining. As i understand the problem arises from apache  
(and maybe other webservers) generate one EXPORT key which is reused  
for performance reasons until the server process is restarted.


Regards

Andreas





smime.p7s
Description: S/MIME Cryptographic Signature

Re: detecting encryption for outgoing mail

2015-02-16 Thread lst_hoe02



Zitat von John j...@klam.ca:

A couple of the  servers I support are medical offices, and for  
patient confidentiality reasons they need to send email out encrypted.
After a lot of discussion they have come to the conclusion that in  
order to avoid accidentally sending confidential data unencrypted,  
all email must be encrypted.
What they would like is a filter on outgoing email that checks for  
encryption and refuses anything not encrypted. They need to err on  
the side of caution.


So far Google has not been my friend.

Does anybody know of a way of enforcing encryption, or detecting  
unencrypted email.


This is a task for a encryption gateway. You might have a look here in  
the section PGP/SMIME Gateways: http://www.postfix.org/addon.html


With such a gateway you can enforce all kind of policy.

Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Working around recalcitrant ISP wrt rDNS

2015-02-05 Thread lst_hoe02



Zitat von li...@rhsoft.net:


Am 05.02.2015 um 11:03 schrieb lst_ho...@kwsoft.de:

You are putting too much of meaning in a DNS token. There is no global
rule or RFC about the interpretation of the string forming this token.
I'm totaly free to call my host bad-host-static-0815.example.com.


which is no problem because it don't match
[\.\-]?[0-9]{1,3}[\.\-][0-9]{1,3}[\.\-][0-9]{1,3}[\.\-][0-9]{1,3}[\.\-]


The problem still stands. Because some provider choose to name their  
IP with that schema does not mean no one should be able to choose a  
name for their hosts like that.



There are a lot of zombies in the *.comcastbusiness.* PTR space, but
you throw out the baby with the bathwater.  There are other ways to
get rid of the zombies on static IPs without wholesale blocking.
Greylisting and a couple reliable RBLs (or postscreen) will block
the vast majority of zombies without wholesale slaughter.


you did not get the point:

if PTR's with a IP-part would be rejected worldwide and ISP's would
block outgoing port 25 for homeusers the business of infect client PCs
to send out malware to MX hosts would die from one day to the next

* greylisting does *much* more harm be it for large senders
 retry with a dfiierent IP or sender verification on the
 other side for your own outgoing mail


It is true that it is more burden for the sender, but that is *always*
the case with spam preventing systems


no it's not always

greylisting slows down legit mail too


E-Mail is and ever was store-and-forward, so occasionally longer  
delays are by design, rejects or vanish in dustbin because DNS names  
choosen are not.



* all the dialupo RBLs are far from complete


You don't need them


* other RBLs are way too late, if someone makes it on them
 he already had sucess in send his crap out


With greylisting the RBL has time to settle


with a well desigend PTR filter you don't have the delay of  
greylisting and 95% of the PTR rejects are *later* in enough of the  
28 RBL's of the postscreen mix - it looks like below


---

195-154-48-147.rev.poneytelecom.eu (195.154.48.147)

* RBL: b.barracudacentral.org
* RBL: bl.mailspike.net
* RBL: dnsbl.inps.de
* RBL: dnsbl.sorbs.net
* RBL: dnsbl-uce.thelounge.net
* RBL: zen.spamhaus.org

Jan 29 22:57:40: 195-154-48-147.rev.poneytelecom.eu: PTR 615; ; 
Jan 30 05:38:49: RBL inps.de; ; 
Jan 30 05:39:00: RBL inps.de; ; 
Jan 30 05:39:10: RBL inps.de; ; 
Jan 30 05:39:17: RBL inps.de; ; 
---


* there is no single reason for not have a sane PTR


I'm free to call my hosts as i like as long as it is a valid DNS token


surely, you are free to configure your server in a way to get  
delivery problems and since a lot of customers only hosting DNS here  
insisted to get a SPF record for avoid their mails going to the spam  
folder at gmail and other large providers virtually nobody has such  
a generic PTR and at the same time no SPF *and* no DNSWL entry




You are right in the case that the concept of SPF and DNSWL and the  
like in the same liga. They are used for spam fighting which they are  
not really useful for. The most part of our spam reaching inbox for  
example is perfect SPF/DKIM validated, most of the ham we get is  
not. You say that greylisting slow down mail/sender but the way larger  
problem is that PTR parsing, SPF/DKIM whatever cruft introduces  
additional failure point which prevent mail delivery at all.



* postfix has even a setting that A/PTR needs to *match*
 and if someone enables that we no longer dicuss about
 the PTR part in the reverse DNS at all


This is not related at all. With a matching PTR there is some *week*
evidence that i'm the owner of the IP, nothing more.


it * is* related because if it is no longer a  
123.123.123.123.isp.tld but your domain it is *not* some infected  
*enduser machine* and all the dialup-rbls are far away from complete



See, even you don't block everyone with an offending PTR -- you
check for valid SPF or dnswl


because the intention is *not* to block mailservers
a random enduser IP i not listed in the SPF record nor on DNSWL's


We don't care about DNS names and we do not even check for matching PTR
or SPF,DNSWL and the like and still our spam ratio reaching the inbox
from random dial-ups is below 5%. The vast majority of spam are the
famous freemailer like Yahoo,Hotmail,Google some hacked edu-accounts and
the well connected SPF/PTR whatever clean spam centers around the world.


that are *your values*

we have some hundret domains and around 1200 mailusers
97% of the 473209 in the last month rejected by RBL would
have hit the PTR filters too and 90% of all incoming legit mail have  
SPF or are on one or more DNSWL


Connections:   531224
Delivered: 58015
Blocked:   473209


The ration in our

Re: Working around recalcitrant ISP wrt rDNS

2015-02-05 Thread lst_hoe02



Zitat von li...@rhsoft.net:


Am 04.02.2015 um 22:54 schrieb Noel Jones:

On 2/4/2015 3:12 PM, li...@rhsoft.net wrote:


*sadly* that sort of incoming rules is not widespreaded enough,
otherwise spam from infected botnet zombies would no longer exist
and frankly the rule for IPhfc.comcastbusiness.net is manually
written by look at the incoming junk amount all day long hitting the
contentfilter and no single legit mail without SPF/DNSWL over months

/^[\.\-]?([0-9]{1,3}[\.\-]){2,4}[\.\-]?[a-z]{4,20}[\.\-]hfc[\.\-]comcastbusiness[\.\-](co|com|net|org)$/
REJECT Generic DNS-Reverse-Lookup (PTR-Rule: 435) see
http://www.emailtalk.org/ptr.aspx or configure
http://en.wikipedia.org/wiki/Sender_Policy_Framework

even if it is not a directly reject *every* SpamAssassin setup on
this planet gives you a penalty for such a PTR and that maybe the
last piece needed for a milter-reject - in that case you don't know
the reasons, with the reject above you do

score RDNS_DYNAMIC 2.639 0.363 1.663 0.982
score NO_RDNS_DOTCOM_HELO 3.100 0.433 3.099 0.823


Your filter is broken if it can't tell the difference between a
static and dynamic PTR.


your mailsetup is broken if you don't care about basics like a sane  
PTR and frankly even the admin before me not cared about much things  
insisted more than 10 years ago the we never ever send out mails  
from a generic PTR


the truth is that a xx.xx.xx.xx-static-dsl.isp.tld is not a  
mailserver just becaus eit contains the word static - in fact most  
of them are ordinary office dsl lines with clients behind


You are putting too much of meaning in a DNS token. There is no global  
rule or RFC about the interpretation of the string forming this token.  
I'm totaly free to call my host bad-host-static-0815.example.com.



There are a lot of zombies in the *.comcastbusiness.* PTR space, but
you throw out the baby with the bathwater.  There are other ways to
get rid of the zombies on static IPs without wholesale blocking.
Greylisting and a couple reliable RBLs (or postscreen) will block
the vast majority of zombies without wholesale slaughter.


you did not get the point:

if PTR's with a IP-part would be rejected worldwide and ISP's would  
block outgoing port 25 for homeusers the business of infect client  
PCs to send out malware to MX hosts would die from one day to the next


* greylisting does *much* more harm be it for large senders
  retry with a dfiierent IP or sender verification on the
  other side for your own outgoing mail


It is true that it is more burden for the sender, but that is *always*  
the case with spam preventing systems



* all the dialupo RBLs are far from complete


You don't need them


* other RBLs are way too late, if someone makes it on them
  he already had sucess in send his crap out


With greylisting the RBL has time to settle


* there is no single reason for not have a sane PTR


I'm free to call my hosts as i like as long as it is a valid DNS token


* postfix has even a setting that A/PTR needs to *match*
  and if someone enables that we no longer dicuss about
  the PTR part in the reverse DNS at all


This is not related at all. With a matching PTR there is some *week*  
evidence that i'm the owner of the IP, nothing more.



See, even you don't block everyone with an offending PTR -- you
check for valid SPF or dnswl


because the intention is *not* to block mailservers
a random enduser IP i not listed in the SPF record nor on DNSWL's


We don't care about DNS names and we do not even check for matching  
PTR or SPF,DNSWL and the like and still our spam ratio reaching the  
inbox from random dial-ups is below 5%. The vast majority of spam are  
the famous freemailer like Yahoo,Hotmail,Google some hacked  
edu-accounts and the well connected SPF/PTR whatever clean spam  
centers around the world.


So no, to construct some meaning to DNS token which is not there is  
not useful at all.


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: TUNING_README: persistent write cache?

2015-02-04 Thread lst_hoe02



Zitat von Andrew Bourgeois and...@demmel.be:


Hello

What does Speed up disk updates with a large (64MB) persistent write
cache. mean (source: http://www.postfix.org/TUNING_README.html)?
Does this talk about the dirty ratio or is it something else? Google
didn't help me on this one.

Thanks in advance!

Best regards

Andrew


This allows disk updates to be sorted for optimal access speed  
without compromising file system integrity when the system crashes


That's why you need a *persistant* cache, to not loose mail and get  
decent performance.


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Using greylisting and other policies all in one. Use built in Postifx policy functions or other popular ones?

2015-01-28 Thread lst_hoe02



Zitat von srach hndls...@tutanota.de:


I have read the documents for some different Greylisting opportunities for
Postfix

This built into Postfix

http://www.postfix.org/SMTPD_POLICY_README.html#greylist

and popular ones

http://wiki.policyd.org
http://postgrey.schweikert.ch

I am not finding a modern comparison of these and a decision point for
choosing one to use best in the latest Postfix versions.  Many online
postings have a comment but they are most for older versions of Postfix.

I wonder if Postfix with modern versions is integrating better ideas and to
do it all in one?  I think maybe that the choice is not just the recommended
built in one of Postifx?  It depends on the goals?

My interested goals are to

block spam with Spamassassin
block viruses with ClamAV
greylist mail from freemail domains with one policy
greylist mail from certain countries with another policy


Don't do this. Greylisting should not be used to punish real MTAs. Use  
Greylisting with automatic whitelist so only the Spam-Bots get cut  
away and let already know MTAs pass by. Works exceptionally well here,  
the Bots go away after 2-3 tries and 90% of the sending MTAs are on  
the whitelist after some time.


Regards

Andreas



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Postfix´s sendmail command configuration

2015-01-04 Thread lst_hoe02



Zitat von m.dvo...@annkar.cz:


I have a script where sendmail command is used BUT I need to specify to
via SMTP server (espec. port) will sendmail send email.

It is simply.
marek

Marek Dvorak

email: m.dvo...@annkar.cz
tel  : 777 691 528
skype: dvorak.marek



As said the sendmail binary drop the mail in the filesystem and does  
not use TCP/IP or ports at all. If you need to transfer the mail to a  
remote next hop to a special port you can use transport maps  
(http://www.postfix.org/postconf.5.html#transport_maps).


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: enable_long_queue_ids vowels are unsafe why?

2015-01-02 Thread lst_hoe02



Zitat von li...@rhsoft.net:


Am 02.01.2015 um 17:41 schrieb lst_ho...@kwsoft.de:

Zitat von wie...@porcupine.org:


Jeffrey 'jf' Lim:

As per subject.
http://www.postfix.org/postconf.5.html#enable_long_queue_ids says:
For safety reasons the vowels (AEIOUaeiou) are excluded from the
alphabet. In what way are vowels unsafe?


Postfix should not generate offensive text such as fuckyoubastard,
neither in English nor in other languages. Removing the vowels from
the alphabet will avoid such problems with many languages.

We have been lucky that there are no reported accidents with the
old hexadecimal-style queue IDs.

   Wietse


I wonder if there are really people around who get offended by a
random generator also generating offensive text...


not people, but content scanners which look also at headers


Another point for the list why content scanner are evil...

Thanks for the hint

Andreas






smime.p7s
Description: S/MIME Cryptographic Signature

Re: enable_long_queue_ids vowels are unsafe why?

2015-01-02 Thread lst_hoe02



Zitat von wie...@porcupine.org:


Jeffrey 'jf' Lim:

As per subject.
http://www.postfix.org/postconf.5.html#enable_long_queue_ids says:
For safety reasons the vowels (AEIOUaeiou) are excluded from the
alphabet. In what way are vowels unsafe?


Postfix should not generate offensive text such as fuckyoubastard,
neither in English nor in other languages. Removing the vowels from
the alphabet will avoid such problems with many languages.

We have been lucky that there are no reported accidents with the
old hexadecimal-style queue IDs.

Wietse


I wonder if there are really people around who get offended by a  
random generator also generating offensive text...
My only concern would be that the probabilty of getting a readable  
text should be so low that i never will see anything like this if it  
is really random ;-)

And yes, i'm aware of the monkeys...

Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Why does SPF fail sometimes?

2014-12-15 Thread lst_hoe02



Zitat von James B. Byrne byrn...@harte-lyne.ca:


On Sun, December 14, 2014 20:05, Richard Damon wrote:


DMARC says that if a domain requests DMARC protection then any message
that has a RFC5322 domain pointing to it, must be verifiable as coming
from that domain, thus such an address can NOT use a 3rd party (like a
mailing list manager) to deliver a message for it without adding it to
SPF or giving it the DKIM signing keys.

Since DMARC was intended to protect high value emails, like from
something like a bank, this wouldn't normally be a problem. Effectively
emails from a DMARC protected domain shouldn't be used for non-official
communication, and any 3rd party service is presumably trusted so you
can make the needed arrangements. The problem is that YAHOO and AOL
have, via their DMARC settings, declared emails from their domain to be
this type of high value, and in effect that their users are not to use
3rd party distribution methods (but haven't told their users this).

Other mailing list systems have adopted some work arounds for this
problem, a common one is to munge the From: line to be the list
address (and setting Reply-To: to the poster), or wrapping the message
in a wrapper that is from the list, and the message to be distributed is
included as an attachment. (And some will just reject any message from a
domain that uses DMARC protection)

The problem isn't really with DMARC, it is doing what it was intended to
do, the problem is the services misusing DMARC. It sounds like if
pushed, they will even admit that they are abusing it, but feel they
need to due to a lot of messages being forged as from them.

Yes, it is arguably a violation of the RFC's to rewrite the From:
address of a message going through a mailing list manager, but it is one
of the ways to handle the misuse of DMARC that has happened. It comes
down to a question of what are you willing to do to make things work
and who are you willing to make bear the brunt of problems.



DMARC was forced upon the IETF by the big mail hosting companies.  The reason
that the FROM header is checked instead of the SENDER is because the FROM is
what virtually all MUA's display to the end user; and that is what the mail
hosting companies want verified.  Banks and other 'high value' email sources
are red-herrings.  They could care less.  Nothing of any import is ever sent
by email from a bank; Or by anyone else that has any sense (PGP/GPG/SMIME
users excepted, maybe).

DMARC is doing exactly what was expected of it by the people pushing-for /
forcing its adoption.  It is also breaking every mailing list manager exactly
as was predicted.  Mailman MLM has since had a mod made to rewrite the from
and set a few other switches to handle SPF.



So DMARC is just another piece of junk invented to break e-mail or the  
rest of it...


I don't get it why people still resist in using working solutions for  
high value e-mail like S/MIME and PGP and instead try to use  
broken-by-design solutions like SPF/DMARC whatever.


No average user understand any of this DMARC/SPF whatever cruft so  
they one day simply will use Google or Hotmail because most thers will  
also do in the hope the big ones will do something right about it.


Regards

Andreas





smime.p7s
Description: S/MIME Cryptographic Signature

Re: And Ident - port 113

2014-12-05 Thread lst_hoe02



Zitat von li...@rhsoft.net:


Am 05.12.2014 um 14:00 schrieb Robert Moskowitz:

I also have ident - port 113 open on the firewall.  But not only is it
not open on the server's firewall, I don't see a listen for it with
'netstat -na|grep113'

I do recall that ident was one thing some MTAs wanted.  Is that still
so?  And if so, should I see a listen on it?


that is all *not* postfix related and for incoming mail you don#t  
need anything than port 25


how is *that* related to mail?
http://en.wikipedia.org/wiki/Ident_protocol


There was a time some 20 years ago where E-Mail was a Unix thing only,  
where servers try to identify the remote connecting with a ident  
call and stall the connection until either succeed or timeout. This is  
ancient behaviour not seen anymore, we have disabled the reject for  
ident some 3 years ago.


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: google bouncing emails - ipv6 ptr problem?

2014-11-23 Thread lst_hoe02



Zitat von John j...@klam.ca:


On 11/22/2014 9:45 AM, Robert Schetterer wrote:

Am 22.11.2014 um 14:50 schrieb A. Schulze:

wietse:


A. Schulze:

So instead implementing strange workarounds, one should search, find,
understand and fix the real problem.

Google bounced my mail because of a temp error. I changed nothing
in my DNS or DKIM. It's their bug, not mine.

I don't expect your setup is obviously broken and also I don't want to
attack somebody. Sorry if that was misunderstood.

but in general I often notice people tend to claim it's *always*
Google's fault
which is simply not true /from my/ experience. I send 10k messages per day
to Google mx servers and never noticed such problems.
OK, maybe I'm in a magic Google whitelist because of my volume but I'm
not aware of this.


Hi Andreas , there a wide reports that google sometimes fails somehow
 with ipv6, i investigated in this hardly , it simply looks its their
bug, my best speculation goes in sometimes not working spf ipv6 stuff at
their site


Pardon me for butting in here, I am NOT a postfix expert and am  
reluctant to tell my betters what to do.


however, I had a similar problem a while back, Google would randomly  
reject email for, to me, no good reason.
It turned out that with IPv6 postfix was not consistent in binding  
an address for sending.
Google would do a RDNS lookup using the perceived address that the  
email came from, this would not resolve correctly, and Google would,  
correctly in my opinion, reject the email.


 My solution was to add smtp_bind_address stanzas to master.cf

==
smtpunix - -  n -  -  smtp
-o smtp_bind_address=74.nnn.nnn.178
-o smtp_bind_address6=2001:470:dead:beef:nn::178
==

Since making this change I have not had any problems is sending to Google.

Hope this helps

JohnA


Still not our case: We have only one IPv4 and one IPv6 address on the  
systems in question. Furthermore the PTR for the machine has exactly  
one match for IPv4 and one for IPv6, so no this isn't our problem in  
any way.


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: google bouncing emails - ipv6 ptr problem?

2014-11-22 Thread lst_hoe02



Zitat von A. Schulze s...@andreasschulze.de:


wietse:


A. Schulze:

So instead implementing strange workarounds, one should search, find,
understand and fix the real problem.


Google bounced my mail because of a temp error. I changed nothing
in my DNS or DKIM. It's their bug, not mine.


I don't expect your setup is obviously broken and also I don't want to
attack somebody. Sorry if that was misunderstood.

but in general I often notice people tend to claim it's *always*  
Google's fault

which is simply not true /from my/ experience. I send 10k messages per day
to Google mx servers and never noticed such problems.
OK, maybe I'm in a magic Google whitelist because of my volume but  
I'm not aware of this.


Andreas


Same here as Wietse said. We have not changed DNS for the mailer for  
years, but once in while if Google fail to resolve the IPv6 PTR they  
reject the mail. With the same setup to the same destination and the  
very same content some minutes later it works. This is annoying to say  
at least. Maybe you simply have been lucky until now or your DNS  
records tend to stay in the Google DNS cache for a longer time.


Regards

Andreas





smime.p7s
Description: S/MIME Cryptographic Signature

Re: google bouncing emails - ipv6 ptr problem?

2014-11-20 Thread lst_hoe02



Zitat von wie...@porcupine.org:


Robert Moskowitz:

Perhaps this should go to the bind list, but all of my checking shows my
ipv6 ptr record is working.

This started, I think, last week.  I was running an old mailserver and
sent many an email to the cubieboard list.


I had one email bounce last week. Looks like they handle DNS
timeouts badly.  I now send their mail via a transport with
soft_bonce=yes.

Wietse


I also noticed some Google mailbounces because of (temporary) IPv6 PTR  
resolve errors on their side. I now use IPv4 only to deliver to them  
and it never happend again until now.


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: TLS SNI support

2014-11-07 Thread lst_hoe02



Zitat von Michael Ströder mich...@stroeder.com:


Peter wrote:

It's pointless for MX hosts because they don't validate the certificate
anyways.


Which has to be changed.

Ciao, Michael.


http://www.postfix.org/TLS_README.html#client_tls_dane

Doesn't need SNI either...

Regards

Andreas





smime.p7s
Description: S/MIME Cryptographic Signature

Re: TLS SNI support

2014-11-07 Thread lst_hoe02



Zitat von li...@rhsoft.net:


Am 07.11.2014 um 09:35 schrieb Michael Ströder:

Peter wrote:

It's pointless for MX hosts because they don't validate the certificate
anyways.


Which has to be changed


Google: DANE and Viktors recent response in that thread

don't require SNI

my god the reason for SNI is that with pure TLS the Host-Header from  
the browser is inside the encrypted connection and that a webserver  
has different docroots for different hostnames, SNI is the fixup to  
provide the hostname before the handshake so that the webserver can  
choose the matching certificate


in context of email it is *pointless* except very rare setups which  
i would call a design error of the mail infrastructure


+1

It is always bad to add more complexity to a security technology for  
cosmetic reasons. SNI is a HTTPS thing and should stay there.


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: SPF and leboncoin.fr vs sfr.fr

2014-05-28 Thread lst_hoe02



Zitat von Daniele Nicolodi dani...@grinta.net:


On 28/05/2014 17:19, Robert Schetterer wrote:

you may set your SPF Record to

~allSoftFail


Thanks Robert, I've done that.


invest in dkim and dmarc


What advantages would that bring to me?

I implemented SPF just because otherwise the very big providers would
threat messages originating from my server as spam, and itself now is
source of troubles...


That's the problem after all. SPF/DKIM whatever is no tool against  
SPAM and should never be used that way. In fact around 80% of the spam  
we got has valid SPF and is perfectly DKIM signed. From valid mail  
only ~20% does pass such criteria. For me this looks like the big  
provider strive to exclude the smaller ones from the market.


But as always YMMV

Regards

Andreas






smime.p7s
Description: S/MIME Cryptographic Signature

Re: SPF and leboncoin.fr vs sfr.fr

2014-05-28 Thread lst_hoe02



Zitat von Benny Pedersen m...@junc.eu:


lst_ho...@kwsoft.de skrev den 2014-05-28 18:54:


But as always YMMV


if spf pass and its spam why not reject that sender domain in postfix ?

any solution always changes the problem :=)


The domains change at least once per week, the netblock every 3-6  
months but all are perfectly valid setup regarding SPF/DKIM and  
forward/reverse DNS. As they are typically at ~ 2-4 Mails per day and  
account passing our restriction at max. we can handle this by hand (-  
delete). But it stands that SPF/DKIM is not useful in preventing spam  
at all. For preventing Phishing the lacking mail client support is the  
killer. Most only display the display name and don't care of address  
or DKIM matching at all.
Beside this there is already a solution against address spoofing  
called S/MIME with some additional benefits like encryption.


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Evangelizing DNSSEC and DANE

2014-05-24 Thread lst_hoe02




Not sure if someone already noticed (in German):

http://www.heise.de/newsticker/meldung/Bund-sichert-ueberraschend-Mailtransport-per-DANE-ab-2196565.html

Looks like the german government is at least in progress of setup DANE  
for e-mail for domain bund.de


Would be a big marketing point i guess.

Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Evangelizing DNSSEC and DANE

2014-05-24 Thread lst_hoe02



Zitat von lst_ho...@kwsoft.de:


Not sure if someone already noticed (in German):

http://www.heise.de/newsticker/meldung/Bund-sichert-ueberraschend-Mailtransport-per-DANE-ab-2196565.html

Looks like the german government is at least in progress of setup  
DANE for e-mail for domain bund.de


Would be a big marketing point i guess.

Regards

Andreas


Hm, looks like a short test as of now. There are no TLSA records any more :-(

Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: SMTP STARTTLS - best practices?

2014-04-25 Thread lst_hoe02



Zitat von Viktor Dukhovni postfix-us...@dukhovni.org:


On Wed, Apr 23, 2014 at 04:54:44PM +0200, lst_ho...@kwsoft.de wrote:


Are there any experience with DNSSEC capable DNS Providers at the lower cost
range suitable for KMU?


I've not looked at the cost of full-service DNS outsourcing.  Some
of the .org registrars are quite cost-effective and have decent
DNSSEC support (I am paying $8/year for dukhovni.org and the
registrar's DNSSEC interface is an easy to use web form).



That's what we would need for .de and .com domains


We are now at a quote for ~300 Euro/month as all-inclusive-DNS (web based
management, automatic key handling, anycast etc.).


I assume that's for multiple high-traffic domains?  The tools for
self-hosting DNSSEC domains are getting better and easier to use,
so one certainly does not need to pay that kind of money unless
one needs DDoS protected DNS for multiple high-value/high-traffic
domains.


Not at all. While the provider does deliver most of this we actually  
don't need it because our traffic is rather low. We only need full  
outsourced DNS with DNSSEC and TLSA + SMIMEA records in the future.  
Unfortunately at least for the .de only a few providers offer DNSSEC  
at all and it looks they are all on the higher price side :-(


Will search a little more to see what we got.

Thanks

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Asking about heartbleed

2014-04-10 Thread lst_hoe02



Zitat von Viktor Dukhovni postfix-us...@dukhovni.org:


On Wed, Apr 09, 2014 at 05:54:33PM -0400, Victoriano Giralt wrote:


I'd like to 'hear' Wietse's and Victor's opinion on how could
this nasty bug affect a TLS service like submission?


In pretty much the same way that it applies to web services.

  * SSL/TLS Private keys may be compromised.

  * GSSAPI SASL Kerberos keys may be compromised.

  * User passwords may be compromised.

  * SSL session keys may be compromised.

  * Recently received email messages whose (partial?) content is
still in memory may be compromised.

  * ...

It is interesting to note that Postfix always wipes memory as it
is released (de-allocated) back to the heap.  So, one might think
that Postfix is safe, but the plaintext buffers that Postfix reads
from OpenSSL are allocated and deallocated by OpenSSL, not Postfix.

OpenSSL by default uses the C library malloc/free functions without
generally wiping memory passed to free().  So anything read from
a remote client may be available via this attack to a different
client.


But this only applies to clients connecting to the same smtpd/process, no?
So a attacker is not able to get sensitive data from *any* client also  
connected, but only from clients which have connected to the same  
smtpd instance in the past or global data like the private key?


I still wonder why OpenSSL does not use the memory wipe before free,  
is it a performance killer or a feature?


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Gateway Server queues too many mails

2014-02-27 Thread lst_hoe02



Zitat von Nikolaos Milas nmi...@noa.gr:


On 27/2/2014 4:40 μμ, Nikolaos Milas wrote:

Now that amavis seems to be running correctly, how can I resend  
immediately those suspended mails?


Unfortunately, I am afraid that after I run postqueue -f and  
messages were moved to the active queue, amavisd again topped CPU at  
100% and postfix started piling up again messages.


So, I restarted amavisd and messages moved again to the deferred queue.

Now,  I am thinking of temporarily removing the:

   content_filter = smtp-amavis:[127.0.0.1]:10024



You should use a process limit matching the number of amavisd  
processes to not feed it with too much concurrent smtp connections.  
Have a look how smtp-amavis is setup in master.cf, if there is no  
limit set the default (100) applies. This *could* be your problem.


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: TLS client logging PATCH

2014-02-26 Thread lst_hoe02



Zitat von Viktor Dukhovni postfix-us...@dukhovni.org:


On Wed, Feb 26, 2014 at 07:43:25AM +0100, Erwan David wrote:


 The local resolver can have the resolvers on the LAN configured as
 forwarders, but you need the local stub resolver. No reason not to have
 one, really, especially on a busy mail server.

However your local resolver could be in another jail/zone/container
(depending on your OS) with another IP address and not the loopback.

You could also have an IPSEC link to your resolver to get you trust
you use the right one. This 127.0.0.1 (or ::1) is in my sense too
restrictive, but you need a trusted link between your postfix and your
resolver.


Yes, of course.  In practice, for most users, the local resolver
is by far the simplest configuration.


Is or will this be enforced by Postfix in some way for DANE?

Regards

Andreas






smime.p7s
Description: S/MIME Cryptographic Signature

Re: TLS client logging PATCH

2014-02-26 Thread lst_hoe02



Zitat von wie...@porcupine.org:


lst_ho...@kwsoft.de:

 Yes, of course.  In practice, for most users, the local resolver
 is by far the simplest configuration.

Is or will this be enforced by Postfix in some way for DANE?


Postfix does not parse /etc/resolv.conf.

Wietse


Thanks!

Andreas



smime.p7s
Description: S/MIME Cryptographic Signature

Re: TLS client logging PATCH

2014-02-26 Thread lst_hoe02



Zitat von li...@rhsoft.net:


Am 26.02.2014 12:48, schrieb Wietse Venema:

lst_ho...@kwsoft.de:

Yes, of course.  In practice, for most users, the local resolver
is by far the simplest configuration.


Is or will this be enforced by Postfix in some way for DANE?


Postfix does not parse /etc/resolv.conf


so can we then stop to pretend having 127.0.0.1 and/or ::1 as the
only nameservers listed in /etc/resolv.conf and speak about that
it is recommended in doubt but not need if someone is knowing
what he is doing in his own trusted network?


I would say it is a strong should, very close to must. But as  
always it is nice to have a possibility to do it another way if you  
know what you do (Freedom of Config :-).


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: network is unreachable

2014-02-11 Thread lst_hoe02



Zitat von c cc sub...@gmail.com:


Hi,

All of the sudden, we can't send any email to one particular domain, and

below is the error message we got. Does anyone have any idea how to fix

this problem? Thanks!

Charles


This is the mail system at host es1.mydomain.com.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.


The mail system


myn...@mail.xxdomain.com: connect to
   xxdomain.com[2607:f220:404:8104::80e7:5a78]:25: Network is
unreachable



Looks like your IPv6 connectivity is broken. Works from here:

telnet -6 nihcesxway5.hub.nih.gov 25
Trying 2607:f220:404:8104::80e7:5a78...
Connected to nihcesxway5.hub.nih.gov.
Escape character is '^]'.
220 nihcesxway5.hub.nih.gov ESMTP
quit
221 nihcesxway5.hub.nih.gov
Connection closed by foreign host.

But not really fast, though.

Either way there are some other MXs as far as i see so your mail  
should get through (later).


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: network is unreachable

2014-02-11 Thread lst_hoe02



Zitat von c cc sub...@gmail.com:


Andreas,

Thanks for your quick reply--is there a setting in Postfix that I should
configure to fix this problem? Thanks!

Charles





You might try with IPv4 only with inet_protocols=ipv4 but you should  
first check if you can reach them by IPv4 anyway. But to really solve  
the problem you should check the network path.


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: network is unreachable

2014-02-11 Thread lst_hoe02



Zitat von c cc sub...@gmail.com:


Hi all,

Thanks for all your help.

Since we are using EC2 from Amazon and they don't support ip6 on EC2, they
recommended me to force Postfix to send email using ipV4 by changing:

 inet_protocols = all to inet_protocols = ipv4 and restart or reload Postfix

If I change to ipV4, would it create more problems for my Postfix? Once
again, thanks for your help.

Charles



You can't reach IPv6 only sites anymore, so no additional problem as  
of now. But this may change later in the century ;-)


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: International email addresses (RFC 6531)

2013-12-29 Thread lst_hoe02



Zitat von Freek Dijkstra pub...@macfreek.nl:


Hi all,

Postfix does not support international email addresses, such as
josé@example.org, as described by RFC 6530-6532.  To be precise, the
SMPTUTF8 (previously: UTF8SMTP) SMTP extension is not announced in the
EHLO response.

Wikipedia [1] says it is under development, but given the response to
the topic Question about supporting EAI in postfix about  a year ago
[2] I get the impression it is not.

Would anybody be aware of external contributions to Postfix for this
feature? I have not found anything on the web.

Regards,
Freek

[1] https://en.wikipedia.org/wiki/Extended_SMTP#SMTPUTF8
[2] http://thread.gmane.org/gmane.mail.postfix.user/234284/focus=234286


IMHO The e-Mail address is just a routeable name. For your real name  
in whatever charset you should use the real name in the header section.


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: blocked by gmail

2013-12-05 Thread lst_hoe02



Zitat von Grant emailgr...@gmail.com:


For the first time ever, 7 of my (very much legitimate) automated
messages sent to gmail users have bounced with this message:

Our system has detected that this message is likely unsolicited mail.
To reduce the amount of spam sent to Gmail this message has been
blocked. Please visit
http://support.google.com/mail/bin/answer.py?hl=enanswer=188131 for
more information.

I will delve into that link, but is there an especially good method
for avoiding this situation?

- Grant


Hi,

the spam filtering mechanisms of Google have been subject of long  
discussions on this list. The results were two-fold: While some  
blocks were found to be legitimate, others appeared truely random.  
However, one common finding is that Google's support is completely  
unresponsive.


The only conclusion I could draw from all that was that the only  
sure decision is to not use Google, and educate all their users  
that they have to expect missing mail because their provider is not  
fit for taking part in federated e-mail.


I know this is not helpful, but it is the only reliable answer  
there is. More details can be found in the archive.


Not the sort of answer I was hoping for but thank you nontheless. :)
Can I set up a feedback loop or anything of that nature with Google,
or is there truly nothing that can be done?

- Grant


You can *try* to use the hints you are given, but you are more or less  
at their mercy and some freemail provider are known for don't-care  
attitude. We have some similar examples with AOL and Outlook.com.  
While AOL finally resolved the issue, we never got any feedback from  
Outlook.com and the problem still persists. I finally give up on it  
because after all the *recipients* got what they pay for. You might  
have better luck with Google.


Regards

Andreas



smime.p7s
Description: S/MIME Cryptographic Signature

Re: server refused to talk to me: 550

2013-12-05 Thread lst_hoe02



Zitat von Matteo Cazzador mat...@netlite.it:


Hi, i've a problem causing by blacklist.
I 've a virtual postfix mail server (with smtp server sasl auth),  
when a user send a mail

using my smtp server to a specific domain i obtain:

 hostname ... server refused to talk to me: 550 Denied by policy

My problem is that the sender isn't warned of mail server error.

The sender don't receive immediatly any error message, why?

Is it possible to have immediatly error on client sender side on error 550?

Can someone help me please?

Thank's a lot.


Mail is store and forward, so your server doesn't know at time of  
submitting the mail if it can be delievered. But you client will get a  
bounce and therefore see that the delievery failed. Unfortunately  
nearly no mailclient is able to notify the user in a understandable  
way, but that a UI problem at the client side.


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Aside] Alternatives to content inspection?

2013-10-11 Thread lst_hoe02



Zitat von Robert Lopez rlopez...@gmail.com:


A recent postfix-users thread had comments (about Spamassassin) along the
lines of content inspection being evil by design. (Andreas and Stan)

In my mind content inspection would include anti-virus checking. Am I wrong?


At least my comment was in the context of spam, not malware. Even the  
human recipients sometimes have trouble to decide by content what is  
spam, so a automatic detection for such a diffuse target is doomed to  
fail. Furthermore if you don't use pre-queue filter (most content  
filter don't), you have no useful option what to do with spam-tagged  
mail.



I recognize postscreen as an effective defence. But there are other kinds
of attacks.

It seems the only thing to attempt to identify spear phishing is content
inspection. When someone takes the time and puts out the effort to target
an organization, appearing to be from that organization, I know of no other
way than to do pattern matching against email content. If I am trying the
wrong approach I would like to know.

What are the alternative that are successfully used?  Especially in the
area of Spear Phishing?


Real Spear Phishing is handcrafted special targeted, so you won't  
detect it with automatic content filters which rely on patterns and  
already known URLs and the like anyway. If the sender is able to fool  
the human recipient it is also able to fool the content filter, taken  
it is not a widspread already known attack which is also caught by  
RBL/Postscreen/Greylisting etc.


Baseline is you might gain some low additional percentage spam caught  
with a big percentage additional problems. I have seen to many mail  
silently vanish in some spam-folder to believe that content filters  
could be desireable.


But as always: YMMV

Regards

Andreas



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Solution to SMTPAuth compromised accounts.

2013-09-13 Thread lst_hoe02



Zitat von Viktor Dukhovni postfix-us...@dukhovni.org:


On Fri, Sep 13, 2013 at 11:45:54AM +0900, Jorgen Lundman wrote:


However, quite often the 3rd party involved uses software that can
use pipelining, and simply keeps sending mail, even though the
SMTPAuth account has been stopped.


What you are calling pipelining is more properly called connection
caching or message piggy-backing.  A single SMTP connection is used
to deliver multiple messages.


Naturally, we can simply restart Postfix, thereby dropping all
connections and forcing SMTPAuth again. But this is rather
undesirable, and unattractive.

Are there other solutions to consider?


With the default setting smtpd_delay_reject=yes each message is
subject to the full set of smtpd restrictions.


Can we add something similar to the smtpd_client_restrictions or
smtpd_recipient_restrictions, and adding a new rule-entry which
would simply confirm that the SMTPAuth LDAP 'user' used way back,
is still accountStatus=enabled ?


The best approach for this is a policy service call before
permit_sasl_authenticated.  The policy service can check wether
the SASL username is still valid.

Sadly Postfix does not have an access table keyed by the SASL login
name.  Perhaps we should bite the bullet, and add one, after defining
a suitable encoding for any usernames that contain special or
whitespace characters.


A workaround might be to force a mismatch with smtpd_sender_login_maps  
by removing the MAIL FROM -- Login-ID match in the table, no? But  
this only applies if reject_sender_login_mismatch could/should be used  
of course.


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: EDH Ciphers

2013-08-14 Thread lst_hoe02



Zitat von Ralf Hildebrandt r...@sys4.de:


What exactly are the prerequisites for preferring EDH ciphers in
Postfix?

* Do I need ECC (and thus OpenSSL = 1.0.0) or not?


For EDH no, for ECDHE yes


* Do I need tls_preempt_cipherlist = yes, and thus Postfix 2.8.0 or not?


This let the *server* (Postfix) choose a cipher suggested by the  
client, so it depends. If the client has no DH ciphers it doesn't  
help, if the client list DH ciphers later in the list Postfix can  
choose the DH ciphers that way. If the client has DH ciphers first in  
the list it is not necessary.


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: delivery status notification (DNS)

2013-07-08 Thread lst_hoe02



Zitat von Pol Hallen postfi...@fuckaround.org:


Follow official postfix page (http://www.postfix.org/DSN_README.html) I've:

smtpd_discard_ehlo_keyword_address_maps = cidr:/etc/postfix/esmtp_access

cat /etc/postfix/esmtp_access
# Allow DSN requests from local subnet only
192.168.1.0/24  silent-discard
0.0.0.0/0   silent-discard, dsn
::/0silent-discard, dsn


I've small lan on 192.168.1.0 and all clients uses a single smtp postfix
server.

On clients, send the emails with delivery status notification option.

After sent, postfix send me a delivery status notification:

Successful Mail Delivery Report

but that email is within postfix queue (why I stopped destination over
internet smtp server - purpose test).

So, my postfix server always send a delivery status notification also if
there's a transmission problem.

What's the error?


Do you have a AV scanner or some other after queue content filter? If  
yes postfix is maybe telling you that the message has been transfered  
to this next hop. IMHO you should ditch DSN because no one is  
using/allowing it anyway, so trying to get it right is a fruitless  
effort.


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Is this an attack?

2013-06-19 Thread lst_hoe02



Zitat von Andreas Kasenides andr...@cymail.eu:

One of my mail servers (postfix 2.6) has been target of what seems  
to me to be an attack.
The attacker tried to deliver messages to a non-existent user names  
formed as a long hex
string. It only happened once from one particular client and kept  
going for some time.
SMTP sessions were coming in one every second with three delivery  
attampts each.

Here is a fragment of one single session:

 Out: 220 prot..eu ESMTP Postfix
 In:  EHLO xx
 Out: 250-prot..eu
 Out: 250-PIPELINING
 Out: 250-SIZE 1024
 Out: 250-VRFY
 Out: 250-ETRN
 Out: 250-ENHANCEDSTATUSCODES
 Out: 250-8BITMIME
 Out: 250 DSN
 In:  MAIL FROM:x...@xx.xxx.xx SIZE=2881 BODY=7BIT
 Out: 250 2.1.0 Ok
 In:  RCPT TO:35150aa4c74ba30f04ede17ca25f1...@.yy
 Out: 451 4.3.0 35150aa4c74ba30f04ede17ca25f1...@.yy: Temporary lookup
 failure
 In:  RCPT TO:357f21a54e272af6a629ff7657eae...@.yy
 Out: 451 4.3.0 357f21a54e272af6a629ff7657eae...@.yy: Temporary lookup
 failure
 In:  RSET
 Out: 250 2.0.0 Ok
 In:  MAIL FROM:xx...@xx.xxx.xx SIZE=2881 BODY=7BIT
 Out: 250 2.1.0 Ok
 In:  RCPT TO:947a7c9627f3977247586a4fca58b...@.yy
 Out: 451 4.3.0 947a7c9627f3977247586a4fca58b...@x.yy: Temporary lookup
 failure
 In:  QUIT
 Out: 221 2.0.0 Bye

Is this an attack of some sort?


The address harvester of the spammers sometimes collect everything  
which has a @ in it and therefore even use message-ids in their  
spamlist.


Nothing to worry about

Regards

Andreas





smime.p7s
Description: S/MIME Cryptographic Signature

Re: Multiple owners in smtpd_sender_login_maps

2013-04-19 Thread lst_hoe02



Zitat von Ram r...@netcore.co.in:

I have a requirement of 2 different users  using the same sender  
email address


I found a very old patch for doing this in postfix.
http://permalink.gmane.org/gmane.mail.postfix.devel/4

Is this patch still the only way of doing multiple owners



Not sure why you like to patch. From the documentation:

In all cases the result of table lookup must be either not found or  
a list of SASL login names separated by comma and/or whitespace


So simply doing

localpart@mailaddress   login-name1, login-name2

in the lookup table should do the trick.

Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Temporary lookup failure with relay_recipient_maps

2013-03-07 Thread lst_hoe02



Zitat von Viktor Dukhovni postfix-us...@dukhovni.org:


On Wed, Mar 06, 2013 at 06:13:05PM +, lst_ho...@kwsoft.de wrote:


Zitat von Wietse Venema wie...@porcupine.org:

Postfix reports that the LDAP client library could not connect to
any of the LDAP servers. Don't shoot the messenger.

Wietse

Would the domain parameter in the LDAP config prevent this, if
only non-matching addresses would have been asked or does postfix
detect the absence of the LDAP servers anyway?


[ I'll play Wietse, since the LDAP connection management logic is my code. ]

Postfix (unsupported ancient versions aside) only connects to the
LDAP server when it is about to make a query.  The non-matching
domain short-circuit happens before any connection attempts.

--
Viktor.


Thanks for confirming. So this would be the solution the OP was  
looking for, given that only full qualified LDAP lookups are used.


Regards

Andreas

Re: Temporary lookup failure with relay_recipient_maps

2013-03-06 Thread lst_hoe02



Zitat von Wietse Venema wie...@porcupine.org:


Alvaro Marin:

For a moment, one ActiveDirectory server for some domains was down, so
I've seen in logs:

warning: dict_ldap_connect: Unable to bind to server ldap://IP1
ldap://IP2 as cn=x,ou=x,dc=x,dc=x: -1 (Can't contact LDAP server)

...

Is anyway to configure Postfix to avoid this situation? If one LDAP/AD
of the configuration of relay_recipient_maps is down, query other
servers and give that failure error only for domains configured in the
down server.


Postfix reports that the LDAP client library could not connect to
any of the LDAP servers. Don't shoot the messenger.

Wietse


Would the domain parameter in the LDAP config prevent this, if only  
non-matching addresses would have been asked or does postfix detect  
the absence of the LDAP servers anyway?
Just curious, the real solution is more of using at least two LDAP  
server per config and don't kill both of them at once.


Regards

Andreas

Re: avoiding overload on port 587



Zitat von Tomas Macek ma...@fortech.cz:

I don't understand now, how Postfix behaves when listenting on  
submission port 587.
Our mailserver is sometimes overloaded on port 25, so we want to use  
postscreen. But I don't understand, how Postfix works when it's  
stressed on port 587, when spammers connect to that opened port and  
want send their emails. In document  
http://www.postfix.org/STRESS_README.html there is:


NOTE: To avoid overload delays for end-user mail clients, enable  
the submission service entry in master.cf (present since Postfix  
2.1), and tell users to connect to this instead of the public SMTP  
service.


Should this mean, that Postfix by default does not use counters like  
smtpd_hard_error_limit, smtpd_junk_command_limit and maybe others on  
sumission port? On this port I would prefer using some kind of smtp  
auth and this port should be world accessible to allow the clients  
using other networks to authenticate and send emails.




Port 587 is by default nothing special for Postfix because it is  
mostly a clone of the Port 25 service. The *intended* difference is  
that Port 587 should only accept mail by authenticated users, so no  
chance for spammers if they don't own valid credentials. To actually  
see the difference between Port 25 and Port 587 settings you have to  
compare the entries in master.cf.


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: avoiding overload on port 587



Zitat von Tomas Macek ma...@fortech.cz:


On Fri, 30 Nov 2012, lst_ho...@kwsoft.de wrote:



Zitat von Tomas Macek ma...@fortech.cz:

I don't understand now, how Postfix behaves when listenting on  
submission port 587.
Our mailserver is sometimes overloaded on port 25, so we want to  
use postscreen. But I don't understand, how Postfix works when  
it's stressed on port 587, when spammers connect to that opened  
port and want send their emails. In document  
http://www.postfix.org/STRESS_README.html there is:


NOTE: To avoid overload delays for end-user mail clients, enable  
the submission service entry in master.cf (present since Postfix  
2.1), and tell users to connect to this instead of the public SMTP  
service.


Should this mean, that Postfix by default does not use counters  
like smtpd_hard_error_limit, smtpd_junk_command_limit and maybe  
others on sumission port? On this port I would prefer using some  
kind of smtp auth and this port should be world accessible to  
allow the clients using other networks to authenticate and send  
emails.




Port 587 is by default nothing special for Postfix because it is  
mostly a clone of the Port 25 service. The *intended* difference is  
that Port 587 should only accept mail by authenticated users, so no  
chance for spammers if they don't own valid credentials. To  
actually see the difference between Port 25 and Port 587 settings  
you have to compare the entries in master.cf.


Regards

Andreas



OK, so there is a chance for spammers to overload the server using  
submission port 587 (the server says then service smtp (25) has
reached its process limit 200) by exhausting number of available  
ports and the MUA clients then can have also problems to send their

emails? I'm I right?


The number of available ports is a OS thing, Postfix can be configured  
in master.cf the not allow more than maxproc-column service processes  
*per service*. So if you have 200 maxproc for Port 25 and another 200  
for Port 587 your OS must be able to handle at least 400 connections  
(open ports, fds etc.). If 200 are reached at Port 25 Postfix will  
still accept up until 200 connections on Port 587, but refuses any  
further connections on Port 25.


If I'm, then I don't understand, why to split the processes into  
submission 587 and normal 25, because if the MUA client send the mail
through 25 (hope with postscreen), there is a chance that the 25 is  
not overloaded (because it uses postscreen) and he will be rather

able to send his email compared to 587.
Or I don't still understand something ... :-)


No, MUA should use Port 587 and *authentication*. Port 25 is for MTA  
--- MTA transfer *without* authentication. It does work to use Port  
25 with MUA but it is not recommended these days. Postscreen is able  
to prevent some spammer connections to actually allocate one of this  
200 port 25 processes so the boundery is higher but still applies.


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: avoiding overload on port 587



Zitat von Tomas Macek ma...@fortech.cz:


On Fri, 30 Nov 2012, lst_ho...@kwsoft.de wrote:



Zitat von Tomas Macek ma...@fortech.cz:


On Fri, 30 Nov 2012, lst_ho...@kwsoft.de wrote:



Zitat von Tomas Macek ma...@fortech.cz:

I don't understand now, how Postfix behaves when listenting on  
submission port 587.
Our mailserver is sometimes overloaded on port 25, so we want to  
use postscreen. But I don't understand, how Postfix works when  
it's stressed on port 587, when spammers connect to that opened  
port and want send their emails. In document  
http://www.postfix.org/STRESS_README.html there is:


NOTE: To avoid overload delays for end-user mail clients,  
enable the submission service entry in master.cf (present  
since Postfix 2.1), and tell users to connect to this instead of  
the public SMTP service.


Should this mean, that Postfix by default does not use counters  
like smtpd_hard_error_limit, smtpd_junk_command_limit and maybe  
others on sumission port? On this port I would prefer using some  
kind of smtp auth and this port should be world accessible to  
allow the clients using other networks to authenticate and send  
emails.




Port 587 is by default nothing special for Postfix because it is  
mostly a clone of the Port 25 service. The *intended* difference  
is that Port 587 should only accept mail by authenticated users,  
so no chance for spammers if they don't own valid credentials. To  
actually see the difference between Port 25 and Port 587 settings  
you have to compare the entries in master.cf.


Regards

Andreas



OK, so there is a chance for spammers to overload the server using  
submission port 587 (the server says then service smtp (25) has
reached its process limit 200) by exhausting number of  
available ports and the MUA clients then can have also problems to  
send their

emails? I'm I right?


The number of available ports is a OS thing, Postfix can be  
configured in master.cf the not allow more than maxproc-column  
service processes *per service*. So if you have 200 maxproc for  
Port 25 and another 200 for Port 587 your OS must be able to handle  
at least 400 connections (open ports, fds etc.). If 200 are reached  
at Port 25 Postfix will still accept up until 200 connections on  
Port 587, but refuses any further connections on Port 25.


According to the doc:
It works as follows. When a public network service such as the  
SMTP server runs into an all server ports are busy condition, the  
Postfix master(8) daemon logs a warning, restarts the service  
(without interrupting existing network sessions), and runs the  
service with -o stress=yes on the server process command line:


Just see all server ports are busy: what means the ports?  
Because I experieced the stress=yes at smtpd processes, when just  
121 smtpd processes were running that time.




So if you have the default max of 100 smtp port 25 service process  
Postfix will restart the port 25 service with stress=yes to kick in  
more aggressive timeouts to faster free up processes. This has nothing  
todo with the service for port 587.


If I'm, then I don't understand, why to split the processes into  
submission 587 and normal 25, because if the MUA client send the  
mail
through 25 (hope with postscreen), there is a chance that the 25  
is not overloaded (because it uses postscreen) and he will be rather

able to send his email compared to 587.
Or I don't still understand something ... :-)


No, MUA should use Port 587 and *authentication*. Port 25 is for  
MTA --- MTA transfer *without* authentication. It does work to  
use Port 25 with MUA but it is not recommended these days.  
Postscreen is able to prevent some spammer connections to actually  
allocate one of this 200 port 25 processes so the boundery is  
higher but still applies.


Andreas


Yes, I understand this well and know about it and this is what I  
want. But don't undrestand howto avoid overloading the server, when  
spammers will try to connect and send their mails to the port 587.
If the Postfix's behaviour on port 587 is the same as with 25, it  
seems to me to be better to let the MUAs to send their mail to 25.  
In the postscreen the mynetworks are automatically whitelisted and  
on 25 they have better chance to send their mails, because 25 should  
not be overloaded because of postscreen used.


Using firewall on 587 is useless, because our clients travel with  
their computers even around Europe and want to send their mails.


There is no benefit for spammers to direct to Port 587 if you only  
allow authenticated mail submission at that port as you should and  
there is no widely used here is my submission port announcement as  
it is with port 25 per MX records in DNS. Port 587 has independant  
settings and limits and is *not* tied to port 25 settings. It is  
possible that port 587 resources are also tied up because of  
dictionary attack or DoS but this can be tackled by limiting  
connections per client and maybe

Re: avoiding overload on port 587



Zitat von Tomas Macek ma...@fortech.cz:


On Fri, 30 Nov 2012, lst_ho...@kwsoft.de wrote:



Zitat von Tomas Macek ma...@fortech.cz:


On Fri, 30 Nov 2012, lst_ho...@kwsoft.de wrote:



Zitat von Tomas Macek ma...@fortech.cz:


On Fri, 30 Nov 2012, lst_ho...@kwsoft.de wrote:



Zitat von Tomas Macek ma...@fortech.cz:

I don't understand now, how Postfix behaves when listenting on  
submission port 587.
Our mailserver is sometimes overloaded on port 25, so we want  
to use postscreen. But I don't understand, how Postfix works  
when it's stressed on port 587, when spammers connect to that  
opened port and want send their emails. In document  
http://www.postfix.org/STRESS_README.html there is:


NOTE: To avoid overload delays for end-user mail clients,  
enable the submission service entry in master.cf (present  
since Postfix 2.1), and tell users to connect to this instead  
of the public SMTP service.


Should this mean, that Postfix by default does not use  
counters like smtpd_hard_error_limit, smtpd_junk_command_limit  
and maybe others on sumission port? On this port I would  
prefer using some kind of smtp auth and this port should be  
world accessible to allow the clients using other networks to  
authenticate and send emails.




Port 587 is by default nothing special for Postfix because it  
is mostly a clone of the Port 25 service. The *intended*  
difference is that Port 587 should only accept mail by  
authenticated users, so no chance for spammers if they don't  
own valid credentials. To actually see the difference between  
Port 25 and Port 587 settings you have to compare the entries  
in master.cf.


Regards

Andreas



OK, so there is a chance for spammers to overload the server  
using submission port 587 (the server says then service smtp  
(25) has
reached its process limit 200) by exhausting number of  
available ports and the MUA clients then can have also problems  
to send their

emails? I'm I right?


The number of available ports is a OS thing, Postfix can be  
configured in master.cf the not allow more than maxproc-column  
service processes *per service*. So if you have 200 maxproc for  
Port 25 and another 200 for Port 587 your OS must be able to  
handle at least 400 connections (open ports, fds etc.). If 200  
are reached at Port 25 Postfix will still accept up until 200  
connections on Port 587, but refuses any further connections on  
Port 25.


According to the doc:
It works as follows. When a public network service such as the  
SMTP server runs into an all server ports are busy condition,  
the Postfix master(8) daemon logs a warning, restarts the service  
(without interrupting existing network sessions), and runs the  
service with -o stress=yes on the server process command line:


Just see all server ports are busy: what means the ports?  
Because I experieced the stress=yes at smtpd processes, when just  
121 smtpd processes were running that time.




So if you have the default max of 100 smtp port 25 service process  
Postfix will restart the port 25 service with stress=yes to kick in  
more aggressive timeouts to faster free up processes. This has  
nothing todo with the service for port 587.


There is still one thing, that I don't understand: when exactly the  
postfix says that he is not stressed and restarts the processes with  
stress=no?
This is not done when less then default_process_limit smtpd  
processes are run, because I experienced on my system  
(default_process_limit = 200), that smtpd with stress=yes were run  
when there were just 121 smtpd's run in total. Strange?




http://www.postfix.org/STRESS_README.html




If I'm, then I don't understand, why to split

the processes into

submission 587 and normal 25, because if the MUA client send the mail
through 25 (hope with postscreen), there is a chance that the 25  
is not overloaded (because it uses postscreen) and he will be  
rather

able to send his email compared to 587.
Or I don't still understand something ... :-)


No, MUA should use Port 587 and *authentication*. Port 25 is for  
MTA --- MTA transfer *without* authentication. It does work to  
use Port 25 with MUA but it is not recommended these days.  
Postscreen is able to prevent some spammer connections to  
actually allocate one of this 200 port 25 processes so the  
boundery is higher but still applies.


Andreas


Yes, I understand this well and know about it and this is what I  
want. But don't undrestand howto avoid overloading the server,  
when spammers will try to connect and send their mails to the port  
587.
If the Postfix's behaviour on port 587 is the same as with 25, it  
seems to me to be better to let the MUAs to send their mail to 25.  
In the postscreen the mynetworks are automatically whitelisted and  
on 25 they have better chance to send their mails, because 25  
should not be overloaded because of postscreen used.


Using firewall on 587 is useless, because our clients travel with  
their computers even

Re: [OT] SPF - Do you use it

2012-10-05 Thread lst_hoe02



Zitat von Titanus Eramius tita...@aptget.dk:


Slightly off topic. I hope it's OK when the mail is marked as such.

I was just wondering if the users of this list use SPF in any way, and
if so, to what extend?


We have considered SPF some five years ago but after second thought  
ditched it completely:


- It dos not really help against spam because the spam-farms also can  
set proper SPF


- It is not really useful for prove-of-sender because no MUA care about

- It does not add any aditional security/reliability to e-mail

- There are problems with forwarding

Instead we have installed a S/MIME Gateway which solve the  
prove-of-sender with additional benefits of making encrypted mail  
possible.


But as always YMMV

Regards

Andreas





smime.p7s
Description: S/MIME Cryptographic Signature

Re: [OT] SPF - Do you use it

2012-10-05 Thread lst_hoe02



Zitat von Reindl Harald h.rei...@thelounge.net:


Am 05.10.2012 16:04, schrieb lst_ho...@kwsoft.de:


Zitat von Titanus Eramius tita...@aptget.dk:


Slightly off topic. I hope it's OK when the mail is marked as such.

I was just wondering if the users of this list use SPF in any way, and
if so, to what extend?


We have considered SPF some five years ago but after second thought  
ditched it completely:


- It dos not really help against spam because the spam-farms also  
can set proper SPF


this point is simply wrong

a spam-farm CAN NOT set a SPF that whatever ip is allowed
to send mails with my envelope - simply because they are not
the dns-admin of my zones


SPF is NOT a spam-protection

it is designed to prevent forged sender-addresses which in
the worst case results in multiple auto-replies between
completly univolved persons which may over-react and
start blacklisting servers which are not the root-cause

the real problem is that not EVERY domain has SPF records
and that is why it doe snot help as much as it could, you
are part of this problem because ANYBODY can send me spam
with yur sender-address and only blacklists and bayesian
filters prevents my server to send you auto-replies for
such messages if i am at vacation


This is your opinion. Mine is i don't care what sender-addresses spam  
has but i care about preventing spam from reaching end users. The most  
spam we see are from well connected spam-farms with their own  
throw-away domains and proper SPF/DKIM set. So no, SPF/DKIM is not  
useful for us in any way but certainly you are free to use it the way  
you like and as long as you like.


Regards

Andreas







smime.p7s
Description: S/MIME Cryptographic Signature

Re: [OT] SPF - Do you use it

2012-10-05 Thread lst_hoe02



Zitat von Wietse Venema wie...@porcupine.org:


Alumno Etsii:

As far as I'm concerned, SPF is not an anti-spam tool, but an anti-forgery
tool.


I'm ending this discussion before the flames flare up.

Let's suffice with the following observation:

SPF helps a sender and receiver who know each other. Otherwise
it helps no-one.

The same holds for any system that relies on sender-provided
policy information including DKIM.

Wietse


+1

and my last post on this subject.

Regards

Andreas





smime.p7s
Description: S/MIME Cryptographic Signature

Re: OT: postfix configuration comments

2012-08-24 Thread lst_hoe02



Zitat von Reindl Harald h.rei...@thelounge.net:


Am 24.08.2012 11:09, schrieb Hari Hendaryanto:

On 8/24/2012 3:30 PM, Reindl Harald wrote:


Am 24.08.2012 05:57, schrieb Hari Hendaryanto:
it's not really  a problem, just  my curiosity. I wonder why  
Postfix does not support comments such as //

comments  or /* comments */ in configuration file.
is there any specific reason why those features not allowed/exist?

because it supports bash-like
# this is my comment


i'm afraid i've already known that for years , that's why i'm asking.. :)


so why do you need // too?

wasted code to support every comment-style of any programming language


In more friendly words: The other comment styles are not there because  
until now no one needed it that urgent to do the coding/testing and  
documentation work.


Regards

Andreas





smime.p7s
Description: S/MIME Cryptographic Signature

Re: high-speed postfix configuration

2012-08-23 Thread lst_hoe02



Zitat von Mike Mitchell m...@mitchellzone.org:

We've actually been providing this service for 10 years now, but are  
just now reaching a scale where default configurations are  
insufficient to handle the volume.   We've not needed to touch the  
mail server prior to now, so are just looking for some initial  
guidance as we dig into optimization.


I understand that it's a complex equation, and stated as much in my  
post.  My statement about unpredictable domains was not completely  
accurate--in reality, the vast majority of users will be on private  
MX domains, and we do have relationships with the operators of these  
to whitelist us through.  My point was that we don't know in advance  
when messages will be sent to each domain.  The danger that we'll  
run into trouble with commercial email services is very low.  And we  
do have sys admin experience and own our own servers, so if file  
system optimization is necessary, we can do that, too.


I'm hesitant to chastise someone like Wietse following my very first  
post to the list, but I'm trying to learn from you guys here and do  
this in the best possible way for my customers and everyone else we  
could potentially impact.  How does it help the situation to  
critique the ability of my organization or our experience in using  
the software, instead of answering the question?  If it's possible  
to provide a more objective response, it would be much appreciated,  
thanks.


/mike


On Aug 23, 2012, at 2:00 PM, Wietse Venema wie...@porcupine.org wrote:


Really, this is not something that one should do without prior
experience in the field. There are issues ranging from local file
system load management, to preventing that major mail operators
will drop your connections or discard your messages.

Wietse


Hello

you start your post with Newbie in the first line and ask for help  
on high throughput mailservers. This is a common sign for trouble  
because Newbie lack the insight how to balance the different set  
screws. Furthermore the most difficult part is not the sending side  
but the receiving end. What you might check on your side:


- Proper and fast (forward and reverse) NS for you sending IPs
- Fast nearby caching resolver
- Fast filesystem where your mails come from
- Really fast syslog with buffered writes which does not slow down  
your mailspool


Also have a look here:
http://www.postfix.org/TUNING_README.html
http://www.postfix.org/QSHAPE_README.html

Regards

Andreas









smime.p7s
Description: S/MIME Cryptographic Signature

Re: ..::Rbl not working::..

2012-08-21 Thread lst_hoe02



Zitat von Alfonso Alejandro Reyes Jiménez are...@ibossmonitor.com:


On 8/21/12 9:57 AM, Ralf Hildebrandt wrote:

* Alfonso Alejandro Reyes Jiménezare...@ibossmonitor.com:


Thanks it seems to be an issue with spamhaus, here's the result:

[root@mail ~]# host 107.178.203.192.zen.spamhaus.org
Host 107.178.203.192.zen.spamhaus.org not found: 3(NXDOMAIN)
[root@mail ~]#

Use a proper DNS server (like somebody on this thread already suggested)

Thanks as I was telling I have one, but I think the issue is with  
the forwarding it's been made to a public dns server. Should I  
change it to a particular one? (ex spamhaus)


Note that public recursor like for example 8.8.8.8 typically exceed  
the limit of queries spamhaus is willing to accept per source and are  
therefore blocked. For RBL queries you really should not use a public  
forwarder.


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: The ultimate email server

2012-08-15 Thread lst_hoe02



Zitat von Mikkel Bang facebookman...@gmail.com:


I'm trying to configure the ultimate email server for this webapp that
needs to send and receive / forward emails to and from thousands of users.

But with so many people recommending so many different tools, it gets hard
to come to a conclusion. Looks like I'm finally arriving at this though:
postfix (postfix-anti-UCE.txt) + dspam - what do you guys think?


There is no ulimate email server because it all depends...



Dropped:

- postscreen: Looked into http://www.postfix.org/POSTSCREEN_README.html but
couldn't really find anything concrete to add to my setup


If you are suspecting Spam-Bots hammering your server you really  
should use Postscreen. If your traffic is really low you can exclude it.



- postgrey: Advised against by the dudes in Freenode #postfix - I've tried
it before and it was really effective, but I don't think my users will like
that 5 minute delay


The delay is adjustable and there is a useful feature called automatic  
whitelist.



- opendkim+spf+dmarc: Advised against by the dudes in Freenode ##freebsd,
saying its role in anti-spam protection is minimal


It might be useful when sending to Hotmail/Yahoo, but you can easily  
live without.



- spamassassin: Too old, too huge and too hard to set up (but maybe those
who advised against it had more against Perl than anything else)


Content Filter are heavy processing but used with tagging/folders can  
cut a lot more spam.



- spamdb+greytrapping: Not necessary if I'm already running dspam


Don't know at all


- mailscanner: Not necessary if I'm already running dspam


Mailscanner is not supported with Postfix (http://www.postfix.org/addon.html)


Regards

Andreas



smime.p7s
Description: S/MIME Cryptographic Signature

Re: virtual mailboxes BUT NOT virtual domain

2012-05-02 Thread lst_hoe02



Zitat von The Eye mhell...@in-ulm.de:


On Wed, May 02, 2012 at 07:05:03AM -0400, Wietse Venema wrote:

Michael Hellwig:
 I've been butting my head against this one for quite some time now.

You might want to read this document:

http://www.postfix.org/ADDRESS_CLASS_README.html

This decribes what is needed to avoid user unknown and relay access
denied errors.

After this, setting up a suitable virtual_transport in main.cf
becomes a minor detail.



Well maybe I'm really dense now, but when I look at that document, I
still see that virtual mailboxes are supposed to be on their own domain,
NOT on the same domain as the local users, given that the distinction
between the two types of mailboxes is made via the domain?

Or do I misunderstand something?


If you want to mix local and virtual delivery in the same external  
maildomain you have to split them and rewrite the mail routing  
information in the envelope. Something like this for example


user1@domain - virtual1@domain
user2@domain - local1@local.servername

and route the mail with transport maps as intended.

Regards

Andreas





smime.p7s
Description: S/MIME Cryptographic Signature

Re: IPv6 to IPv4 fallback mechanism

2012-04-20 Thread lst_hoe02



Zitat von Fernando Gozalo fgoz...@csi.uned.es:


Hi,

does the postfix smtp client implement the IPv6 to IPv4 fallback  
mechanism as browsers do?


Postfix uses the fallback mechanism SMTP provides. It connects the MX  
with lowest priority at IPv6 if available and proceed to the next IPv6  
or IPv4 address available if it fails. So if you have one MX with   
and A record Postfix client would try  first on most OS and if it  
fails proceed with A records.


Regards

Andreas

Re: postgrey outgoing mail whitelister

2012-04-18 Thread lst_hoe02


Zitat von /dev/rob0 r...@gmx.co.uk:


On Wed, Apr 18, 2012 at 04:33:31AM +0300, Henrik K wrote:

Still, is it too much to ask for looking at
things from many angles or backing up claims with any kind of
statistics or science instead of personal gut feelings?


Where/how would one collect such data? My mail stream differs from
yours, as does my spam problem. The best, meticulously gathered
statistics from one site won't be applicable to another site.

Unfortunately the gut is what we have. My gut feeling is that SPF
lookups are the surest way to make this scheme work without causing
some kind of problem. Yes, my MX is also the outbound relay, but at
bigger sites this is less likely.

Another gut feeling: greylisting is past its prime. I do it using
postscreen, but I sometimes consider disabling the deep protocol
tests. The DNSBL scoring system is what blocks most of my spam.


And that's how the gut feelings are differ. On our site greylisting  
is by far the most effective spam-block. For a long time we had  
problems because the RBL listings for spam sources only appear after  
they have dropped their spam to us, so pure RBL/DNSBL is near useless  
for us. With greylisting a big share of the spam bots don't come back  
anyway and the ones operate longer are finally listed in the RBLs at  
the time they would pass greylisting. Combined with a big automatic  
whitelist the negative impact from greylisting is near zero because  
all business partners and the like are whitelisted.


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: postgrey outgoing mail whitelister

2012-04-17 Thread lst_hoe02



Zitat von Reindl Harald h.rei...@thelounge.net:


Am 17.04.2012 13:43, schrieb Henrik K:

Hopefully by now people realize that your practical expierience
is questionable.


my practical expierience is managing some hundret domains
with  15.000 RCPT since years - so stop your idiotic
personal attacks while nobody attacked you until you
creeped out of your hole and replied to a message
which was not sent as reply to one of yours


Calm down boys. The world is not true/false but mostly it depends.  
If you really insist in pissing contest take it somewhere else, most  
of us don't care.


Andreas

Re: Postfix can not resolve the ip-address



Zitat von Руслан Шарипов ufa...@gmail.com:


Hello.

Postfix can not resolve the IP-address, but the nameserver is
configured correctly.

See, in mail.log:
root@mail2:/var/log# tail -3 mail.log
Apr 16 02:35:44 mail2 postfix/smtpd[1855]: connect from  
unknown[209.85.215.53]

Apr 16 02:35:45 mail2 postfix/smtpd[1855]: NOQUEUE: reject: RCPT from
unknown[209.85.215.53]: 450 4.7.1 Client host rejected: cannot find
your hostname, [209.85.215.53]; from=@gmail.com to=@*
proto=ESMTP helo=mail-lpp01m010-f53.google.com
Apr 16 02:35:45 mail2 postfix/smtpd[1855]: disconnect from
unknown[209.85.215.53]

But in fact (execute in the console on the same server):
root@mail2:/var/log# host 209.85.215.53
53.215.85.209.in-addr.arpa domain name pointer mail-lpp01m010-f53.google.com.
That is, PTR-record for the IP-address is correct.

Question: Why Postfix can not resolve the IP-address?


smtpd chrooted with out-of-sync resolv.conf?
temporaery DNS problem?

The reject was a temp-fail (450 code) so the client should retry  
later. What was the result for the later try?


Regards

Andreas

Re: Postfix and Flood Spamming



Zitat von Stephane Wirtel stephane.wir...@gmail.com:


Dear Postfix Jedi,

I need your help to secure a new postfix server against the SPAM flooding.

Currently I have an old postfix based on an old debian server and since
some days, my server is subject to the SPAM flooding (+- 50k mails/hours).


What do you mean by 50K mails/hour?
Do the mails really enter your Postfix queue?
Do you mean connection attempts?


So, I have decided to reconfigure a new server with an updated
distribution, because the old distribution is not supported by debian (too
old).

For this new server, I think to use
1. SASL (authentication)
2. TLS for the SMTP server.
3. use the smtpd_client_restrictions = permit_sasl_authenticated,
permit_mynetwork
4. I use pgsql server for the domains and the mailboxes.


http://www.postfix.org/pgsql_table.5.html
Have a look at the domain setting, it could lower the pressure for  
the DB and http://www.postfix.org/proxymap.8.html for reducing the  
number of connections to the DB.



5. postgrey and some rbl servers


Be sure to configure postgrey to tailor your needs, the defaults are  
not optimal for all cases.



I have some questions,
1. is it enough ? (I think no, but if you have advice, I'm very interested)


Carefully configured it could be enough. You might need to setup a  
personal blocklist for your favorite Spam net not included in the  
RBLs.



2. do you know some secure and efficient rbl servers ?


Have a look at multirbl.valli.org for example and be sure to read and  
understand the operation statement of the RBLs you like to choose.  
Also check if the DNS latency to this RBLs are low.



3. Do I have to use SPF in my ns ?


SPF does nothing about your incoming Spam load, it might help for  
delivery problems to some destinations like Hotmail.


Regards

Andreas

Re: Postfix and Flood Spamming



Zitat von Stéphane Wirtel stephane.wir...@gmail.com:


Hi Stan,

On 04/16/2012 01:27 PM, Stan Hoeppner wrote:

On 4/16/2012 4:33 AM, Stephane Wirtel wrote:

Dear Postfix Jedi,

I need your help to secure a new postfix server against the SPAM flooding.

Currently I have an old postfix based on an old debian server and since
some days, my server is subject to the SPAM flooding (+- 50k mails/hours).


How many of these 50K are entering the queue?
yes, in fact, all :( and now, I can't send an email to gmail or  
hotmail for my customers.


This sounds like your server is sending out (relaying) this crap??

This is by far a more serious issue and you should immediately  
shut-down your mailserver and check why the spam could enter the queue  
to get relayed. Using RBLs does not harden your server against  
open-relay/hacking abuse.


Regards

Andreas

Re: Postfix and Flood Spamming



Zitat von Stéphane Wirtel stephane.wir...@gmail.com:



Is there an efficient way to know if my server is blacklisted ? a reference ?


Enter the IP in question at http://multirbl.valli.org/ is one possibility

Regards

Andreas

Re: Multiple SSL certs on multiple IPs