Re: block spam mail from lan

[li...@rhsoft.net]

Am 11.05.2013 14:34, schrieb Pol Hallen:
> I don't understand.
> 
> Situation: A real user using browser connect to squirrelmail and send a
> mail. It's ok.
> 
> But if this user create a mail bomb using squirrelmail how way to spam I
> can have this problem

well, nothing can really prevent you from bad users with valid logins
you can only mitigate the amount of spam until you recognize what
happens and you shut down the user account

the problem with webmail and such limitations is that you have
always the same client-ip and if the values are too low it
affects users which are not responsible for spam

so the solution is get rid of untrustable users and/or force
them at least to use a mail-client from their own IP/machine

anvil_rate_time_unit = 1800s
smtpd_client_connection_rate_limit = 50
smtpd_client_recipient_rate_limit = 400
smtpd_recipient_limit = 100

Re: Postfix sending issue

[li...@rhsoft.net]

Am 03.07.2013 02:34, schrieb Sam Flint:
> Jul  3 00:28:41 bell postfix/smtpd[15256]: warning: dict_nis_init: NIS domain 
> name not set - NIS lookups disabled
> Jul  3 00:28:41 bell postfix/smtpd[15256]: connect from localhost[::1]
> Jul  3 00:28:41 bell postfix/smtpd[15256]: NOQUEUE: reject: RCPT from 
> localhost[::1]: 554 5.7.1 : Relay access denied; 
> from= to= proto=ESMTP 
> helo=
> Jul  3 00:28:41 bell postfix/smtpd[15256]: lost connection after RCPT from 
> localhost[::1]
> Jul  3 00:28:41 bell postfix/smtpd[15256]: disconnect from
> localhost[::1]
> 
> The error in my mail client is:
> 
> Transaction failed
> 554 5.7.1 : Relay access denied

and why do you not simply enable authentication on your client?
the log shows pretty clear that this does not happen and
postfix *must not* accept the message as otherwise you would
have an open relay

as well your postconf shows you have confugured SASL

smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot

Re: exclude 127.0.0.1 from smtpd_tls_auth_only = yes

[li...@rhsoft.net]

Am 06.07.2013 15:46, schrieb Pol Hallen:
> Thanks all for replies :-) I use linux.
> 
> So, what should be do? I'm confused :-/
> 
> How clone submission service?

* /etc/postfix.master.cf
* copy the submission line
* change "submission" to 127.0.0.1:588
* add "-o smtpd_tls_auth_only = no" as param
* with "-o smtpd_*=value" you can override any config param
* configure the local client to use port 588 instead the normal 587

Re: Mail server, what else?

[li...@rhsoft.net]

Am 13.07.2013 20:11, schrieb Craig R. Skinner:
>> I appreciate if you can give me advise so I can further improve my system.
> 
> No Apache, PHP or webmail. HTTP was designed to transfer hyperlinked
> text files, not do dynmaic stuff with root access to the whole box.
> Beware!

in case of root access yes!

but what has the protocol HTTP to do with the underlying
application? that's a different layer and without whatever
dynamic language running on webservers you do not come very
far and you would be negatively impressed if all web-apps
you are using are down from one day to the next

Re: Mails not delivered to maildir.

[li...@rhsoft.net]

and it contains "info: postmaster" which defaults to root

>> mail from: root
>> 250 2.1.0 Ok
>> rcpt to: info
>> 250 2.1.5 Ok

*why* do you not use *full qualified* addresses for testing?

> Jul 18 21:06:34 mail postfix/local[633]: 22D9928E172F: to=, 
> orig_to=, relay=local
> seems like it should be in the user info maildir but # ls 
> /home/info/Maildir/new return total 0

how do you come to that conclusion if your quote contains 
"to=, orig_to="

Am 18.07.2013 22:54, schrieb Krzysztof Szarlej:
> Here is my aliases file http://37.187.58.245/aliases.txt 
>  
> 
> 2013/7/18 Axel Luttgens mailto:axelluttg...@swing.be>>
> 
> Le 18 juil. 2013 à 21:42, Krzysztof Szarlej a écrit :
> 
> > I am sorry for not putting postconf -n:
> >
> > [...]
> >
> > All the mails are in */root/Maildir/new* directory
> >
> > Seems like the mails are not redirected properly to the users maildirs
> 
> Hello Krzysztof,
> 
> What does your /etc/aliases file contain?

Re: Mails not delivered to maildir.

[li...@rhsoft.net]

Am 18.07.2013 23:06, schrieb Krzysztof Szarlej:
> Ok thank you guys and sorry for not reading the mailing list manual

but why then continue top-posting?

> Now it works, I deleted the alias for info. 

add "reject_non_fqdn_recipient" and "reject_non_fqdn_sender"
to "smtpd_recipient_restrictions" would bring you further

since this is for *smtp* it does not affect pickup per
(mail-command, cronjobs...) and prevents mistakes

Re: Migrate mail from one drive to another

[li...@rhsoft.net]

Am 06.08.2013 21:26, schrieb Leonardo Rodrigues:
> After syncing the folders with services stopped and configs already pointing 
> to the new places, it would be
> just a matter of getting services running again !
> 
> Downtime of maximum 3-4 minutes !!!
> 
> But watch out ... these steps would make sense only if you're using Maildir 
> mailbox format ... if you're using
> mbox, for example, syncing times would be much longer as any change would 
> require the whole file to be copied again!!

no - rsync does *not* copy whole files again

it copies only the changed parts and it is very
unlikely the a mbox fil eget changed at whole

this works even for virtual machine images where you get displayed
transfer rates up to 200 MB/second over WAN and the same for large
innodb files


http://rsync.samba.org/how-rsync-works.html

Then the local file is read and a checksum is generated for the block beginning 
with the first byte of the local
file. This block checksum is looked for in the set that was sent by the 
generator, and if no match is found, the
non-matching byte will be appended to the non-matching data and the block 
starting at the next byte will be
compared. This is what is referred to as the “rolling checksum”

If a block checksum match is found it is considered a matching block and any 
accumulated non-matching data will be
sent to the receiver followed by the offset and length in the receiver's file 
of the matching block and the block
checksum generator will be advanced to the next byte after the matching block.

Re: greylisting generates error email?

[li...@rhsoft.net]

Am 17.08.2013 19:39, schrieb Grant:
> Do you use that config on a commercial mail server?  I don't mean to
> say that you shouldn't, I'm just wondering if you do.  In a commercial
> environment, the penalty for a false positive is a customer unable to
> reach the company behind the server which just isn't tolerable

there is *no way* to have never ever false positivies

and without spam protection someone deletes your message
within the 500 spam mails each day as collateral damagae

in case of a false positive: the sender get a bounce from his mailserver
in case of deleted: it was silently dropped

chosse one.

Re: Server to Server TLS encryption?

[li...@rhsoft.net]

Am 18.08.2013 07:32, schrieb Theodotos Andreou:
> I went through the TLS Readme but I couldn't find a clear answer to the 
> following question:

surely

since postfix in this case is the *xclient* here you go
http://www.postfix.org/TLS_README.html#client_tls

> Can you configure postfix in a way that it connects using TLS to another SMTP 
> server, if TLS is available on the
> other side? For example if the destination server supports TLS then postfix 
> opens a TLS connection to it.

cat /etc/postfix/main.cf | grep smtp_ | grep tls
smtp_use_tls= yes
smtp_tls_loglevel   = 1
smtp_tls_cert_file  = 
/etc/postfix/certs/localhost.pem
smtp_tls_key_file   = 
/etc/postfix/certs/localhost.pem
smtp_tls_CAfile = 
/etc/pki/tls/certs/ca-bundle.crt
smtp_tls_security_level = may
smtp_tls_note_starttls_offer= yes
smtp_tls_session_cache_timeout  = 3600s
smtp_tls_session_cache_database = 
btree:/var/lib/postfix/smtp_scache
smtp_tls_exclude_ciphers= DES-CBC3-SHA

> Further more can this be done even if you have a self-signed certificate on 
> the destination?

yes

Re: Block certain remote hosts on submission port

[li...@rhsoft.net]

Am 22.08.2013 14:23, schrieb Charles Marcus:
> Now to figure out how to log these firewall rejections to a separate log 
> file, so I can see them if/when someone
> complains about not being able to connect

nothing easier than that

* the first rule logs with rate-control to avoid self-DOS
* the second one rejects
* the same works for any iptables rule (log-line excatly like the other rule, 
different action)

iptables -A INPUT -p tcp --dport 587 -s  -m conntrack 
--ctstate NEW -m limit --limit 1/m -j LOG
--log-level debug --log-prefix "Firewall: "
iptables -A INPUT -p tcp --dport 587 -s  -m conntrack 
--ctstate NEW -j REJECT --reject-with
icmp-admin-prohibited
___

rsyslog.conf *before* all other rules

:msg, contains, "Firewall " -/var/log/firewall.log
& ~

Re: Disable root email

[li...@rhsoft.net]

Am 23.08.2013 14:29, schrieb Roman Gelfand:
> How can I disable postfix from sending administrator email
> notifications. ie from: r...@domain.com to: r...@domain.com?

why would you want to do this?

disable the root cause producing the messages
instead break the MTA - postfix job is to send
messages it got delivered by SMTP or pickup

Re: Logging Bounces

[li...@rhsoft.net]

Am 29.08.2013 19:27, schrieb Roman Gelfand:
> Is there a way to add more info to "status=bounced" entries?  For
> instance, I would like to see the from email and subject on the same
> line.

grep for "83A7643CEB" and you get from address and all sort of details
like the sender, client-IP and infos to other RCPT's submitted with
the same transaction (if exists)

the subject is nothing which appears or should appear in the maillog
why? because it is no technical information and violates privacy

> Aug 25 11:40:27 mail postfix/smtp[22413]: 83A7643CEB:
> to=, relay=mxserver.domain.com[XX.XX.XX.XXX]:25,
> delay=0.57, delays=0/0/0.41/0.16, dsn=5.0.0, status=bounced (host
> mxserver.domain.com XX.XX.XX.XXX] said: 550 Requested action not
> taken: mailbox unavailable (in reply to RCPT TO command))

Re: newbie check Was [Re: port 25 submission settings sanity check]

[li...@rhsoft.net]

Am 29.08.2013 21:34, schrieb Glenn English:
> I'm under the impression that 587 is to be used by my local users 
> (email clients to local MTA), and 25 is used by MTA<->MTA. Is this wrong?

correct

> And /etc/services says:
> 
>> auth 113/tcp authentication tap ident
> 
> not 587...

grep for the port and not for auth :-)

submission  587/tcp msa # mail message submission

Re: Anyone use this email server configuration ?

[li...@rhsoft.net]

Am 02.09.2013 22:55, schrieb LuKreme:
> On 02 Sep 2013, at 07:10 , Littlefield, Tyler  wrote:
>> Second, you'll need to encrypt your harddrive, which I doubt this whole blog 
>> covers.
> 
> Encrypting your hard drive is trivial, at least in OS X and, I hear, even in 
> Windows. 

and after that?

I suspect it's more difficult in linux/freebsd, but I bet not much more than 
trivial

it is trivial on *every* OS
but it does help you *nothing* in reality

it does help you only if someone takes oyur hardware and is running
in *any* other case the encrypted disk is unlocked and any intrusion
has the same success as for an unencrypted devive

so why do people insist claim encrypted drives gain any security if
they are not talking about notebooks stolen in a cafe?

Re: Anyone use this email server configuration ?

[li...@rhsoft.net]

Am 02.09.2013 23:13, schrieb LuKreme:
> On 02 Sep 2013, at 15:02 , li...@rhsoft.net wrote:
> 
>> Am 02.09.2013 22:55, schrieb LuKreme:
>>> On 02 Sep 2013, at 07:10 , Littlefield, Tyler  wrote:
>>>> Second, you'll need to encrypt your harddrive, which I doubt this whole 
>>>> blog covers.
>>>
>>> Encrypting your hard drive is trivial, at least in OS X and, I hear, even 
>>> in Windows. 
>>
>> and after that?
> 
> I was making no point about the securing of mail, just about encrypting the 
> hard drive.
> 
>> it does help you *nothing* in reality
> 
> Um... no, that's not right. Encrypting drives is quite useful.

without *context* *nothing* is useful

>> so why do people insist claim encrypted drives gain any security if
>> they are not talking about notebooks stolen in a cafe?
> 
> For servers? Encrypting the drive on a always-on server seems a bit pointless

interesting argument on a *server list*

Re: mail delivery to Inbox , not to spam

[li...@rhsoft.net]

Am 11.09.2013 10:51, schrieb Vishal Agarwal:
> How can I be sure that the email send through my server to anybody should
> delivered to recipients inbox; not  to the spam folder. Where all the
> default settings are used in recipient inbox.

you as sender are not the one who decides what
at the destination happens with a message and
by whatever rules messages are flagged as spam

Re: Rejecting mail to unknown users

[li...@rhsoft.net]

Am 11.09.2013 16:52, schrieb Kris Deugau:
> Mark Goodge wrote:
>> It might help if you explained why you want to do this. What particular
>> problem is being caused by your internal users getting an error message
>> instead of a bounce?
> 
> Some idiot mail clients (*cough*ManyversionsofOutlook*cough*) don't
> actually display the SMTP error response to the user, they just pop up a
> generic "Wahh!  Can't do that!" error message

iPhones do not show the errors at all as well as ignoring the 5xx
repsonse a try over months and weeks to send the same message
every 5 minutes by stupidity

but that is no reason to generate bounces

Re: Dealing with outages

[li...@rhsoft.net]

Am 11.09.2013 20:19, schrieb Jeroen Geilman:
> On 09/09/2013 09:27 PM, Wietse Venema wrote:
>> Postfix does a hard bounce when the DNS server replies that the
>> name has no MX record AND the DNS server replies that the name has
>> no A record, AND (if Postfix IPv6 support is on) the DNS server
>> replies that the name has no  record.
> 
> Does that mean that postfix will do a hard bounce if there is no reply to an 
> MX query after a timeout ?
> I thought it would at least try the other queries (A and/or ) before 
> giving up, since this costs no more than
> when there /is/ a (negative) reply.
> 
> Since postfix may be talking to a cache or a resolver with numerous hops in 
> between postfix and the authoritative
> source, any of the queries may fail individually, and yet not be conclusive.
> 
>> Postfix does a soft bounce when any of those lookups does not produce
>> a reply.
> 
> This seems to suggest the former, but I am double-checking

* no reply -> defer -> soft bounce
* NEGATIVE reply -> no defer -> hard bounce

this answsers all possible cases because timeout is also "no reply"

if a domain does not exist because the worldwide DNS recursion says
"there is no such domain, there is no nameserver to ask" it would
be pointless to soft bounce / defer and hope someone registers
the domain

a outage is by definition "no reply"

Re: Do not forward spam

[li...@rhsoft.net]

Am 20.09.2013 18:12, schrieb azurIt:
> Blocking emails based on spam filters are always wrong

says who?

> Spam recognition will NEVER be 100%

nothing will 100%, nowehere

> there are always false positives

yes, and there are some 100 times more spam

> We are accepting all emails and filter them after

than accept that you are considered as a spammer and backscatter

> I just need to tell Postfix to NOT forward particular messages 

no, you need to realize that they way you are acting you are
considered as spammer for good reasons and the wrong handling
accepting anything is nothing postfix can fix after that

Re: Do not forward spam

[li...@rhsoft.net]

Am 20.09.2013 22:10, schrieb azurIt:
>> Am 20.09.2013 22:03, schrieb azurIt:
>>> One note to all fans of 'spam filters rejecting' here: Did you even notice 
>>> that 
>>> NO ONE of big e-mail providers are rejecting messages based on standard 
>>> spam filter techniques? 
>>> Google, Yahoo, Microsoft, AT&T, ... No one is doing it, most of them have 
>>> developed their own 
>>> filtering systems and you must be really big spammer to be blocked 
>>> permanently. 
>>> The best of them is Google, just try their filters and you will see (even 
>>> blocking which
>>> was used to us was targeted only to particular messages)
>>
>> that must be why you started this with "Today gmail block us because of spam 
>> (which we were
>> just forwarding, not sending)" :-)
>>
> Please read my whole message. Thank you

i did - but you still refuse to understand that *any* well implemented spam 
filter
based on content also filters and rejects *pre queue* - nobody but you does
accept *any* message and in many countries filter and delete spam *after*
accept it from the sender even is not permitted by law

*any* serious spam filter REJECTS at SMTP level because it is the only way
the sender knows it was filtered while not be a backscatter because the
*sending server* is generating the bounce with the rejct message of the
final destination and if it was a professional spammer he will supress it
and not read the reject message at all

here you go:
http://www.postfix.org/SMTPD_PROXY_README.html

BTW: avoid to look answering yourself by quoting because you cut the poster you 
refer

Re: Do not forward spam

[li...@rhsoft.net]

Am 20.09.2013 22:03, schrieb azurIt:
> One note to all fans of 'spam filters rejecting' here: Did you even notice 
> that 
> NO ONE of big e-mail providers are rejecting messages based on standard spam 
> filter techniques? 
> Google, Yahoo, Microsoft, AT&T, ... No one is doing it, most of them have 
> developed their own 
> filtering systems and you must be really big spammer to be blocked 
> permanently. 
> The best of them is Google, just try their filters and you will see (even 
> blocking which
> was used to us was targeted only to particular messages)

that must be why you started this with "Today gmail block us because of spam 
(which we were
just forwarding, not sending)" :-)

Re: need to purge clamav from postfix configuration

[li...@rhsoft.net]

Am 21.09.2013 17:25, schrieb DTNX Postmaster:
> +1 on using Debian ClamAV packages without any problems. We use the 
> milter package to integrate it with Postfix, using unix sockets.
> 
> The problem people generally run into with unix sockets is one of 
> permissions. The milter socket needs to be stored inside the Postfix 
> chroot, and be writable by both Postfix and the milter daemon

which leaves the question open why the Debian postfix-maintainer
insists in the *non upstream* chroot-default after years of most
problems reported here are caused by it?

Re: postfix multi-domain relay recipient verification problem with DNS and internal IP

[li...@rhsoft.net]

Am 30.09.2013 12:21, schrieb no@s...@mgedv.net:

> syslog entries as follows:
> postfix/smtpd 2013-09-30 10:45:23 NOQUEUE: reject: RCPT from
> mail.xxx.yyy[222.222.222.222]: 450 4.1.1 : Recipient address
> rejected: unverified address: Address verification in progress;
> from= to= proto=ESMTP helo=
> postfix/smtp 2013-09-30 10:45:47 connect to mail.x1.com[222.111.222.111]:25:
> Operation timed out
> postfix/smtp 2013-09-30 10:45:47 BB2D44AF07: to=, relay=none,
> delay=30, delays=0/0.01/30/0, dsn=4.4.1, status=undeliverable (connect to
> mail.x1.com[222.111.222.111]:25: Operation timed out)
> 
> any ideas how i can tell postfix to use the internal IP for my hosted
> domains?
> faking DNS with an own server is not an option, btw, as other DNS records
> from
> these domains need to be resolved properly for web-tools and such

normally you would have internal and external DNS views

however, dnsmasq can use /etc/hosts and forward all other requests to a
specific DNS and so you would point /etc/resolv.conf to 127.0.0.1

Re: postfix multi-domain relay recipient verification problem with DNS and internal IP

[li...@rhsoft.net]

Am 30.09.2013 12:59, schrieb no@s...@mgedv.net:
>> normally you would have internal and external DNS views
>>
>> however, dnsmasq can use /etc/hosts and forward all other requests to a
>> specific DNS and so you would point /etc/resolv.conf to 127.0.0.1
> 
> i know it's possible to fake DNS records with "dummy" DNS services

it's not a fake

> want to keep the installation clean and easy. my question points more in
> this direction i think: what tells postfix to use the internal IP for x2.us,
> but
> not for all the other domains, which are setup in exactly the same ways
> in the resolver, /etc/hosts, DNS, postfix-config and the "internal" m$-MX

postfix asks the DNS server
maybe you can use the /etc/hosts hack

http://www.linuxquestions.org/questions/linux-software-2/force-postfix-to-refer-etc-hosts-857662/

Re: postfix hardening - what can we do?

[li...@rhsoft.net]

Am 04.10.2013 13:43, schrieb LuKreme:
> On 03 Oct 2013, at 12:48 , micah  wrote:
>> Providing a TLS-wrapped, from the beginning, port is better than offering 
>> STARTTLS.
> 
> No, it really isn’t.
> 
> I’m not clear on what problem you ae trying to solve. You seem to want “mo 
> security” without 
> any evidence that the current security is insufficient.

keep in mind you are very new in context of mailservers

http://www.postfix.org/CVE-2011-0411.html

>> SMTP over TLS uses the same TLS protocol that is also used to encrypt
>> traffic between web clients and web servers. But, there is a subtle
>> difference in the way TLS is used, and that makes this flaw possible

yes this is fixed, but without the plaintext start it would not have been 
possible

> And rejecting plain text email acceptance? Well’s you might as well not have 
> a mailserver.

he is speaking about *submission* which is *always* authenticated and
there it is a good idea to enforce encryption if you rae in the position
to start with a new mailserver and need not to care about existing
client configurations which would break if you enforce it later

Re: Google rejecting IPv6 mails

[li...@rhsoft.net]

Am 07.10.2013 19:15, schrieb Erwan David:
> No Google is really rejecting emails in IPv6 because of a lack of PTR...

as virtually everbody else does for IPv4
why should someone handle IPv6 different?

if you have no PTR do not deliver emial

Re: Google rejecting IPv6 mails

[li...@rhsoft.net]

Am 07.10.2013 19:42, schrieb Erwan David:
> Le 07/10/2013 19:38, li...@rhsoft.net a écrit :
>>
>> Am 07.10.2013 19:15, schrieb Erwan David:
>>> No Google is really rejecting emails in IPv6 because of a lack of PTR...
>> as virtually everbody else does for IPv4
>> why should someone handle IPv6 different?
>>
>> if you have no PTR do not deliver emial
>>
> That's a matter of policy, if you cannot afford to loose legitimate
> email, you may.

show me one legitimate mail server in 2013 without a PTR

as server-admin you need to RTFM and anybody which is connecting
a mailserver to the internet not having a PTR or coming with
the lousy excuse "my ISP doe snot support" instead switch to
a sane ISP did not RTFM and has to accept that others do not
accept messages from him - the is no "if" and no "but"

Re: Google rejecting IPv6 mails

[li...@rhsoft.net]

Am 07.10.2013 20:30, schrieb Erwan David:
> Le 07/10/2013 20:24, li...@rhsoft.net a écrit :
>>
>> Am 07.10.2013 19:42, schrieb Erwan David:
>>> That's a matter of policy, if you cannot afford to loose legitimate
>>> email, you may.
>> show me one legitimate mail server in 2013 without a PTR
>>
>> as server-admin you need to RTFM and anybody which is connecting
>> a mailserver to the internet not having a PTR or coming with
>> the lousy excuse "my ISP doe snot support" instead switch to
>> a sane ISP did not RTFM and has to accept that others do not
>> accept messages from him - the is no "if" and no "but"
> 
> You may also completely stop accepting email, thus you will have no spam
> at all. For me it is more important not to loose legitimate email.
> You may have a different opinion.
> 
> But it is false to say tjat a mail server without reverse surely is a
> spammer.
> 
> Spammers can afford reverse

it is very likely that it is a spammer or at least not any important mail

if someone has important mail to send he will learn the hard way that
all the "best practices" are there for a reason - hence he get a
clear reject message and if someone refuses to fix it's setup which
is done within seconds -> his problem

for every rejected legit mail from a badly configured server missing a
PTR you block 100 spam mails

i even go so far if someone complains that his messages are rejected
because a missing PTR i recommend to fire his admin and in doubt the
PTR has to match the A-record

Re: Google rejecting IPv6 mails

[li...@rhsoft.net]

Am 07.10.2013 20:47, schrieb Erwan David:
> Le 07/10/2013 20:37, li...@rhsoft.net a écrit :
>> Am 07.10.2013 20:30, schrieb Erwan David:
>>> Le 07/10/2013 20:24, li...@rhsoft.net a écrit :
>>>> Am 07.10.2013 19:42, schrieb Erwan David:
>>>>> That's a matter of policy, if you cannot afford to loose legitimate
>>>>> email, you may.
>>>> show me one legitimate mail server in 2013 without a PTR
>>>>
>>>> as server-admin you need to RTFM and anybody which is connecting
>>>> a mailserver to the internet not having a PTR or coming with
>>>> the lousy excuse "my ISP doe snot support" instead switch to
>>>> a sane ISP did not RTFM and has to accept that others do not
>>>> accept messages from him - the is no "if" and no "but"
>>> You may also completely stop accepting email, thus you will have no spam
>>> at all. For me it is more important not to loose legitimate email.
>>> You may have a different opinion.
>>>
>>> But it is false to say tjat a mail server without reverse surely is a
>>> spammer.
>>>
>>> Spammers can afford reverse
>> it is very likely that it is a spammer or at least not any important mail
>>
>> if someone has important mail to send he will learn the hard way that
>> all the "best practices" are there for a reason - hence he get a
>> clear reject message and if someone refuses to fix it's setup which
>> is done within seconds -> his problem
>>
>> for every rejected legit mail from a badly configured server missing a
>> PTR you block 100 spam mails
>>
>> i even go so far if someone complains that his messages are rejected
>> because a missing PTR i recommend to fire his admin and in doubt the
>> PTR has to match the A-record
>>
> Tat's false. The best you can hope is that one of the A (or ) record
> for one of the PTR of the connecting address is the connecting address
> You may have several PTR per IP and several address per name

you may that, you may this

you may have a sane setup with one IP having one A-record and one PTR
i did nowhere say i would enforce this, i said "in doubt it has to match"
or at least there must be a A-record for your PTR

but that's off-topic

on-topic is that anybody setting up a MTA without a PTR is clearly
missing the qualification to maintaina mail-system and most likely
doe snot care about other best practices which makes him dangerous

Re: Temporarily block domain.tld from sending?

[li...@rhsoft.net]

Am 08.10.2013 07:44, schrieb Stan Hoeppner:
>> I've removed the script, I stopped ftp (it seems it was ftp'd)
>>
>> at the time I've posted, I was on a 4" mobile, and, I was looking for a
>> stop gap measure to 'stop further damage' from that point
> 
> Understood.  For a more permanent solution to this script problem, you
> may want to consider locking down or disabling the pickup service, and
> configuring all web applications and MUAs to use the submission service
> with auth.  This will prevent such scripts from being able to send mail
> in the event some crafty soul is able to get one uploaded via something
> other than FTP.

disable_functions = mail
http://code.google.com/a/apache-extras.org/p/phpmailer/downloads/list

i never allowed any webserver in the past 10 years to
use the sendmail binary for a lot of reasons like header
injections and so on

Re: Temporarily block domain.tld from sending?

[li...@rhsoft.net]

Am 08.10.2013 11:32, schrieb Manuel Bieling:
> On 2013.10.08 09:16:11 +0200, li...@rhsoft.net wrote: 
>> i never allowed any webserver in the past 10 years to
>> use the sendmail binary for a lot of reasons like header
>> injections and so on 
> 
> Good, but possibly would not have helped. For me it looks obvious like
> 'Stealrat' which opens a socket too.

postfix does not need to relay without authentication even on 127.0.0.1

> I never used PHP in the past 10
> years would be more convincing. However, I agree using a mail relay and
> mail storage on one maschine with a webserver is too much.
>  
> if(@mail($recipient, $subject, $message, $reply . $type, "-f$sender"))
>   die(chr(79) . chr(75) . md5(1234567890) . "+0");
> 
> [...]
> 
> if(!in_array('fsockopen', $config))
>   $socket = @fsockopen($address, 25, $errno, $errstr, 20);
> elseif(!in_array('pfsockopen', $config))
>   $socket = @pfsockopen($address, 25, $errno, $errstr, 20);
> 
> [...]

disable_functions = "exec, passthru, shell_exec, system, proc_open, proc_close, 
proc_nice, proc_terminate,
proc_get_status, pcntl_exec, apache_child_terminate, posix_kill, posix_mkfifo, 
posix_setpgid, posix_setsid,
posix_setuid, mail, symlink, link, dl, get_current_user, getmypid, getmyuid, 
getrusage, fsockopen, pfsockopen,
socket_accept, socket_bind, openlog, syslog"

Re: Temporarily block domain.tld from sending?

[li...@rhsoft.net]

Am 08.10.2013 15:16, schrieb Michael Orlitzky:
> On 10/08/2013 01:44 AM, Stan Hoeppner wrote:
>>
>> Understood.  For a more permanent solution to this script problem, you
>> may want to consider locking down or disabling the pickup service, and
>> configuring all web applications and MUAs to use the submission service
>> with auth.  This will prevent such scripts from being able to send mail
>> in the event some crafty soul is able to get one uploaded via something
>> other than FTP.
>>
> 
> Having mail() as the universal interface is nice while you're developing
> in PHP, since there's no need to fiddle with the settings when moving
> between development and production

well, any software i ever developed from 2003 on is using 127.0.0.1:25 if
available without authentication and the configured autentication and SMTP
host otherwise

on no webserver postfix is listening on 127.0.0.1
it listens explicitly on a virtual interface and only there

the other option is use http://php.net/manual/de/function.php-uname.php
and consider a hostname-scheme for development machines

these are all things which are solveable

Re: Google rejecting IPv6 mails

[li...@rhsoft.net]

Am 09.10.2013 23:54, schrieb James Cloos:
>> "ln" == lists@rhsoft net  writes:
> 
> ln> show me one legitimate mail server in 2013 without a PTR
> 
> Unfortunately it is not uncommon with v6.

because people change configurations in hurry to have ipv6

> I've had to whitelist a number of sites over the last year where the
> outoing mta added a v6 address w/o a ptr.

wrong way - don't whitelist them and they will fix it

> Mostly it appeared to be due to new v6 routes and autoconfig surprising
> the mta admin

autoconfig on a server?
well deserved to get rejected

never change anything on a network config without verify or
accept that you got rejected for good reasons, pretty sure
the OP has the same "problem"

Re: using different outgoing IP per incoming IP?

[li...@rhsoft.net]

Am 10.10.2013 10:20, schrieb Andreas Ziegler:
> a postfix server that is listening on more than IP - each for another
> internal service - is sending them out to the recipients using one
> specific IP.
> Is it possible to specify, that mails coming in on IP 1.2.3.4 have to
> use another outgoing IP than mails coming in on other IPs?

not with one instance
there is no connection between IP's before and after queue

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

Re: seamless postfix migration to a new server

[li...@rhsoft.net]

Am 12.10.2013 17:04, schrieb teknet9:
> I have many users i can not allow for any downtime (not even few seconds)

says who?

"not even a few seconds" is unrealistic even at normal operations
e-mail is not a real-time messenger

> Also i can not loose any single email

why should you?

you most likely would by partial migrations over months

> Your solution will not guarantee that

1) a short downtime does not matter
2) you do not lose email due downtime
3) incoming mail are deferred by the sender at downtime
4) hot rsync followed by a cold one due downtime is ultra fast
5) imapsync exists

normally one would migrate the *complete* server at once
and if it is only a new machine at the same location make
the last imapsync in a short downtime-frame while the old
server does no longer accept connections from outside

that all scripted and at last step the old machine becomes
a spare-IP address while the new ones network interface is
started with the IP address of the live machine

Re: Question on postfix set up: stopping new connections from outside on smtp server

[li...@rhsoft.net]

Am 18.10.2013 15:00, schrieb francis picabia:
> I'm looking at the logs for an SMTP only service where iptables
> should be stopping new connections on port 25, and I'm
> seeing connects with no sasl auth.  They fail to relay, but
> I'd rather we didn't talk to them at all

why do you need iptables for that?
comment out the smtp line for Port 25 in master.cf
the one you posted is stripped

what says "netstat --numeric-hosts --numeric-ports --programs -u -t -l"

# smtpinet  n   -   n   -60   smtpd

Re: disable ipv6 when sending to gmail ?

[li...@rhsoft.net]

Am 18.10.2013 17:57, schrieb Dominik George:
> Mark Martinec  schrieb:
>> IMO, instead of working on workarounds, people's efforts would be
>> better spent
>> on setting up their DKIM and/or SPF, reverse DNS mapping, and making
>> sure that
>> postfix only binds to an intentionally configured IPv6 address (not on
>> SLAAC
>> or 'privacy extensions' random address).
> 
> I took care of all of this, and I do habe working SPF, DKIM and DNS for IPv6 
> and did so forever.  
> Yet it does not make Google accept my mail.

what about giving the real IP and output of "ifconfig" to give others
the chance to verify this for you instead say "i took care"

* sender address
* configuration
* real IP adress to verify PTR that *only 1* PTR exists and matchs
* verify that *all* matchs

most times if people say "i have done that all" they made a small
mistake which they do not face independent how often you verufy it
by yourself

Re: Question on postfix set up: stopping new connections from outside on smtp server

[li...@rhsoft.net]

Am 18.10.2013 19:48, schrieb francis picabia:
> OK, with the syslog entry Noel suggested, I can see traffic has arrived on
> submission port.  Yet if I grep for the IP connecting, I see no sasl login.
> 
> Oct 18 14:39:24 myserver postfix-internal/submission/smtpd[25329]:
> connect from blk-222-132-252.eastlink.ca[24.222.132.252]
> Oct 18 14:39:24 myserver postfix-internal/submission/smtpd[25329]:
> NOQUEUE: reject: RCPT from
> blk-222-132-252.eastlink.ca[24.222.132.252]: 454 4.7.1
> : Relay access denied;
> from= to= proto=ESMTP
> helo=<[192.168.0.5]>
> 
> There must be a config to be tightened up somewhere in there

* it is not Port 25
* it is rejected

*what* do you imagine to tighten?

Port 587 is open, so any idiot out there can *try* to submit on 587
it is rejected becaus ehe does not authenticate
you are clearly searching for a solution where no problem exists

Re: mxbackup quote

[li...@rhsoft.net]

Am 18.10.2013 21:27, schrieb Pol Hallen:
> I configurated postfix ad mxbackup. show set a quote forma each domain?

*what* are you talking about?
that pretty much makes no sense for anybody but you

Re: disable ipv6 when sending to gmail ?

[li...@rhsoft.net]

Am 18.10.2013 23:52, schrieb Dominik George:
> $ host 2a00:1828:2000:239::2
> 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.3.2.0.0.0.0.2.8.2.8.1.0.0.a.2.ip6.arpa 
> domain name pointer shore.naturalnet.de.
> 
> $ host shore.naturalnet.de
> shore.naturalnet.de has address 89.238.64.147
> shore.naturalnet.de has IPv6 address 2a00:1828:2000:239::2
> 
>> * verify that *all* matchs
> 
> I do not see what should not match ;).
> 
> Further:
> 
> $ dig naturalnet.de MX
> ;; ANSWER SECTION:
> naturalnet.de.  3600IN  MX  30 shore.naturalnet.de.
> 
> $ dig shore.naturalnet.de 
> ;; ANSWER SECTION:
> shore.naturalnet.de.3521IN  2a00:1828:2000:239::2
> 
> $ dig naturalnet.de TXT
> ;; ANSWER SECTION:
> naturalnet.de.  3591IN  TXT "v=spf1 mx ~all"

if i would be you i would *not* use "v=spf1 mx ~all"

until we switched to declare ip-addresses in SPF i noted repeatly
negative results from several testing tools online, maybe caused
by the additional ookups needed for MX to A/AAA and IP

after switch to ipv4: i *never* faced any fasle positive

rhsoft.net. 86400  IN  TXT  "v=spf1 ip4:91.118.73.0/24 ip4:89.207.144.27 
ip4:84.113.45.179 -all"
rhsoft.net. 86400  IN  SPF  "v=spf1 ip4:91.118.73.0/24 ip4:89.207.144.27 
ip4:84.113.45.179 -all"

here you go for ipv6

http://www.openspf.org/SPF_Record_Syntax#ip6

Re: Connection refused to local stunnel tunnel

[li...@rhsoft.net]

Am 20.10.2013 01:34, schrieb Olaf Marzocchi:
> If I use ssl0.ovh.net:25, I get a timeout. If I use port 587, I get "(TLS is 
> required, but was not offered by host ssl0.ovh.net[213.186.33.20])", so I 
> opted for SMTPS.
> However, Postfix cannot do SMTPS on port 465, so I installed stunnel and I 
> set it to connect to ssl0.ovh.net:465. I did it on my OS X 10.8 and it 
> worked, I can send mail from command line. As reference, I used the config 
> suggested in postifx help:
> 
> [smtp-tls-wrapper]
> accept = localhost:11125
> client = yes
> connect = ssl0.ovh.net:465

this way you can get no difference because it is still smtps
https://www.stunnel.org/pipermail/stunnel-users/2011-April/003056.html

Re: Connection refused to local stunnel tunnel

[li...@rhsoft.net]

Am 20.10.2013 20:33, schrieb Wietse Venema:
> Olaf Marzocchi:
>> postfix/smtp[2103]: [ID 947731 mail.warning] warning: relayhost 
>> configuration problem
>> postfix/smtp[2103]: [ID 197553 mail.info] 311482A92D: 
>> to=, orig_to=, relay=none, delay=157834, 
>> delays=157833/0.01/0.08/0, dsn=4.3.5, status=deferred (Host or domain name 
>> not found. Name service error for name=localhost type=A: Host not found)
> 
> Specify [127.0.0.1] (including []) instead of "localhost".
> 
>> So, I still don't understand why is localhost not recognized!!
> 
> There is no "localhost" in DNS. To configure Postfix to look in
> /etc/hosts, see
> 
> http://www.postfix.org/postconf.5.html#smtp_host_lookup

the DNS server should be fixed

http://tools.ietf.org/html/rfc1537

Also each nameserver should run primary for 0.0.127.in-addr.arpa;
that zone file should contain a SOA and NS record and an entry:

 1PTR localhost.

EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316

[li...@rhsoft.net]

postfix/smtp[7411]: warning: TLS library problem: 7411:error:100AE081:elliptic 
curve
routines:EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316

maybe relevant to "only ECC NIST Suite B curves support"?
postfix was compiled against exactly this openssl build
as far as i can see fallback to unecrypted connection

http://koji.fedoraproject.org/koji/buildinfo?buildID=471781
* Wed Oct 16 2013 Tomáš Mráz  1.0.1e-28
- only ECC NIST Suite B curves support
- drop -fips subpackage

* Mon Oct 14 2013 Tom Callaway 
- 1.0.1e-27
- resolve bugzilla 319901 (phew! only took 6 years & 9 days)

Re: EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316

[li...@rhsoft.net]

Am 21.10.2013 23:04, schrieb Viktor Dukhovni:
> On Mon, Oct 21, 2013 at 09:43:50PM +0200, li...@rhsoft.net wrote:
> 
>> postfix/smtp[7411]: warning: TLS library problem: 
>> 7411:error:100AE081:elliptic curve
>> routines:EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316
>>
>> maybe relevant to "only ECC NIST Suite B curves support"?
>> postfix was compiled against exactly this openssl build
>> as far as i can see fallback to unecrypted connection
>>
>> http://koji.fedoraproject.org/koji/buildinfo?buildID=471781
>> * Wed Oct 16 2013 Tom?? Mr?z  1.0.1e-28
>> - only ECC NIST Suite B curves support
>> - drop -fips subpackage
>>
>> * Mon Oct 14 2013 Tom Callaway 
>> - 1.0.1e-27
>> - resolve bugzilla 319901 (phew! only took 6 years & 9 days)
> 
> Until recently, there was no ECC support in RedHat (and Fedora)
> OpenSSL packages.  It seems that a few weeks ago they finally
> enabled ECC, but could not resist the urge to cripple it a bit. :-)

looks so

> Instead of improving the world by finally supporting EC, they've
> made things worse!  Previously clients negotiated something other
> than EECDH key exchange, now they negotiate it and fail!  Sorry to
> say so, but the RedHat engineers need adult supervision.

since you sound very knowledgeable about SSL may you consider
to make a comment there?

https://bugzilla.redhat.com/show_bug.cgi?id=1019251

fine: http://koji.fedoraproject.org/koji/buildinfo?buildID=471397
crippled: http://koji.fedoraproject.org/koji/buildinfo?buildID=471781

with the first build no single error

> What site was your SMTP client connecting to?  IIRC Suite B supports
> prime256v1 (aka secp256r1) and secp384r1.  Perhaps the SMTP server
> decided to live on the bleeding edge with "secp521r1"

as far as i can see in all 8 cases currently to GMX

Oct 21 22:29:22 mail postfix/smtp[12289]: SSL_connect error to 
mx00.gmx.net[213.165.67.99]:25: -1
Oct 21 22:29:22 mail postfix/smtp[12289]: warning: TLS library problem: 
12289:error:100AE081:elliptic curve
routines:EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316:
Oct 21 22:29:22 mail postfix/smtp[12289]: warning: TLS library problem: 
12289:error:1408D010:SSL
routines:SSL3_GET_KEY_EXCHANGE:EC lib:s3_clnt.c:1641:
Oct 21 22:29:22 mail postfix/smtp[12289]: 3d3Tvy5Cdsz23: Cannot start TLS: 
handshake failure

Re: EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316

[li...@rhsoft.net]

Am 21.10.2013 23:40, schrieb Viktor Dukhovni:
> On Mon, Oct 21, 2013 at 11:17:25PM +0200, li...@rhsoft.net wrote:
> 
>>> Instead of improving the world by finally supporting EC, they've
>>> made things worse!  Previously clients negotiated something other
>>> than EECDH key exchange, now they negotiate it and fail!  Sorry to
>>> say so, but the RedHat engineers need adult supervision.
>>
>> since you sound very knowledgeable about SSL may you consider
>> to make a comment there?
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1019251
> 
> I have enough fish to fry.  The problem is obvious, client promises
> EECDH support, server sends a standard curve name and the client
> promptly fails because its list of supported curves is incomplete.
> 
> Of course you should capture a session with wireshark and see what
> curve the server sends back to confirm this obvious interpretation.

looking at the logs where ECDHE worked fine with the intermediate openssl
and started to fail to "mx00.gmx.net" after the crippleded update i
think the situation is clear

>> fine: http://koji.fedoraproject.org/koji/buildinfo?buildID=471397
>> crippled: http://koji.fedoraproject.org/koji/buildinfo?buildID=471781
>>
>> with the first build no single error
> 
> I think you know what to do...

maintain openssl at my own is above my scope i fear :-(

well, i rebuild the package with "rpm --rebuild" but they strip parts out of the
source-tarball and even in my situation building dovecot/postfix/httpd with
complete own packages it leaves a bad taste of danger try to maintain a
different openssl in context of other packages

i hate it to ask but is there any change postfix avoids ECDHE for such 
destinations
in case of this situation and continues to use DHE if the requested curve is not
available in the linked openssl library?

>> as far as i can see in all 8 cases currently to GMX
>>
>> Oct 21 22:29:22 mail postfix/smtp[12289]: SSL_connect error to
>>   mx00.gmx.net[213.165.67.99]:25: -1
> When I test connections to this host,  I always get "AES256-SHA",
> and no EDH or kEECDH ciphers are accepted.  Did gmx.de change their
> configuration to work around this?  Can you build posttls-finger (from 2.11)
> and test with:
> 
> $ posttls-finger -t30 -T 180 -p TLSv1.2 -Ldebug \
>   -o tls_medium_cipherlist='kEECDH:kEDH:kRSA' \
>   "[213.165.67.99]"
> 
> do you get handshake failures?

no "posttls-finger" here but the logs below are a clear language i think
Oct 21 20:16:43 Updated: 1:openssl-libs-1.0.1e-28.fc18.x86_64

Oct 21 19:08:27 mail postfix/smtp[13875]: Trusted TLS connection established to 
mx00.gmx.net[213.165.67.99]:25:
TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Oct 21 19:36:37 mail postfix/smtp[15749]: Trusted TLS connection established to 
mx00.gmx.net[213.165.67.99]:25:
TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Oct 21 19:59:48 mail postfix/smtp[17217]: Trusted TLS connection established to 
mx00.gmx.net[213.165.67.99]:25:
TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

https://bugzilla.redhat.com/show_bug.cgi?id=1019390#c3

Re: EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316

[li...@rhsoft.net]

Am 21.10.2013 23:49, schrieb li...@rhsoft.net:
> i hate it to ask but is there any change postfix avoids ECDHE for such 
> destinations
> in case of this situation and continues to use DHE if the requested curve is 
> not
> available in the linked openssl library?
> 
>>> as far as i can see in all 8 cases currently to GMX
>>>
>>> Oct 21 22:29:22 mail postfix/smtp[12289]: SSL_connect error to
>>>   mx00.gmx.net[213.165.67.99]:25: -1
>> When I test connections to this host,  I always get "AES256-SHA",
>> and no EDH or kEECDH ciphers are accepted.  Did gmx.de change their
>> configuration to work around this?  Can you build posttls-finger (from 2.11)
>> and test with:
>>
>> $ posttls-finger -t30 -T 180 -p TLSv1.2 -Ldebug \
>>  -o tls_medium_cipherlist='kEECDH:kEDH:kRSA' \
>>  "[213.165.67.99]"
>>
>> do you get handshake failures?
> 
> no "posttls-finger" here but the logs below are a clear language i think
> Oct 21 20:16:43 Updated: 1:openssl-libs-1.0.1e-28.fc18.x86_64
> 
> Oct 21 19:08:27 mail postfix/smtp[13875]: Trusted TLS connection established 
> to mx00.gmx.net[213.165.67.99]:25:
> TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> Oct 21 19:36:37 mail postfix/smtp[15749]: Trusted TLS connection established 
> to mx00.gmx.net[213.165.67.99]:25:
> TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> Oct 21 19:59:48 mail postfix/smtp[17217]: Trusted TLS connection established 
> to mx00.gmx.net[213.165.67.99]:25:
> TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1019390#c3

also interesting, from one postfix to another using the same postfix/openssl 
builds
exactly the same previously to GMX used ciphers are still fine - leaves the 
question
open what exactly does "mx00.gmx.net" differently to fail now

Oct 21 23:52:45 localhost postfix/smtp[27178]: Trusted TLS connection 
established to *:25: TLSv1.2 with cipher
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Re: EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316

[li...@rhsoft.net]

Am 22.10.2013 02:33, schrieb Viktor Dukhovni:
> On Mon, Oct 21, 2013 at 11:55:38PM +0200, li...@rhsoft.net wrote:
> 
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1019390#c3
> 
> The author of comment #4 is not getting it.  The problem is NOT
> that Postfix fails to negotiate EECDH, rather the problem is that
> it does!  Once EECDH is negotiated, the server (gmx) selects an
> unsupported (by RedHat's crippled OpenSSL) curve and the handshake
> fails.

this guy did the absusive change too :-(

> This is NOT progress.  No support for EC is better than broken
> support for EC.  Either implement EC support or don't.

yes, frsutrating, but better start with something crippeled and
hope it improves than wait another 6 years

>> also interesting, from one postfix to another using the same postfix/openssl 
>> builds
>> exactly the same previously to GMX used ciphers are still fine - leaves the 
>> question
>> open what exactly does "mx00.gmx.net" differently to fail now
>>
>> Oct 21 23:52:45 localhost postfix/smtp[27178]:
>>   Trusted TLS connection established to *:25:
>>   TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> 
> I don't understand what you mean, feel free to elaborate.

my two postfix servers are using exactly the same ciphers as
was used before the change with success to GMX, but maybe i
am not knoledgeable enough to understand the deep details...

Re: EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316

[li...@rhsoft.net]

Am 23.10.2013 22:57, schrieb Viktor Dukhovni:
> On Tue, Oct 22, 2013 at 06:07:49AM +, Viktor Dukhovni wrote:
> 
> Follow-up, comments after a brief email discussion with Paul Wouters
> of RedHat:

thank you so much for that!

>> * Firstly, client TLS extensions are not possible when the client starts
>>   with an SSLv2 compatible SSL HELLO.  So the list of supported curves
>>   is not sent by clients that are backwards compatible with SSLv2 (though
>>   of course by now SSLv2 should be disabled in most clients).
> 
> This is still an issue, but nobody should enable SSLv2, so perhaps
> breakage when you do is tolerable.  RedHat could disable client-side
> ECDH ciphers for SSL connections for which SSLv2 is enabled.

understood

>> * Secondly, the OpenSSL server API does not expose the client's
>>   supported EC curves to the server application which is expected
>>   to configure the EECDH curve.  Thus the extension from RFC 4492
>>   is almost never used, most servers choose the EECDH curve blindly.
> 
> While OpenSSL does not currently allow the server's choice of curve
> to adjust to client capabilities, it does in fact check whether
> the server's curve is on the client's list, and if not, the OpenSSL
> server code with disable ECDH cipher-suites.

understood

> The problem turns out to be that RedHat's patch did not prune the
> list of curves advertised by the TLS client!  They're going to
> update the code to only advertise secp{256,384}r1, which will make
> connections to gmx.de work again (but without EECDH)

sounds good and thank you again to point this out
so "we" can expect a fixed package soon and disable workarounds

in the meantime "smtp_tls_policy_maps" works like a charme
sooner or later i will have the whole postfix-documentatin in my configs :-)

/etc/postfix/tls_policy
gmx.de encrypt exclude=ECDH
gmx.at encrypt exclude=ECDH
gmx.net encrypt exclude=ECDH
gmx.com encrypt exclude=ECDH

Re: EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316

[li...@rhsoft.net]

Am 24.10.2013 11:11, schrieb Patrick Lists:
> On 10/23/2013 10:57 PM, Viktor Dukhovni wrote:
> [snip]
>> The problem turns out to be that RedHat's patch did not prune the
>> list of curves advertised by the TLS client!  They're going to
>> update the code to only advertise secp{256,384}r1, which will make
>> connections to gmx.de work again (but without EECDH).
> 
> Apologies if this is too OT but did Paul mention why they are ripping out 
> curves?

if you look at the history of the 6 years standing original bugreport
clearly because patent trolls and the fact Redhat is a US company

https://bugzilla.redhat.com/show_bug.cgi?id=319901
https://bugzilla.redhat.com/show_bug.cgi?id=319901#c17

Re: Relay Access Denied

[li...@rhsoft.net]

Am 25.10.2013 00:50, schrieb Tim Legg:
> I tried to send an e-mail from my address on mail.com to my own machine to 
> test it out. It bounced.  Below is the
> tail of my mail.log
>  
> postfix/smtpd[12344]: NOQUEUE: reject: RCPT from mout.gmx.net[74.208.4.201]: 
> 554 5.7.1 : Relay
> access denied; from= to= proto=ESMTP 
> helo=
> postfix/smtpd[12344]: disconnect from mout.gmx.net[74.208.4.201]
>  
> I read about this error on other forums, but I had no idea what they were 
> talking about.  I just need to do what
> needs to be done to make it work.  

output of "postconf -n" would be helpful

> Unfortunately, on Ubuntu, postfix doesn't seem to work out-of-the-box

it is impossible to work out of the box because without configuration
no MTA (not only) postfix knows what domains you are hosting nor how
to deliver messages to the mailboxes

Re: How do I track down (mail system configuration error)

[li...@rhsoft.net]

Am 29.10.2013 16:23, schrieb LuKreme:
> On 29 Oct 2013, at 09:13 , Wietse Venema  wrote:
> 
>> % egrep '(warning|error|fatal|panic):' /some/log/file | more
> 
> I forgot about warning and checked egrep '(fatal|panic|error)'
> 
> warning: pipe flag `D' requires dovecot_destination_recipient_limit = 1
> So, there's that

one reason more why soeone should use LMTP these days
besides possible security problems and bad performance
by starting a new process for each delivery

Re: How do I track down (mail system configuration error)

[li...@rhsoft.net]

Am 29.10.2013 21:27, schrieb LuKreme:
> On 29 Oct 2013, at 09:26 , li...@rhsoft.net wrote:
>> one reason more why soeone should use LMTP these days
>> besides possible security problems and bad performance
>> by starting a new process for each delivery
> 
> I'm not sure I understand. 

you don't

> Are you saying that this a reason to use LMTP

yes

> but that LMTP causes security problems and bad performance?

no, the *opposite* that is why i said one *reason more*

Re: Delays

[li...@rhsoft.net]

Am 29.10.2013 21:25, schrieb Roman Gelfand:
> The client is thunderbird.  Correct me if I am wrong, it appears it 40
> seconds for the client to hand over the email to the server?  If so,
> where should I troubleshoot?  are there maintenance
> tasks/configuration changes to improve this situation.
> 
> BTW... from the inception there was no or negligible delay.  Several
> months later, I am seeing this on regular basis even hourly volume is
> not large.
> 
> Oct 29 16:06:10 pmx1 postfix/smtp[7414]: 200AC43831:
> to=, relay=none, delay=40, delays=0.01/0/40/0,
> dsn=4.4.1, status=deferred (connect to
> mail.domain.com[96.57.168.248]:25: Connection timed out)

this is clearly a *network* problem on the server *or* the client
*or* somewhere between (routers, switches)

Re: Delays

[li...@rhsoft.net]

Am 29.10.2013 21:46, schrieb Roman Gelfand:
> How did you decide this is a network issue?

Connection timed out?

> How would you go about determining which router which switch?

it's hard to explain how to debug network issues

> On Tue, Oct 29, 2013 at 4:33 PM, li...@rhsoft.net  wrote:
>>
>>
>> Am 29.10.2013 21:25, schrieb Roman Gelfand:
>>> The client is thunderbird.  Correct me if I am wrong, it appears it 40
>>> seconds for the client to hand over the email to the server?  If so,
>>> where should I troubleshoot?  are there maintenance
>>> tasks/configuration changes to improve this situation.
>>>
>>> BTW... from the inception there was no or negligible delay.  Several
>>> months later, I am seeing this on regular basis even hourly volume is
>>> not large.
>>>
>>> Oct 29 16:06:10 pmx1 postfix/smtp[7414]: 200AC43831:
>>> to=, relay=none, delay=40, delays=0.01/0/40/0,
>>> dsn=4.4.1, status=deferred (connect to
>>> mail.domain.com[96.57.168.248]:25: Connection timed out)
>>
>> this is clearly a *network* problem on the server *or* the client
>> *or* somewhere between (routers, switches)

Re: Delays

[li...@rhsoft.net]

Am 29.10.2013 21:55, schrieb li...@rhsoft.net:
> Am 29.10.2013 21:46, schrieb Roman Gelfand:
>> How did you decide this is a network issue?
> 
> Connection timed out?

[harry@srv-rhsoft:~]$ telnet 96.57.168.248 25
Trying 96.57.168.248...
telnet: connect to address 96.57.168.248: Connection timed out

and BTW:

mail.domain.com[96.57.168.248]:25: Connection timed out

if you think you need to anonymize informations do *not*
use random domains: http://tools.ietf.org/html/rfc2606#section-3
and if you need help generally avoid to do so without
very good reasons

[harry@srv-rhsoft:~]$ host mail.domain.com
mail.domain.com has address 72.5.54.21

>> How would you go about determining which router which switch?
> 
> it's hard to explain how to debug network issues
> 
>> On Tue, Oct 29, 2013 at 4:33 PM, li...@rhsoft.net  wrote:
>>>
>>>
>>> Am 29.10.2013 21:25, schrieb Roman Gelfand:
>>>> The client is thunderbird.  Correct me if I am wrong, it appears it 40
>>>> seconds for the client to hand over the email to the server?  If so,
>>>> where should I troubleshoot?  are there maintenance
>>>> tasks/configuration changes to improve this situation.
>>>>
>>>> BTW... from the inception there was no or negligible delay.  Several
>>>> months later, I am seeing this on regular basis even hourly volume is
>>>> not large.
>>>>
>>>> Oct 29 16:06:10 pmx1 postfix/smtp[7414]: 200AC43831:
>>>> to=, relay=none, delay=40, delays=0.01/0/40/0,
>>>> dsn=4.4.1, status=deferred (connect to
>>>> mail.domain.com[96.57.168.248]:25: Connection timed out)
>>>
>>> this is clearly a *network* problem on the server *or* the client
>>> *or* somewhere between (routers, switches)

Re: Delays

[li...@rhsoft.net]

Am 29.10.2013 22:08, schrieb Roman Gelfand:
> Sorry about that one.  In fact, the other address was unreachable
> than.   Please, keep in mind, it is the hand off from thunderbird to
> postfix I am interested in.
> 
> Here is a good example.
> 
> Oct 29 16:57:10 pmx1 postfix/smtp[8024]: EF7454059D:
> to=,
> relay=gmail-smtp-in.l.google.com[173.194.68.26]:25, delay=31,
> delays=0.02/0/30/0.55, dsn=2.0.0, status=sent (250 2.0.0 OK 1383080173
> nl1si12576362qeb.75 - gsmtp)

a good example for what?
status=sent -> what is your problem?

"cat maillog | grep EF7454059D" to filter anything related to this message
from the logfilesand the "delay=31" is most likely because the message
was queued on your server for whatever load-reason or because temporary
not reachable destination (network, name-resolution, one of them at googles 
side)

> On Tue, Oct 29, 2013 at 5:02 PM, li...@rhsoft.net  wrote:
>>
>>
>> Am 29.10.2013 21:55, schrieb li...@rhsoft.net:
>>> Am 29.10.2013 21:46, schrieb Roman Gelfand:
>>>> How did you decide this is a network issue?
>>>
>>> Connection timed out?
>>
>> [harry@srv-rhsoft:~]$ telnet 96.57.168.248 25
>> Trying 96.57.168.248...
>> telnet: connect to address 96.57.168.248: Connection timed out
>>
>> and BTW:
>>
>> mail.domain.com[96.57.168.248]:25: Connection timed out
>>
>> if you think you need to anonymize informations do *not*
>> use random domains: http://tools.ietf.org/html/rfc2606#section-3
>> and if you need help generally avoid to do so without
>> very good reasons
>>
>> [harry@srv-rhsoft:~]$ host mail.domain.com
>> mail.domain.com has address 72.5.54.21
>>
>>>> How would you go about determining which router which switch?
>>>
>>> it's hard to explain how to debug network issues
>>>
>>>> On Tue, Oct 29, 2013 at 4:33 PM, li...@rhsoft.net  wrote:
>>>>>
>>>>>
>>>>> Am 29.10.2013 21:25, schrieb Roman Gelfand:
>>>>>> The client is thunderbird.  Correct me if I am wrong, it appears it 40
>>>>>> seconds for the client to hand over the email to the server?  If so,
>>>>>> where should I troubleshoot?  are there maintenance
>>>>>> tasks/configuration changes to improve this situation.
>>>>>>
>>>>>> BTW... from the inception there was no or negligible delay.  Several
>>>>>> months later, I am seeing this on regular basis even hourly volume is
>>>>>> not large.
>>>>>>
>>>>>> Oct 29 16:06:10 pmx1 postfix/smtp[7414]: 200AC43831:
>>>>>> to=, relay=none, delay=40, delays=0.01/0/40/0,
>>>>>> dsn=4.4.1, status=deferred (connect to
>>>>>> mail.domain.com[96.57.168.248]:25: Connection timed out)
>>>>>
>>>>> this is clearly a *network* problem on the server *or* the client
>>>>> *or* somewhere between (routers, switches)

Re: CONNECT from localhost[::1]: 454 4.7.1 : Client host rejected: Access denied

[li...@rhsoft.net]

Am 30.10.2013 22:42, schrieb Andy Howell:
> I'm using openSuSE 13.1 system, running as a virtual machine. I'm not married 
> to that
> disto. I started with CentOS 6.4, but the postfix there is 3+ years old. I 
> wanted an RPM
> based disto with more recent versions. SuSE 13.1 seemed reasonable. I find 
> the debian
> package management too painful to work with. RPM is much easier when its 
> necessary to
> build something from source.
> 
> Postfix is listening to ip6:
> 
> netstat -an|grep 10025
> tcp0  0 127.0.0.1:10025 0.0.0.0:*   LISTEN
> tcp0  0 ::1:10025   :::*LISTEN
> 
> I should probably just disable ipv6 on the interfaces, as its not needed


you probably should disable ipv6 at all if it is not in use
as well as anything else which is not in use on a server

sysctl.conf:
net.ipv6.conf.all.disable_ipv6=1

Re: Getting automated sending feedback from SMTP server

[li...@rhsoft.net]

Am 02.11.2013 12:15, schrieb Jeroen Geilman:
>> Using php-mailer or any language/api (in [HTTP Server]), I only have
>> feedback for connection between servers: "Connection to SMTP server was
>> OK", but this is not a proof that my message was really sent.

if the send-method() of phpmailer gives "true" back that this *is*
the proff because it got a 2xx status code from the SMTP server

> No, there is much more information exchanged.
> 
> If whatever library you are using on the HTTP end does not properly support 
> SMTP

phpmailer *does* and with correct handling you even got the
whole server responses on the website

Re: not logging outbound emails

[li...@rhsoft.net]

Am 02.11.2013 22:17, schrieb c cc:
> In /var/log/maillog, I do not see any outbound emails being logged

show logs

> only inbound emails

show logs

> Did I misconfigure anything?

who knows your config without a crystal ball and missing "postconf -n"

Re: Getting automated sending feedback from SMTP server

[li...@rhsoft.net]

Am 03.11.2013 05:26, schrieb Paul C:
> phpmailer, or any other mime class, is not giving you the actual response 
> code of the end delivery of the email,
> unless you are directly sending your email from phpmailer (which is possible 
> but not intelligent). It can be
> confusing to people when they don't understand the transport of the message 
> to its final destination. 
> 
> So your 2xx response you got from phpmailer means you successfully delivered 
> the email from your script to your
> postfix mta, that 2xx response means postfix has accepted the message and 
> will process it. If the final destination
> of the message was to an email address on your server, postfix would finish 
> the delivery by sending the message to
> the local mailbox, but in the hotmail example, postfix takes the message from 
> you successfully, puts it in the
> queue, and then attempts to connect to hotmail and do the entire smtp 
> conversation all over again with hotmail,
> where hotmail would give postfix the response code of that attempt. This 
> response has absolutely nothing to do with
> the response you got from phpmailer. 

and how is this different to any other e-mail you send over SMTP?

if it fails you get a bounce from your postfix server to the envelope sender
and if you do not get a bounce after 5 days it was delivered - nothing new

http://en.wikipedia.org/wiki/Variable_envelope_return_path
http://www.postfix.org/VERP_README.html

Re: Postfix still sending bounces

[li...@rhsoft.net]

Am 05.11.2013 00:50, schrieb Jim Wright:
> On Nov 4, 2013, at 5:03 PM, Ian Evans  wrote:
>>
>> I've read tutorials and the backscatter/local recipient pages and my postfix 
>> is still sending out bounce message instead of just dropping the 
>> connections. I want to be a good netizen so want to nip this in the bud.
> 
> Normally, bouncing undeliverable messages is the proper behavior for a good 
> netizen.

*what*?

you never ever have to bounce - not for incoming mail
you must not if you won't get blacklisted for good reasons

http://en.wikipedia.org/wiki/Backscatter

> Why are you being rude and dropping the connection?  

he meant REJECT and not simply drop the connection

> Doing this to a properly configured mail server will just cause them to retry 
> the delivery

not in case of a 5xx status code

Re: Postfix still sending bounces

[li...@rhsoft.net]

Am 05.11.2013 12:03, schrieb Jose Borges Ferreira:
> On Tue, Nov 5, 2013 at 4:43 AM, LuKreme  wrote:
>>> Normally, bouncing undeliverable messages is the proper behavior for a good 
>>> netizen.
>>
>> *NEVER* Bounce. Ever.
>>
>> Reject, yes. Bounce? Absolutely never. If you bounce a message to me, you 
>> get put on the deepest darkest shitlist imaginable where you *never* get 
>> removed.
>>
> 
> Your server, Your rules but don't try to influence people with bad ideas.

if a server is sending bounces instead reject messages it is wrong configured

> Backscatter is done with bounces. Not all bounces are backscatter.

the one and only reason why a bounce is acceptable is to *your* users beause
the remote MTA rejected a message and after accept a incoming message the LDA
does not accept it because quotas whichthe MTA can not check for

* if you accept a message and the RCPT is unknown -> config error
* if you accept a message and use a post-queue spamfilter you must not bounce
  avoid such filters

there is no other valid reason accept a incoming message and after
that send a bounce - that's the Microsoft Exchange way accepting and
then send bounces "user unknown", but this is unacceptable behavior

Re: force startssl/tls/ssl on sasl login

[li...@rhsoft.net]

Am 06.11.2013 23:34, schrieb Benny Pedersen:
> nik600 skrev den 2013-11-06 23:19:
> 
>> is possible to force startssl/tls/ssl on sasl login ?
> 
> http://www.faqforge.com/linux/how-to-enable-port-465-smtps-in-postfix-mailserver/

and what has the deprecated smtps to do with the question?
how does it prevent to authenticate on 587 without TLS/SSL?
why would you stop use the correct submission port?

in other words - there where enough correct answers before

Re: Convert all envelope ids to lowercase

[li...@rhsoft.net]

Am 07.11.2013 11:32, schrieb Ansgar Wiechers:
> On 2013-11-07 Ram wrote:
>> Is there a simple way I can configure postfix to convert all Envelope
>> From and To addresses to lowercase, before delivery
>>
>> I believe postfix internally converts all ids to-lowercase while
>> doing hash map lookups
>> I need this because that will save all unnecessary tolower() function
>> calls in all reporting modules
> 
> Localparts are not case-insensitive

in theory opf a dumb RFC
in real life they are

never faced a mailserver where m...@example.com is not
delivered to the same inbox as m...@example.com and
vice versa

Re: postfix 2.7.1 debian - does not query DNS

[li...@rhsoft.net]

Am 07.11.2013 12:53, schrieb Simon Loewenthal:
> Damned chroot now turned off, and lookups now work like they should have done 
> :D
> 
> And this nicely solved my RDNS_NONE scoring issue with SA, of course!
> 
> Nov  7 12:49:16 lo postfix/smtpd[15712]: 32FD892: 
> client=english-breakfast.cloud9.net[168.100.1.7]
> Thanks, I did not think that chroot had been turned on by default

Debian is the only known distribution doing this stupid default config
over years and only god knows why they insist doing this damage

explicit cipher list

[li...@rhsoft.net]

Hi

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

am i overlooking something or is it not possible to list explcit
offered ciphers and their order like dovecot/httpd fro smtpd?

i am speaking here about non-MX servers only for submission
what i most appreciate in this way of configuration is
openssl ciphers -v '{cipherlist}' to verify it
___

dovecot:

ssl_prefer_server_ciphers = yes
ssl_cipher_list =
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:AES256-SHA:RC4-SHA:!3DES:!ADH:!aNULL:!DES:!DSS:!eNULL:!EXP:!KRB5:!LOW:!MD5:!PSK:!RC2:!SEED:!SRP:!SSLv2
___

httpd:

SSLProtocol All -SSLv2
SSLHonorCipherOrder On
SSLCipherSuite
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:AES256-SHA:RC4-SHA:!3DES:!ADH:!aNULL:!DES:!DSS:!eNULL:!EXP:!KRB5:!LOW:!MD5:!PSK:!RC2:!SEED:!SRP

Re: explicit cipher list

[li...@rhsoft.net]

thank you for your feedback

Am 07.11.2013 23:45, schrieb Viktor Dukhovni:
> Postfix provides a more natural user interface in terms of cipher
> grades (null, export, low, medium, high).  These have sensibly easy
> to reason about security properties.
> 
> I've seen many subtle and not so-subtle errors when mere mortals
> (including myself) have tried to use the raw OpenSSL cipherlist
> syntax.  

that's clear, but on the other hand having exactly the same configuration on
SMTP/POP3/IMAP makes it unlikely that a client behaves different and may
fail for the one and not for the other

> Making that be the Postfix interface would be a disservice
> to Postfix users.

in my current case where i played round over weeks with the Apache
configuration and https://www.ssllabs.com/ssltest/ the opposite
is true

>> I am speaking here about non-MX servers only for submission
>> what I most appreciate in this way of configuration is
>> openssl ciphers -v '{cipherlist}' to verify it
> 
> $ postfix_ciphers() {
>   grade="$1"
>   openssl ciphers -v "$(postconf -xh tls_${grade}_cipherlist)"
>   }
> 
> $ postfix_ciphers null
> ECDHE-RSA-NULL-SHA  SSLv3 Kx=ECDH Au=RSA  Enc=None  Mac=SHA1
> ECDHE-ECDSA-NULL-SHASSLv3 Kx=ECDH Au=ECDSA Enc=None  Mac=SHA1
> ECDH-RSA-NULL-SHA   SSLv3 Kx=ECDH/RSA Au=ECDH Enc=None  Mac=SHA1
> ECDH-ECDSA-NULL-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=None  Mac=SHA1
> NULL-SHA256 TLSv1.2 Kx=RSA  Au=RSA  Enc=None  
> Mac=SHA256
> NULL-SHASSLv3 Kx=RSA  Au=RSA  Enc=None  Mac=SHA1
> NULL-MD5SSLv3 Kx=RSA  Au=RSA  Enc=None  Mac=MD5
> 
> The above requires a Postfix recent enough to support "postconf
> -x", otherwise, drop the "x" and it'll probably still work, provided
> there are no ${variable} macros in your main.cf overrides of these
> parameters.

cool, yes always the latest stable release in use

> If you MUST muck around with raw OpenSSL cipherlists, the underlying
> 
>   tls__cipherlist
> parameters are present and documented, along with appropriate
> warnings to not go there.
> 
> Note that Postfix will still apply implicit and configured exclusions
> to these based on context (!aNULL when verifying peer certificates)

that does not work with "smtpd_tls_security_level = may" and 
"smtpd_tls_security_level = encrypt"
is impossible without breaking historical client setups nobody knows how to 
explain them all
to enable encryption on different devices
___

"smtpd_tls_exclude_ciphers" seems not to work as expected because DES ciphers 
are still enabled

[root@testserver:~]$ postconf -n | grep smtpd_tls_exclude_ciphers
smtpd_tls_exclude_ciphers = 3DES, ADH, aNULL, DES, DSS, eNULL, EXP, KRB5, MD5, 
PSK, RC2, SEED, SRP

[root@testserver:~]$ postconf -xh tls_high_cipherlist
aNULL:-aNULL:ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH

[root@testserver:~]$ openssl ciphers -v 
'aNULL:-aNULL:ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH'
AECDH-AES256-SHASSLv3 Kx=ECDH Au=None Enc=AES(256)  Mac=SHA1
ADH-AES256-GCM-SHA384   TLSv1.2 Kx=DH   Au=None Enc=AESGCM(256) Mac=AEAD
ADH-AES256-SHA256   TLSv1.2 Kx=DH   Au=None Enc=AES(256)  Mac=SHA256
ADH-AES256-SHA  SSLv3 Kx=DH   Au=None Enc=AES(256)  Mac=SHA1
ADH-CAMELLIA256-SHA SSLv3 Kx=DH   Au=None Enc=Camellia(256) Mac=SHA1
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) 
Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA  Enc=AES(256)  Mac=SHA384
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256)  Mac=SHA384
ECDHE-RSA-AES256-SHASSLv3 Kx=ECDH Au=RSA  Enc=AES(256)  Mac=SHA1
ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256)  Mac=SHA1
DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH   Au=DSS  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH   Au=RSA  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH   Au=RSA  Enc=AES(256)  Mac=SHA256
DHE-DSS-AES256-SHA256   TLSv1.2 Kx=DH   Au=DSS  Enc=AES(256)  Mac=SHA256
DHE-RSA-AES256-SHA  SSLv3 Kx=DH   Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-DSS-AES256-SHA  SSLv3 Kx=DH   Au=DSS  Enc=AES(256)  Mac=SHA1
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH   Au=RSA  Enc=Camellia(256) Mac=SHA1
DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH   Au=DSS  Enc=Camellia(256) Mac=SHA1
ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) 
Mac=AEAD
ECDH-RSA-AES256-SHA384  TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA384
ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA384
ECDH-RSA-AES256-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA1
ECDH-ECDSA-AES256-SHA   SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA1
AES256-GCM-SHA3

Re: explicit cipher list

[li...@rhsoft.net]

Am 08.11.2013 00:50, schrieb Viktor Dukhovni:
> On Fri, Nov 08, 2013 at 12:27:13AM +0100, li...@rhsoft.net wrote:
> 
>>> If you MUST muck around with raw OpenSSL cipherlists, the underlying
>>>
>>> tls__cipherlist
>>>
>>> parameters are present and documented, along with appropriate
>>> warnings to not go there.
>>>
>>> Note that Postfix will still apply implicit and configured exclusions
>>> to these based on context (!aNULL when verifying peer certificates)
> 
> READ THE ABOVE "Note" carefully.  The exclusions are applied on
> top of the cipher grade at run time.  They don't modify the underlying
> cipher list that defines the base ciphers for the grade.

i read it carefully but i still do not find away to get SMTP
configured with exactly the same ciphers in the same order
nor see a way to get the effective list

the intention is that i see clients with broken TLS handshakes on
SMTP while they work pretty fine on dovecot with the hardcoded
cipherlist and it's hard to impossible debug this with endusers

since they successful log into POP3/IMAP with TLS i assume the
same client would happily do the same with identical cipherlists
on SMTP while i even do not know which sort of device or if
it is more than one device behind a NAT

>> that does not work with "smtpd_tls_security_level = may" and
>> "smtpd_tls_security_level = encrypt"
> 
> Pilot error

how is it a pilot error that i can't turn back time 10 years and configure
hundrets of client devices to not break them with set to "encrypt" where
especially smartphones tend to not give out any error messages to the user

there is a existing userbase from long before my time :-(

Re: explicit cipher list

[li...@rhsoft.net]

thank you very much for all that informations

i will add this message to my documentation archive and have a look
how hard it is really needed to tweak here - also saw consumer grade
routers breaking TLS until restart them

somehow i do not expect that Outllok 2010 on Windows 8 has more problems
than on WinXP which was recently the problem with no time to debug
this deeper

Am 08.11.2013 02:17, schrieb Viktor Dukhovni:
> On Fri, Nov 08, 2013 at 01:05:33AM +0100, li...@rhsoft.net wrote:
> 
>>>>> Note that Postfix will still apply implicit and configured exclusions
>>>>> to these based on context (!aNULL when verifying peer certificates)
>>>
>>> READ THE ABOVE "Note" carefully.  The exclusions are applied on
>>> top of the cipher grade at run time.  They don't modify the underlying
>>> cipher list that defines the base ciphers for the grade.
>>
>> I read it carefully, but I still do not find a way to get SMTP
>> configured with exactly the same ciphers in the same order
>> nor see a way to get the effective list
> 
> The effective list is the ${tls__cipherlist} plus any
> exclusions.  The grade is determined via ${smtpd_tls_ciphers} (for
> smtpd_tls_security_level = may) and ${smtpd_tls_mandatory_ciphers}
> (for smtpd_tls_security_level = encrypt).
> 
> The Postfix default cipher-suites are chosen to avoid freezing-in
> any particular OpenSSL's version's cipher choices.  Instead of
> explicit choices of discrete ciphers, cipher properties are used
> to sort the lists, and make appropriate exclusions.
> 
> If you don't like the default value of:
> 
>   tls_medium_cipherlist
>   tls_export_cipherlist
> 
> and for your site you prefer a different setting (generally
> interoperability suffers when everyone goes their own way)
> you can change this to whatever you want.
> 
>> The intention is that I see clients with broken TLS handshakes on
>> SMTP while they work pretty fine on dovecot with the hardcoded
>> cipherlist and it's hard to impossible debug this with endusers
> 
> tcpdump + wireshark always tell the whole story.
> 
>>> Pilot error
>>
>> How is it a pilot error ...
> 
> You're expecting tls_medium_cipherlist, ... to reflect cipher
> exclusions.  They don't.  Cipher exclusions are applied *after*
> these parameters are read.  Setting "smtpd_tls_loglevel = 2"
> (on a non-default port) and connecting to that port with
> "openssl s_client -starttls smtp" (or similar) will log
> the actual cipherlist used by smtpd(8).
> 
> Bottom line:
> 
> - Postfix has cipher grades, they make life easier for most users.
> 
> - Postfix has configurable OpenSSL cipherlists for each grade.  Tweak
>   these if you must.
> 
> - Postfix appends dynamic exclusions to the ciphergrade lists as
>   documented.  The combined list (with exclusions appended) is not
>   directly visible via postconf.
> 
> With smtpd(8) there are no implicit exclusions so you can build the
> full list yourself if you want.  For example with opportunistic TLS
> (may):
> 
> $ server_ciphers() {
>   local use skip ciphers exclude e
>   case $1 in 
>   may)
>   use="tls_export_cipherlist"
>   skip="smtpd_tls_exclude_ciphers";;
>   encrypt)
>   use="tls_medium_cipherlist"
>   skip="smtpd_tls_mandatory_exclude_ciphers";;
>   esac
>   ciphers="$(postconf -xh $use)"
>   exclude="$(postconf -xh $skip)"
>   if [ -n "${exclude}" ]; then
>   OIFS="$IFS"; IFS=":,$OFS"
>   set -- $exclude
>   IFS="$OIFS"
>   for e; do ciphers="$ciphers:"'!'"$e"; done
>   fi
>   openssl ciphers -v "$ciphers"
> }
> 
> $ server_ciphers encrypt
> 
> Server cipherlists don't matter much (the more the merrier), since
> all the server has to do is accept one element from the client's
> list.  So tuning server cipher lists is not that useful.  For
> submission, you just want to exclude "EXPORT" and "LOW".  Leaving
> out ciphers can just cause interoperability problems.
> 
> If the server is configured to pre-empt the client preference list,
> it may be able to choose better than the client, but the client
> should not offer ciphers it can't do, so this should not impact
> interoperability significantly.
> 
> Finally, if you build your own Postfix server, it may be using a
> more recent OpenSSL toolkit, and that can make a big diffe

Re: postfix 2.7.1 debian - does not query DNS

[li...@rhsoft.net]

Am 08.11.2013 10:42, schrieb DTNX Postmaster:
> $ cat  /usr/share/doc/postfix/README.Debian
> There are some significant differences between the Debian Postfix packages,
> and the source from upstream:
> 
> 1.  The Debian install is chrooted by default.
> 2.  Dynamically loadable map support.
> 3.  For policy reasons:
>   a. SASL configuration goes in /etc/postfix/sasl
>   b. myhostname=/path/to/file is supported (and used) in main.cf
> 4.  IPV6 support is enabled: postfix listens on ipv6/ipv4 by default,
> (see: inet_protocols)
> 5.  TLS/SASL support is enabled.
> 6.  rmail comes from sendmail, not from postfix.
> 7.  The upstream main.cf is delivered as /usr/share/postfix/main.cf.dist,
> rather than cluttering /etc/postfix/main.cf with comments.
> 
> As annoying as Debian can be at times with the choices they make, I 
> would suggest that it's ultimately the responsibility of the deploying 
> administrator to be aware of any caveats, especially when they are 
> listed in the documentation, or relatively easy to find with a web 
> search

there are only rare situations where a chrooted postfix
makes sense and so they should not making a problematic
default which gains nothing on 999 out of 1000 setups

Re: AOL won't even talk to me

[li...@rhsoft.net]

Am 08.11.2013 13:45, schrieb mark hardwick:
> Pretty much everything is working with my new mail server now.
> Google, hotmail etc are all chatting nicely to me, AOL on the other had just 
> says
> 
> postfix/smtp[31792]: 3DDC64827D: host mailin-03.mx.aol.com[205.188.156.193] 
> refused to talk to me: 421 mtain-dl02.r1000.mx.aol.com Service unavailable - 
> try again later

the real question is *how often*

if you have peaks to a destination they may throttle you down
and that is not only AOL, that's why it is a temporary errr

4xx is *always* temorary and postfix *will* try later

Re: sasl by sender

[li...@rhsoft.net]

Am 15.11.2013 20:50, schrieb Pol Hallen:
> Hi all, I've finished to read sasl authentication and I can send email
> using it.
> 
> Now I'd like that postfix send the email using the sasl username
> (te...@mydomain.com) and not with the sender of email client, because with
> 1 sasl authentication, every users can send with same sasl account, ie:
> 
> us...@domain.org has a sasl authentication (ie: us...@domain.org)
> 
> but also us...@domain.org can send using sasl authentication
> (us...@domain.org) and recipient receives different sender name.
> 
> I need filter for the sender of email client

http://www.postfix.org/postconf.5.html#smtpd_sender_login_maps

Re: reject_sender_login_mismatch problem

[li...@rhsoft.net]

Am 16.11.2013 19:44, schrieb Pol Hallen:
> Hi all :-) I configurated postfix to check if a client is within the
> 
> smtpd_sender_login_maps = hash:/etc/postfix/smtpd_sender_login_maps
> 
> with sasl sender authentication, and:
> 
> smtpd_recipient_restrictions =
> permit_mynetworks,
> permit_inet_interfaces,
> reject_sender_login_mismatch,
> permit_sasl_authenticated,
> 
> seem everything works fine, but I've some problem like this:
> 
> Sender address rejected: not logged in
> 
> when I try to send an email that relay by another smtp :-/
> any idea to solve this problem?

no because you refused to send log and postconf -n

Re: reject_sender_login_mismatch problem

[li...@rhsoft.net]

and where is the complete log of the message you are speaking
about in your initial post? you are long enough here to know
how debugging works and how it can't work

> mydestination = fuckaround

what's that?
this is not a domain

Am 16.11.2013 19:54, schrieb Pol Hallen:
> alias_database = hash:/etc/aliases
> alias_maps = hash:/etc/aliases
> anvil_rate_time_unit = 10s
> anvil_status_update_time = 120s
> append_dot_mydomain = no
> biff = no
> broken_sasl_auth_clients = yes
> config_directory = /etc/postfix
> delay_warning_time = 10m
> disable_vrfy_command = yes
> helpful_warnings = yes
> home_mailbox = Maildir/
> inet_interfaces = all
> inet_protocols = ipv4
> invalid_hostname_reject_code = 554
> maximal_queue_lifetime = 90d
> message_size_limit = 2048
> multi_recipient_bounce_reject_code = 554
> mydestination = fuckaround, fuckaround.org, localhost.localdomain,
> localhost, localhost.$mydomain
> myhostname = server1.fuckaround.org
> mynetworks = 127.0.0.0/8, 192.168.1.0/24
> myorigin = /etc/mailname
> policy-spf_time_limit = 3600s
> recipient_delimiter = +
> relay_domains_reject_code = 554
> relayhost = smtp.fastwebnet.it:587
> smtp_sasl_auth_enable = yes
> smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
> smtp_tls_note_starttls_offer = yes
> smtp_use_tls = yes
> smtpd_banner = $myhostname
> smtpd_client_message_rate_limit = 10
> smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated,
> reject_unauth_destination, check_policy_service unix:private/policy-spf,
> smtpd_helo_required = yes
> smtpd_recipient_restrictions = permit_mynetworks, permit_inet_interfaces,
> permit_sasl_authenticated, reject_unauth_destination,
> reject_invalid_hostname, reject_unknown_recipient_domain,
> reject_unauth_pipelining, check_policy_service unix:private/policy-spf,
> smtpd_sasl_auth_enable = yes
> smtpd_sasl_security_options = noanonymous
> smtpd_sender_login_maps = hash:/etc/postfix/smtpd_sender_login_maps
> smtpd_tls_CAfile = /etc/postfix/ssl/cacert.pem
> smtpd_tls_auth_only = no
> smtpd_tls_cert_file = /etc/postfix/ssl/smtpd.crt
> smtpd_tls_key_file = /etc/postfix/ssl/smtpd.key
> smtpd_tls_loglevel = 1
> smtpd_tls_received_header = yes
> smtpd_tls_session_cache_timeout = 3600s
> smtpd_use_tls = no
> strict_rfc821_envelopes = yes
> tls_random_source = dev:/dev/urandom
> unknown_address_reject_code = 554
> unknown_client_reject_code = 554
> unknown_hostname_reject_code = 554
> unknown_local_recipient_reject_code = 554
> unknown_relay_recipient_reject_code = 554
> unknown_virtual_alias_reject_code = 554
> unknown_virtual_mailbox_reject_code = 554
> unverified_recipient_reject_code = 554
> unverified_sender_reject_code = 554
> virtual_alias_domains = fuckaround.org
> virtual_alias_maps = hash:/etc/postfix/virtual
> virtual_gid_maps = static:5000
> virtual_mailbox_base = /home/vhosts
> virtual_mailbox_domains = hash:/etc/postfix/domains
> virtual_mailbox_limit_maps = hash:/etc/postfix/vquota
> virtual_mailbox_limit_override = yes
> virtual_mailbox_maps = hash:/etc/postfix/vmailbox
> virtual_maildir_extended = yes
> virtual_maildir_limit_message = "User over quota, try again"
> virtual_maildir_suffix =
> virtual_minimum_uid = 100
> virtual_overquota_bounce = yes
> virtual_trash_count = yes
> virtual_trash_name = ".Trash"
> virtual_uid_maps = static:5000

Re: How do I link Postfix to OpenSSL?

[li...@rhsoft.net]

Am 17.11.2013 17:45, schrieb Juerg Reimann:
> At http://www.postfix.org/postconf.5.html#smtp_tls_mandatory_protocols is 
> mentioned "As of OpenSSL 1.0.1 two new protocols are defined, "TLSv1.1" and 
> "TLSv1.2". If an older Postfix version is linked against OpenSSL 1.0.1 or 
> later, these, or any other new protocol versions, are unconditionally 
> enabled."
> 
> How do I link Postfix to a new OpenSSL version on my system? Does it mean, 
> that I have to recompile it?

yes or you find a pre-compiled package linked against whatever openssl package 
you are talking about

Re: Diffie-Hellman parameters

[li...@rhsoft.net]

Am 17.11.2013 23:36, schrieb Fedor Brunner:
> Please increase the size of Diffie-Hellman parameters in
> http://www.postfix.org/TLS_README.html
> You recommend 1024 bit DH parameters, but for long term protection,
> these parameters are too short.
> 
> During ephemeral Diffie-Hellman (EDH) key exchange a temporary key is
> generated from DH parameters. This temporary key is used for encryption
> of the communication and the server public RSA key is used ONLY for
> signing of this temporary key and NOT for encryption of the
> communication. If you use DH parameters shorter than you RSA key, you
> are weakening your encryption.
> 
> https://wiki.openssl.org/index.php/Diffie_Hellman
> https://wiki.openssl.org/index.php/Diffie-Hellman_parameters
> 
> 
> If you are interested in more technical information about key sizes I
> highly recommend:
> 
> http://www.keylength.com/en/compare/
> 
> Yearly Report on Algorithms and Keysizes (2012), D.SPA.20 Rev. 1.0,
> ICT-2007-216676 ECRYPT II, 09/2012.
> 
> Recommendation for Key Management, Special Publication 800-57 Part 1
> Rev. 3, NIST, 07/2012

that's all fine but breaks interoperability leading in opportunistic mode
which is needed on the MTA side to let clients fall back to *unencrypted*
connections - so you may consider what is better - 1024 bit or no
encryption at all

you can do that on a webserver but not on a MTA

Re: Client host name resolution

[li...@rhsoft.net]

Am 18.11.2013 12:43, schrieb E.B.:
> My understanding was clients for whom you see this in the logs:
> 
> connect from unknown[1.2.3.4]
> 
> Do not have a PTR/rDNS set up for themselves.  However, I recently tested a 
> connection (using telnet on the client side, connecting to port 25) from a 
> server that does have rDNS in place, but I still get the "connect from 
> unknown".
> 
> I did "dig -x 1.2.3.4" on the server for the same IP address and the result 
> came back with the correct domain name. So why didn't postfix see the host 
> name? I restarted postfix in case it was caching, but it didn't help.
> 
> I also tried putting this in /etc/hosts
> 
> 1.2.3.4  host.example.com
> 
> That didn't help, either.
> 
> Appreciate any tips.

check your master.cf that chroot is *explicit* set to NO

Re: Need Help: Postfix Relayhost Setup and Dovecot

[li...@rhsoft.net]

Am 18.11.2013 17:36, schrieb Dominique:
> Nov 18 17:10:15 mail postfix/smtp[20654]: 2937521D41:
> to=, relay=smtp.isp.es[1.1.1.1]:25, delay=1.1,
> delays=0.09/0/0.87/0.18, dsn=5.0.0, status=bounced (host
> smtp.isp.es[1.1.1.1] said: 522 Authenticate first (in reply to MAIL FROM
> command))
> 
> I understand that I need to authenticate first for the relayhost to kick
> in, and I thought I had it. (Applied the same logic from the cyrus
> setup), but it seems I missed something.
> 
> Can someone give me a hint ?

smtp_sasl_auth_enable = yes
is nowhere in your posted configuration

notice smtp_ versus smtpd_ while anyhting which is
relevant for sending message sto another MTA is smtp_

Re: hiding IP address and such

[li...@rhsoft.net]

Am 19.11.2013 00:58, schrieb John Allen:
> Is there any good reason to hide IP addresses and domain names etc when post 
> to this list

it is your responsibility to decide what can be disclosed and what not
but keep always in mind the more you obfuscate the harder someone can help debug

by obfuscate public ip-addresses as example nobody is able to verify connection,
PTR's and so on which maybe is the root cause of a problem

Re: TLS timeout

[li...@rhsoft.net]

Am 20.11.2013 13:55, schrieb bitozoid:
> On Tue, Nov 19, 2013 at 1:32 PM, Brian Evans  wrote:
>> The smtp client process does not have support for the deprecated smtps
>> protocol (465) you are trying to use.
> 
> I have another instance of postfix working against other smarthost
> (Exchange in this case) via port 465, and it seems not to be a problem
> at all

you do not - not with a public relay - period

> Afaik it is better to work with standard port numbers,
> but it is not a requirement

if the other side is your server and you configured 465 wrong with STARTTLS yes
but 587/465 is not only the port, 465 is TLS wrapper mode which means the
initial connection has to be done encrpyted and so it works technically
completly different than STARTTLS
___

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

Client-side SMTPS support
Although the Postfix SMTP client by itself doesn't support TLS wrapper mode, it 
is relatively easy to forward a
connection through the stunnel program if Postfix needs to deliver mail to some 
legacy system that doesn't support
STARTTLS. Use one of the following two examples, to send only some remote mail, 
or to send all remote mail, to an
SMTPS server.

Re: can someone explain this SPF fail to me

[li...@rhsoft.net]

Am 21.11.2013 18:40, schrieb jeffrey j donovan:
> Greetings,
> 
> Can someone explain this error to me, I have never seen this one before. I 
> tested my spf records and they seem fine. 
> 
>>> : host mail.ncem-pa.org[204.186.202.37] said: 554
>>>5.7.1 : Recipient address rejected: Failed SPF
>>>check; beth.k12.pa.us, Redundant applicable 'v=spf1' sender policies 
>>> found
>>>(in reply to RCPT TO command)
>>> Reporting-MTA: dns; smtp5.beth.k12.pa.us
> 
> in this , it looks like the user recipient address is incorrect or something 
> along those lines.
> I do have two spf records, one for my relays and one for google.  The remote 
> user has none

"Redundant applicable 'v=spf1' sender policies found" is pretty clear

> I do have two spf records, one for my relays and one for google

and that is what is called "redundant"
merge them in one

;; ANSWER SECTION:
beth.k12.pa.us. 28800   IN  TXT "v=spf1 ip4:209.96.107.0/24 
ip4:209.96.96.0/24 mx:beth.k12.pa.us
mx:bethsd.org ~all"
beth.k12.pa.us. 28800   IN  TXT 
"google-site-verification=JjPx6RdJsh1ILF2-zcX-g3xyhuuHPZxw28c_L2YVyFI"
beth.k12.pa.us. 28800   IN  TXT "v=spf1 include:_spf.google.com 
~all"

Re: Do not send mails to addresses with more than 3 dots in username part

[li...@rhsoft.net]

Am 22.11.2013 10:12, schrieb Alexander Farber:
> I run a Drupal 7 website on a CentOS 6.4 server with 
> postfix-2.6.6-2.2.el6_1.x86_64.
> 
> In the last few months the amount of fake users trying to register at my 
> website has increased dramatically - I get
> 2 or 3 of such registrations per minute.
> 
> Mostly they have fake mail adresses with many dots and at gmail.com 
> :
> 
> c.ar.eer.t...@gmail.com 
> all.ego.ry.nl@gmail.com 
> b.is.on.bk@gmail.com 
> 
> At the end those users can't register, because a mail confirmation is 
> required.
> 
> But my mailbox is filled with mail bounces and in the /var/log/maillog I see 
> my site contacting Gmail servers again
> and again

this should be solved on the website and not the MTA

* captcha
* hidden honeypot field
* session token
* don't accpet the e-mail address at all

problems needs to be solved on the root cause not worked around somewhere else

Re: Do not send mails to addresses with more than 3 dots in username part

[li...@rhsoft.net]

Am 22.11.2013 12:38, schrieb Alexander Farber:
> Thanks, I agree with all general advices...
> But for now I just want to stop the flood
> (and also Drupal is difficult to modify for me +
> I don't want to add CAPTCHA to my 
> already overloaded reg. form, etc., etc.)

zero understanding to refuse use of captchas these
days and wonder about flood of spam mails, really!

you believe you can stop the problem by filter out
addresses with more than 3 dots in username part?

how long?
until tomorrow, two days, a few weeks..

honestly any spammer reading this thread is still
working around your workaround before it is enabled

Re: Do not send mails to addresses with more than 3 dots in username part

[li...@rhsoft.net]

my last post in this thread because we are going off-topic

discard messages on a MTA is the *last resort* if nothing
else happens but not the solution for a broken web-app
because it is the wrong layer

hence even if you insist in "more than 3 dots in username part"
this belong to the *web application* and not to the MTA

Am 22.11.2013 12:51, schrieb Alexander Farber:
> I admin this website for 3 years already and 
> despite it being just a small obscure card game -
> there haven't been a month without a challenge,
> where I had to go and change something manually.

a admin 200 websites for 10 years already

> If you think, that a CAPTCHA or anything else
> will stop all the problems and you never have
> to touch anything, you are so wrong :-)

since i do my job for 10 years now i now that "never have to touch anything"
is plain wrong, but ignore problems root causes is terrible wrong

i good web-form these days doe snot relie only on the captcha

* it is using a captcha in first front
* it is using a hidden session token *too*
* it i using one or more spam-trap fields *too*

and after that is done hence i use even GeoIP to lock countries as i had
a regional website not long ago where all the guestbook spam came from
different ip-addresses in India and Pakistan which where for sure humans
because they passed all 3 protections a few times per day

Re: Do not send mails to addresses with more than 3 dots in username part

[li...@rhsoft.net]

Am 22.11.2013 15:31, schrieb Alexander Farber:
> I've spent last 2 hours with Drupal CAPTCHA module -
> the default image and math captchas didn't stop
> any spam user at all - I could see fake users
> still registering - every few seconds (scary!).
> 
> I have uploaded a russian font then and configured
> the CAPTCHA to use russian letters only 
> (since my site is targeting Russian users) - 
> this has stopped them for now.
> 
> I'm just saying, that the whole problem isn't trivial
> and obvious comments (install captcha etc.)
> aren't really helping here, that's why I asked 
> the specific postfix question here...

that's why i did not name captcha only besdies that your
"3 dots in username part" should happen on the webserver

* it is using a captcha in first front
* it is using a hidden session token *too*
* it is using one or more spam-trap fields *too*


that is why you got also another answer with https://drupal.org/project/honeypot

how such things are working?

* place some hidden fields with random values
* store that values in the server session
* expect on the server some of them submitted with the exact value
* expect on the server some of them submitted *not* with this value
  achieved by change them with javascript -tags to tell
  the user clearly he needs to enable it in case of noscript-extensions

the typical "attacker" will analyze the source code for hidden fields
and send the exact values - for all of them -> game lost because it
takes too much time and effort to find out what is allowed to be sumitted
with what value and even if i get broken in that context my next defense
would be to name these trap-fields randomly, shuffle which are allowed
and which are not and store an array in the server-session with that
choices - obfuscate that and a "attacker" needs to careful analyze
each time the source code -> guess hwat. he goes to a different website

that#s why i write my own CMS systems and avoid Wordpress, Drupal,
Jommla and what not because i can react to issues in a timly and
working manner


this *is not* a MTA issue and will never be

Re: can someone explain this SPF fail to me

[li...@rhsoft.net]

Am 23.11.2013 06:49, schrieb Benny Pedersen:
> jeffrey j donovan skrev den 2013-11-21 18:40:
> 
>>>> : host mail.ncem-pa.org[204.186.202.37] said: 554
>>>>5.7.1 : Recipient address rejected: Failed SPF
>>>>check; beth.k12.pa.us, Redundant applicable 'v=spf1' sender policies 
>>>> found
>>>>(in reply to RCPT TO command)
>>>> Reporting-MTA: dns; smtp5.beth.k12.pa.us
> 
> was it 2 txt records with v=spf1 on ncem-pa.org?

no because this is the RCPT which will unlikely block himself
because it's own SPF while the S is for SENDER

> there seems now no spf on this domain for
> https://dmarcian.com/spf-survey/beth.k12.pa.us it seems ok

yes because it is answered and fixed long ago
why start to reply to a 3 days old thread without read existing anserws?

 Original-Nachricht ----
Betreff: Re: can someone explain this SPF fail to me
Datum: Thu, 21 Nov 2013 18:53:51 +0100
Von: li...@rhsoft.net 
An: postfix-users@postfix.org

Am 21.11.2013 18:40, schrieb jeffrey j donovan:
> Greetings,
>
> Can someone explain this error to me, I have never seen this one before. I 
> tested my spf
> records and they seem fine.
>
>>> : host mail.ncem-pa.org[204.186.202.37] said: 554
>>>5.7.1 : Recipient address rejected: Failed SPF
>>>check; beth.k12.pa.us, Redundant applicable 'v=spf1' sender policies 
>>> found
>>>(in reply to RCPT TO command)
>>> Reporting-MTA: dns; smtp5.beth.k12.pa.us
>
> in this , it looks like the user recipient address is incorrect or something 
> along those lines.
> I do have two spf records, one for my relays and one for google.  The remote 
> user has none

"Redundant applicable 'v=spf1' sender policies found" is pretty clear

> I do have two spf records, one for my relays and one for google

and that is what is called "redundant"
merge them in one

;; ANSWER SECTION:
beth.k12.pa.us. 28800   IN  TXT "v=spf1 ip4:209.96.107.0/24 
ip4:209.96.96.0/24 mx:beth.k12.pa.us
mx:bethsd.org ~all"
beth.k12.pa.us. 28800   IN  TXT 
"google-site-verification=JjPx6RdJsh1ILF2-zcX-g3xyhuuHPZxw28c_L2YVyFI"
beth.k12.pa.us. 28800   IN  TXT "v=spf1 include:_spf.google.com 
~all"

Re: Postfix installation guid

[li...@rhsoft.net]

Am 23.11.2013 13:39, schrieb Kranti Kiran Patnaik:
> Can someone share a very good postfix 2.10 installation guide for managing 
> 2-5million emails per day? My current
> postfix is unable to handle such large volume as lot of emails are getting 
> stuck in the incoming folder and thus
> the deliveries are delayed upto 2-3 days. My current postfix configuration is 
> on the following platform
> 
> OS: RHELRed Hat Enterprise Linux Server release 5.4 (Tikanga) 32bit
> RAM: 4GB
> Postfix: postfix-2.3.3-2.1.el5_2, postfix-pflogsumm-2.3.3-2.1.el5_2 (rpms 
> installed which come through RHEL5.4)

for that high traffic you need *exremly* fast disks
which means a RAID with as much disks as possible

i would go so far to say you need more than one MX
to spread the load

http://blog.scoutapp.com/articles/2011/02/10/understanding-disk-i-o-when-should-you-be-worried

Re: Postfix installation guid

[li...@rhsoft.net]

Am 23.11.2013 15:25, schrieb Kranti Kiran Patnaik:
> I am going to have atleast 5 servers now to share the load, how do i split 
> the MX? 
> Can you guide me, do you have any documentation?
> 
> On Sat, Nov 23, 2013 at 7:51 PM, li...@rhsoft.net <mailto:li...@rhsoft.net> 
> 
> Am 23.11.2013 13:39, schrieb Kranti Kiran Patnaik:
> > Can someone share a very good postfix 2.10 installation guide for 
> managing 2-5million emails per day? My current
> > postfix is unable to handle such large volume as lot of emails are 
> getting stuck in the incoming folder and thus
> > the deliveries are delayed upto 2-3 days. My current postfix 
> configuration is on the following platform
> >
> > OS: RHELRed Hat Enterprise Linux Server release 5.4 (Tikanga) 32bit
> > RAM: 4GB
> > Postfix: postfix-2.3.3-2.1.el5_2, postfix-pflogsumm-2.3.3-2.1.el5_2 
> (rpms installed which come through RHEL5.4)
> 
> for that high traffic you need *exremly* fast disks
> which means a RAID with as much disks as possible
> 
> i would go so far to say you need more than one MX
> to spread the load
> 
> 
> http://blog.scoutapp.com/articles/2011/02/10/understanding-disk-i-o-when-should-you-be-worried

* don't reply off-list
* don't top-post

https://www.google.at/search?q=email+MX+round+robin

if you meant to *send* 5 Mio mails per day that is another story
forget it - you will hit all sort of rate-limits until you
can not spread the outgoing messages over differnt source
IP's - in that case no further support of me because i hardly
can think of 5 Mio *legit* mails per day which is not spam

> How do i take that information from my server? I am new to this,
> can you guide me

it is a bad idea if you are new in maintain a mailserver
start with such a big beast - that will not work

Re: Do not send mails to addresses with more than 3 dots in username part

[li...@rhsoft.net]

Am 23.11.2013 20:18, schrieb tejas sarade:
> OK, got it.
> 
> Add the following line in main.cf  file to add new recipient 
> restriction which will use pcre table. 
> 
> smtpd_recipient_restrictions = check_recipient_access 
> pcre:/etc/postfix/pcre_recipients, permit_mynetworks,
> reject_unauth_destination

have fun with "reject_unauth_destination" too late and
"check_recipient_access" says "PERMIT" instead "DUNNO"

a major mistake and becuase it is made too often smtpd_relay_restrictions
was included in the lastest releases

http://www.postfix.org/SMTPD_ACCESS_README.html#danger

Re: Do not send mails to addresses with more than 3 dots in username part

[li...@rhsoft.net]

Am 23.11.2013 22:48, schrieb Peter:
> On 11/24/2013 08:25 AM, li...@rhsoft.net wrote:
>>
>> have fun with "reject_unauth_destination" too late and
>> "check_recipient_access" says "PERMIT" instead "DUNNO"
>>
>> a major mistake and becuase it is made too often smtpd_relay_restrictions
>> was included in the lastest releases
>>
>> http://www.postfix.org/SMTPD_ACCESS_README.html#danger
> 
> From the original post:
>> I run a Drupal 7 website on a CentOS 6.4 server with 
>> postfix-2.6.6-2.2.el6_1.x86_64.
> 
> smtpd_relay_restrictions was not introduced until postfix 2.10.  At any
> rate, he should be safe as long as there are no PERMIT actions in his
> pcre_recipients file.

and that is why i said "in lastest releases" to point out that
configure a MTA is not a game and dangerous until you don't
know exactly what you are doing *because* smtpd_relay_restrictions
did *not* exist as safety net for major mistakes in the past

Re: malformed mx record

[li...@rhsoft.net]

nobody said that anywhere

if they receive mails from other senders that senders
are *not* using DNS and ignore the MX

Am 05.12.2013 15:26, schrieb Roman Gelfand:
> I am not sure I understand.  I am sending out email from postfix.
> Postfix looks up the target domain mx record.  Are you saying the
> domain the target domain's dns server varies response based on query
> source ip address?
> 
> On Thu, Dec 5, 2013 at 1:34 AM, Robert Schetterer  wrote:
>> Am 05.12.2013 03:12, schrieb Roman Gelfand:
>>> Supposedly, the recipients are getting their emails from other
>>> senders.  However, when sending email from postfix,  I get mx
>>> malformed bounce.
>>>
>>> I did a dig on mx record for that domain and got...
>>>
>>> enlglobal.com.  300 IN  MX  0 .
>>>
>>> Is this legit?  If yes, what is the mail server? what do I need to do
>>> for postfix to recognize it?
>>>
>>> Thanks in advance
>>>
>>
>> as far i remember...
>> normally this is a trick from the domain owner ,to say no mail for that
>> domain ( avoid typos etc ), if postfix did an error everything is fine,
>> you dont need to do anything, if you like mail from that domain  dns
>> record should be changed

Re: Postfix smtp relay in DMZ

[li...@rhsoft.net]

Am 06.12.2013 10:13, schrieb Andreas Kasenides:
> The scenario is a classic one:
> 1. one or more relay SMTP servers in DMZ
> 2. one or more backend SMTP servers on the inside network
> 3. There may or may not be separate incoming or outgoing designated SMTP 
> servers.
> 
> Now the desired functionality is (of course):
> 1. relay machines receive messages from outside AND inside
> 2. relays check for all the bad things (spam, viruses etc).
> 3. for incoming messages relays check for valid local users and reject 
> messages for invalid users
> 
> Such scenario allows all checks to be done at the entry point allowing 
> back-ends to
> function with the real nice messages and at a much reduced load.
> 
> But there is a problem. If you are a DMZ admin (or a security hawk) #3 
> functionality above is
> not possible without violating the DMZ policy, especially if you are dealing 
> with internal LDAP
> and DB servers which essentially house personal information.
> I am  very interested to find out how others deal with this conflict in an 
> SMTP centric set-up

i would write a script running internally to fetch that list and genereate a 
static
config file for postfix whis is refreshed via cron and copied to the server

the list of valid local users typically does not change all day long

Re: Design details of high performance dovecot cluster

[li...@rhsoft.net]

Am 06.12.2013 11:32, schrieb JEHERUL:
> Currently we are running a mail system for 1 users each 2GB mailbox. At 
> present we have 5 mail servers where
> users mailboxes are distributed almost uniformly. We have a HP SAN Storage 
> (HP EVA 6400) where mailboxes are
> stored. We partition the storage into five vg and each is mounted on the 5 
> servers. We are using postfix and dovecot.
> 
> The system was running fine but currently we  notices high IO load due to 
> IMAP connection. So we are planning to
> build a dovecot cluster.
> 
> Please suggest some design for the dovecot cluster keeping in mind to our 
> scenario. (If needed we can buy
> additional hardware like load balancer)

this belongs to the dovecot-list

however, maybe look at the dovecot proxy feature
http://wiki2.dovecot.org/PasswordDatabase/ExtraFields/Proxy

you could split the userbase to different machines while the connection
happens always on the proxy which can with a sql-database containing
the target server spread the load, this way the dovecot-proxy would
be the load-balancer and I/O no longer on one machine

but as you say "HP SAN Storage" which is typically used as shared
storage avoid using the same storage backend for the other machines

on the other hand:
consider look for a enclosure to add more disks to the SAN storage
the more disks the spindle has the more IOPS/performance

at least for the HP MSA series are enclosures available for
12 additional disks on the same controller

Re: Misdeliveries of messages

[li...@rhsoft.net]

Am 09.12.2013 20:03, schrieb LuKreme:
> In our previous episode (Monday, 09-Dec-2013), Wietse Venema said:
>> Instead, you need to eliminate all characters except those that are
>> known to be safe: a-zA-Z0-9_@:=+, the '-', and maybe a few more.
> 
> what about é and ø? Or aren't we utf-8 clean on email addresses yet?

* the local part must not contain special chars
* the domain itself does not exist with UTF8

if you look at a nameserver configured vor a IDN domain
you will see nothing else than Punnycode, in fact any client
translates the userinput to punnycode

honestly you have everywhere Punnycode (DNS, webserverconfig as
well as mailserverconfig) and nothing else on the low-level side
and so postfix will hardly see unicode in the envelope

http://en.wikipedia.org/wiki/Punycode

Re: Misdeliveries of messages

[li...@rhsoft.net]

Am 10.12.2013 15:18, schrieb LuKreme:
> In our previous episode (Monday, 09-Dec-2013), "li...@rhsoft.net" said:
>> * the local part must not contain special chars
> 
> Is that your policy or are you claiming that is a standard? 

it is fact

> RFC 6530 covers UTF-8 email addresses and how they should be handled my MTAs.

fine, read it, how does this affect the current world?
http://www.rfc-editor.org/info/rfc6530

Status: PROPOSED STANDARD
IETF State: WG Document
Consensus: Unknown

http://datatracker.ietf.org/doc/rfc6530/?include_text=1
_

in order to use internationalized email addresses, it is necessary to
internationalize both the domain part and the local part of email
addresses.  The domain part of email addresses is already
internationalized [RFC5890], while the local part is not.  Without
the extensions specified in this document, the mailbox name is
restricted to a subset of 7-bit ASCII [RFC5321]

Though MIME [RFC2045] enables the transport of non-ASCII data, it does not
provide a mechanism for internationalized email addresses.  In RFC
2047 [RFC2047], MIME defines an encoding mechanism for some specific
message header fields to accommodate non-ASCII data.  However, it
does not permit the use of email addresses that include non-ASCII
characters.  Without the extensions defined here, or some equivalent
set, the only way to incorporate non-ASCII characters in any part of
email addresses is to use RFC 2047 coding to embed them in what RFC
5322 [RFC5322] calls the "display name" (known as a "name phrase" or
by other terms elsewhere) of the relevant header fields.  Information
coded into the display name is invisible in the message envelope and,
for many purposes, is not part of the address at all.

Re: Misdeliveries of messages

[li...@rhsoft.net]

Am 11.12.2013 14:37, schrieb Marcin Szymonik:
>> The real fix is not to process the above commands with the shell.
> 
> Thanks for these tips too.
> 
> I decided to popen() directly to sendmail without saving a message to tmp 
> file.
> Unfortunately I don't see any php function allowing to popen without 
> executing a command with the shell.
> What do you think would be the best solution?
> Switch to another scripting language?

the scripting language does not matter, the dangerous call of
shell commands with unknown remote input is the problem

see here why
http://www.securityfocus.com/archive/1/526591

don't do such things on a server
talk with network services and not with shells and pipes

> Switch to "advanced content filter" like described at 
> http://www.postfix.org/FILTER_README.html?

switch to a "advanced content filter"

Re: Misdeliveries of messages

[li...@rhsoft.net]

Am 11.12.2013 14:49, schrieb M.Atıf CEYLAN:
> On 11-12-2013 15:37, Marcin Szymonik wrote:
>> Unfortunately I don't see any php function allowing to popen without 
>> executing a command with the shell. 
> There are some functions in php to executing shell or another program. exec, 
> system or piping like popen (popen,
> fopen). But I think you want to do "without executing". This is possible only 
> with system chmod setting it's not
> related any language

please read the thread, nobody is talking about system chmod
the question is how to avoid *the need* of execute a script/application with 
params
the answer is use network-aware daemons instead

Re: Is it possible to verify "from:" header addresses?

[li...@rhsoft.net]

Am 14.12.2013 00:18, schrieb Adam Moffett:
> We're doing sender verification for our local domains, so a message sent from 
> "f...@plexicomm.net" gets rejected. 
> A message with an envelope sender of "va...@spammer.com" with a from: header 
> of "f...@plexicomm.net" gets
> accepted.  Is there a way to enable verification on "from:" header addresses?

in other words you want to block your own messages to this list?
why? look in the headers! bad idea what you try to do!
as well you would block *many* other legit mail!

Re: new postfix on centos 6.5

[li...@rhsoft.net]

Am 14.12.2013 16:19, schrieb Danil Smirnov:
> Joni, thank you very much!
> 
> Now I've found several RPMs but I don't know their creators - so they
> are very unsecure for me... May by you can point me to some official
> source for such RPMs?
> 
> Another option is to build postfix from sources...
> 
> Are there any trusted repository for the new postfix versions
> for Centos??? It would be best solution...

define trusted.

in doubt install rpmbuild, download the src.rpm of CentOS
install it in your user-account as user which results in
the SPEC-File inside ~/rpmbuild/SPECS/ and the other sources
including the postfix-tarball in ~/rpmbuild/SOURCUES/

put the recent postfix-tarball in ~/SOURCES/, edit postfix.spec
and fire up "rpmbuild -bb postfix.spec", a minute later you have
a 100% trustable and recent postfix-rpm under ~/rpmbuild/RPMS
which can be updated with "yum update *.rpm" and reused on as
much machines you have

there are a few steps to init the build-envirnonment
http://wiki.centos.org/HowTos/SetupRpmBuildEnvironment

i prefer doing such things inside a virtual machine the last
6 years, download the generated RPMs from there and place them
in on my own webserver hosting a repo, makes it easy to
snapshot and backup the build-environment and even roll out
a clone on a different infrastructure

in the meantime i maintain any relevant server software with
overrides this way to keep them recent and optimize compiler/hardening
flags

Re: Is it possible to verify "from:" header addresses?

[li...@rhsoft.net]

Am 16.12.2013 19:30, schrieb Adam Moffett:
> 
>>> We're doing sender verification for our local domains, so a message sent 
>>> from "f...@plexicomm.net" gets rejected.
>>> A message with an envelope sender of "va...@spammer.com" with a from: 
>>> header of "f...@plexicomm.net" gets
>>> accepted.  Is there a way to enable verification on "from:" header 
>>> addresses?
>> in other words you want to block your own messages to this list?
>> why? look in the headers! bad idea what you try to do!
>> as well you would block *many* other legit mail!
>>
> Why would that block my message to this list? adamli...@plexicomm.net is in 
> the from: header and that's a valid
> address which my server could verify

if you block forged senders and take the From-header into account
you block your own messages you wrote to this list - period

*do not* block based on random headers and if you do so don't
whine if things going terrible wrong

in case of SMTP *envelope* is what counts