Re: Postfix very slow accepting a mail having a massive recipient list

[Michael Tokarev]

On 20.01.2012 04:39, Stan Hoeppner wrote:
[]
>>> But that
>>> alone isn't going to fix a 10x performance deficit.  You've probably got
>>> multiple factors degrading performance.
>>
>> Yes, you have right. But I found recently, that disk mounted on my
>> server are slow 5.9K. My tests on in shows that they do fsync 1.5x-2x
>> slower than 7.2K with quite often 5x-10x slower peak. Together with
>> raid10, lvm, ext4, and much heavier load during delivery it may give
>> effect I'm observing.
> 
> 5.9K RPM?  Bingo.  There's the problem.  Those are "green" drives, from
> one manufacturer or another, probably Western Digital EARS 2TB drives.

Most likely seagate. WD usually either does not tell the speed (saying
it varies) or they're 5.4K RPM.

> They are not suitable for RAID use, nor server use, nor any high
> performance use whatsoever.  As you've seen first hand their performance
> is low, unpredictable, and unreliable.
> 
> In addition, they are "Advanced Format" drives, meaning 4KB hardware
> sectors but reported to the host as 512 byte sectors.  This can cause
> stripe alignment problems with RAID and the filesystem, which will
> exacerbate fsync delays.  Normally this misalignment is only an issue
> with parity arrays but it can also affect non parity striped arrays in
> certain configurations.

> Needless to say, you're not going to get decent queue spooling
> performance with these green drives, ever.  If you can't wholesale swap
> these 8 drives for units suitable for mail server duty, consider
> sticking two small inexpensive 7.2k SATA drives in the box and mirroring
> them.  Move the Postfix spool directory onto them--and any other
> applications you're running that need higher random IOPS performance
> than you're going to get from these green drives.


Please excuse me for the somewhat harsh words, but except of the
alignment issues which should be solved for once when partitioning
and creating filesystem, the rest is a complete bullshit collected
from various forums where people does not understand what they're
doing and blame bad drives.

I understand this is not a proper place to discuss this too: it is
postfix, it is not a disk comparison forum.  But I can't resist.

These drives are excellent when set up and used properly (the
misalignment issue you mentioned is real indeed, and MUST be
taken into account: everything should be aligned to 4Kb, lots
of especially old tools don't do that or even don't LET you to
do that - eg cfdisk in linux).  Very reliable, fast and
predictable.

I'll give just one note about speed, which may look completely
wrong at first.  The reason they're speedy is that at their
low rotational speed, they also have much more data density, --
ie, basically, they can transfer much more data during single
rotate.  This way, their linear speed (sequentional read or
write) often goes FASTER than enterprize-class 15KRPM drives
which are of much less volumes (300-600Gb as opposed to 1 or
2Tb or more for these "green" drives).

Yes, due to slower rotational speed, they take more time to
position platter to the right place.  But that's, again, not
whole story: the seek time is about the same as for their
"elder" brothers.  Now, use just first 300 or 600Gb out of
this 2Tb drive, to have more fair comparison with 15KRPM
drives, and you realize that the seek time improves greatly,
since we now have to seek less!

That's about speed.  As you can see, the picture is FAR from
definitive.

Their speed is reduced _dramatically_ when the drive have to
resort to read-modify-write cycle when the host sends data to
write in 512-byte units instead of in 4kb units, or when the
blocks are not aligned to 4kb.  This is where 99% of hysteria
comes from in various forums where people blame these drives.
And this one can't be solved 100% by doing right partitioning
and filesystem alignment: in addition to right alignment,
_size_ of each block being transferred matters too, it should
not be 512 but 4096.  This is where some operating systems
(especially windowsXP which is still used alot) cant guarantee
the right size.  Linux, especially recent kernel versions, is
much better, but here, again, it largely depends on the
filesystem.

Note that it is very difficult (lacking proper tools) to align
msdos-style partitions properly, since traditionally, all
partitions in extended partition are aligned to (chs)+512, and
all older tools will force the +512 shift.

That's enough for now about speeed.

As for reliability, it is not better and not worse than any
other drives.  One can argue that "enterprise-grade" drives
are more reliable, but that's very questionable still.  And
these "consumer-grade" drives have an advantage: they cost
alot less, so for the same money you can get several of them
to use them in higher-redundrancy raid array, to back the
theorerical lack of high reliability.

> This is likely the least expensive way, in both $$ and effort, to solve
> your problem.

I never tried running mailserver 

Re: Postfix very slow accepting a mail having a massive recipient list

[Konrad Rzepecki]

W dniu 20.01.2012 01:39, Stan Hoeppner pisze:

On 1/19/2012 5:07 AM, Konrad Rzepecki wrote:

Yes, you have right. But I found recently, that disk mounted on my
server are slow 5.9K. My tests on in shows that they do fsync 1.5x-2x
slower than 7.2K with quite often 5x-10x slower peak. Together with
raid10, lvm, ext4, and much heavier load during delivery it may give
effect I'm observing.


5.9K RPM?  Bingo.  There's the problem.  Those are "green" drives, from
one manufacturer or another, probably Western Digital EARS 2TB drives.
They are not suitable for RAID use, nor server use, nor any high
performance use whatsoever.  As you've seen first hand their performance
is low, unpredictable, and unreliable.


I have Seagate Barracude LP 1.5TB drives.


Needless to say, you're not going to get decent queue spooling
performance with these green drives, ever.  If you can't wholesale swap
these 8 drives for units suitable for mail server duty, consider
sticking two small inexpensive 7.2k SATA drives in the box and mirroring
them



This is likely the least expensive way, in both $$ and effort, to solve
your problem.


But, unfortunately, impossible, a last for now. I make, from some time, 
changes in my sending software. I hope this workaround will be enough.


Anyway, thanks for your help.

--
   Konrad Rzepecki

reject_authenticated_sender_login_mismatch issue

[Anton Raytsin]

Hello.

I'd like to force users to send only e-mails with valid MAIL FROM and 
also From: header. I have found out a way to check MAIL FROM and SASL 
login and configured my main.cf like this:


smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no
append_dot_mydomain = no
readme_directory = no
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
myhostname = mail.mydomain.com
myorigin = mydomain.com
mydestination = localhost
relayhost =
mynetworks = 127.0.0.0/8
mailbox_size_limit = 0
message_size_limit = 104857600
recipient_delimiter = +
inet_interfaces = all
anvil_rate_time_unit=60s
smtpd_client_message_rate_limit=20
header_checks=regexp:/etc/postfix/header_checks
smtpd_helo_restrictions=permit_sasl_authenticated,check_helo_access 
hash:/etc/postfix/hello_access

smtp_sender_login_maps = mysql:$config_directory/mysql_login_maps.cf
virtual_mailbox_domains = 
proxy:mysql:$config_directory/mysql_virtual_domains_maps.cf

virtual_mailbox_base = /var/vmail
virtual_mailbox_maps = 
proxy:mysql:$config_directory/mysql_virtual_mailbox_maps.cf
virtual_alias_maps = 
proxy:mysql:$config_directory/mysql_virtual_alias_maps.cf

virtual_minimum_uid = 150
virtual_uid_maps = static:150
virtual_gid_maps = static:8
virtual_transport = dovecot
dovecot_destination_recipient_limit = 1
smtpd_sasl_auth_enable = yes
smtpd_sasl_exceptions_networks = $mynetworks
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sender_restrictions=reject_authenticated_sender_login_mismatch,permit_sasl_authenticated,check_sender_access 
regexp:/etc/postfix/sender_access,reject_non_fqdn_sender,reject_unknown_sender_domain,permit
smtpd_recipient_restrictions=reject_unauth_pipelining,permit_sasl_authenticated,permit_mynetworks,reject_invalid_hostname,reject_non_fqdn_recipient,reject_unknown_recipient_domain,reject_unlisted_recipient,reject_unauth_destination,reject_rbl_client 
bl.spamcop.net,permit


mysql_login_maps.cf:
user = user
password = password
hosts = localhost
dbname = mail
table = mailbox
select_field = username
where_field = username
additional_conditions = AND active='1'

But when I send any email from authenticated user, I receive error:

5.7.1 : Sender address rejected: not owned by user 
u...@mydomain.com.


How to fix it?

Access Map

[DN Singh]

Hello group,

I was configuring some restrictions on the Postfix level using access map.
It is in has format.
It is has a pretty good number of domains in it. So, I was wondering, how
large can be the file, without affecting the performance?
These are configured in recipient restrictions, so during each and every
mail, it will do a lookup for that domain.
Please consider the scenario and let me know the limit.

Thanks.

Re: Spamcop listed gmail?

[Simon Brereton]

On Jan 19, 2012 7:13 PM, "Steve Fatula"  wrote:
>>
>> From: Robert Fitzpatrick 
>> To: Postfix 
>> Sent: Monday, January 16, 2012 1:12 PM
>> Subject: Spamcop listed gmail?
>>
>> Perhaps this is not the place for this, I didn't find a mailing list on
>> the spamcop site and just looking to see if this is experienced by
>> others. Got two calls this morning, both not receiving mail from gmail
>> users and both being blocked by my usage of 'reject_rbl_client
>> bl.spamcop.net'. Anyone other users of this config parameter seeing this?
>>
> You should not block outright. Either use a scoring system (perhaps
postscreen), or, DNSWL to first whitelist the servers.
>
> I personally report yahoo, gmail, etc. all the time via Spamcop when I
get spam from them. My hope is they will at least find the account and
disable it, possibly, with luck, even block emails going out just like it
in the future.

What he said...

Simon

MTA hosted on cloud server

[Ori Bani]

Hello,

I am evaluating a potential move of a mail server from a dedicated
server to a cloud-based server instance.  I am trying to research the
cons (I am comfortable with the pros) of doing so.

>From what I can tell, we have to consider possible performance issues
(e.g., I/O contention), although if you find a provider with a good
infrastructure/design or can afford to buy enough resources, this can
be minimized.

However, the issue that strikes me as the most serious (being somewhat
out of our control and dependent on people and factors that aren't all
that transparent) is that one might find the server in a Bad
Neighborhood.

This was covered almost a year and a half ago on this list already:

http://marc.info/?t=12811596731&r=1&w=2

But I am starting a new thread because a year and a half is a long
time and because I think there have been some developments in regard
to this issue of RBLs and cloud providers--

Amazon is the well-known example of a cloud provider that wound up on
at least one prominent RBL which caused a lot of grief.  I'm under the
impression that they have taken measures to deal with this problem,
although I haven't seen the details of this except in the form of some
forum posts that suggest that they have separated their dynamically
allocated netblocks from a pool of IP addresses that are tied to
customer accounts in a static manner.

This seems like a reasonable solution to that problem, but I'm not
100% sure that that's what they've done OR that it has proved to be a
good fix.

We aren't considering Amazon and would like to use a different cloud
hosting provider, but it's very difficult to tell what providers have
dealt with this problem (or if it is a problem at all -- some people
(see below) contend that it isn't an issue, but I don't think they
understand how Bad Neighborhoods affect MTAs around them).

I have been participating in a forum thread in a cloud
hosting-specific subforum where I thought I could get some good
feedback, but instead I've ended up having to explain and re-explain
why ranges of addresses that are somewhat frequently reassigned can be
bad news for anyone attempting to run a mail server. (I'd be thrilled
to have one of the experts from here come and do a better job of
explaining it than I have!!)

http://www.webhostingtalk.com/showthread.php?t=1117637

So is there anyone out there who runs a mail server from a cloud-based
server?  (non-Amazon as well as Amazon)

Can anyone here shed any light on the current state of cloud providers
and RBLs and/or dynamic netblock lists (and what has been done to help
remedy such issues)?

Thank you

Ori

Re: lost connection after EHLO from unknown

[Noel Jones]

On 1/19/2012 9:44 PM, santosh malavade wrote:
> hi,
> 
> this pertains to the issue raised by our unit in barbados, having ip
> address 173.225.251.221, i have included the said ip in debug_peer_list
> 
> we are getting lot of messages in the mail log showing the following
> 
> Jan 20 00:15:21 mailgate postfix/smtpd[18917]: lost connection after
> EHLO from unknown[173.225.251.221]
> Jan 20 00:26:21 mailgate postfix/smtpd[18917]: lost connection after
> CONNECT from unknown[173.225.251.221]
> Jan 20 03:17:53 mailgate postfix/smtpd[20255]: lost connection after
> CONNECT from unknown[202.43.9.67]
> 

"lost connection" means the tcp connection failed.  Don't bother
with the debug_peer_list; it's unlikely to help with this.

You can try capturing a tcpdump of the session.  Most likely it will
show the connection was lost and not much else.
http://www.postfix.org/DEBUG_README.html#sniffer

It might be more interesting to get a tcp recording on the other
end, if that's possible.

Does your offshore unit have a otherwise stable internet connection?
 Is this a wired connection or some kind of wireless or satellite?


  -- Noel Jones

lost connection after EHLO from unknown

[santosh malavade]

hi,

this pertains to the issue raised by our unit in barbados, having ip
address 173.225.251.221, i have included the said ip in debug_peer_list

we are getting lot of messages in the mail log showing the following

Jan 20 00:15:21 mailgate postfix/smtpd[18917]: lost connection after EHLO
from unknown[173.225.251.221]
Jan 20 00:26:21 mailgate postfix/smtpd[18917]: lost connection after
CONNECT from unknown[173.225.251.221]
Jan 20 03:17:53 mailgate postfix/smtpd[20255]: lost connection after
CONNECT from unknown[202.43.9.67]


my mail server configuration is given below :


mailgate:~ # postconf -n
canonical_maps = hash:/etc/postfix/canonical
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/lib/postfix
debug_peer_level = 2
debug_peer_list = 173.225.251.221
disable_dns_lookups = no
header_checks = regexp:/etc/postfix/header_checks
home_mailbox = Maildir/
inet_interfaces = all
mail_owner = postfix
mail_spool_directory = /var/mail
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
masquerade_classes = envelope_sender, header_sender, header_recipient
masquerade_exceptions = root
message_size_limit = 8703181
mydestination = $myhostname, localhost.$mydomain
myhostname = mailgate.asianpaints.com
mynetworks = 127.0.0.1/8 , 192.168.40.0/24 ,172.25.10.94/32
newaliases_path = /usr/sbin/sendmail
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/packages/postfix/README_FILES
recipient_canonical_maps = hash:/etc/postfix/recipient_canonical
relocated_maps = hash:/etc/postfix/relocated
sample_directory = /usr/share/doc/packages/postfix/samples
sender_canonical_maps = hash:/etc/postfix/sender_canonical
sendmail_path = /usr/sbin/sendmail
setgid_group = maildrop
smtpd_helo_required = yes
smtpd_recipient_restrictions = check_sender_access
hash:/etc/postfix/sender_access, check_recipient_access
hash:/etc/postfix/sender_access reject
strict_rfc821_envelopes = yes
transport_maps = hash:/etc/postfix/transport
virtual_maps = hash:/etc/postfix/virtual


the output of master.cf

mailgate:~ # cat /etc/postfix/master.cf | grep ^[^#]
smtp  inet  n   -   n   -   100 smtpd
587   inet  n   -   n   -   -   smtpd -v
pickupfifo  n   -   n   60  1   pickup
cleanup   unix  n   -   n   -   0   cleanup
qmgr  fifo  n   -   n   300 1   qmgr
rewrite   unix  -   -   n   -   -   trivial-rewrite
bounceunix  -   -   n   -   0   bounce
defer unix  -   -   n   -   0   bounce
flush unix  n   -   n   1000?   0   flush
smtp  unix  -   -   n   -   -   smtp
showq unix  n   -   n   -   -   showq
error unix  -   -   n   -   -   error
local unix  -   n   n   -   -   local
virtual   unix  -   n   n   -   -   virtual
lmtp  unix  -   -   n   -   -   lmtp
cyrus unix  -   n   n   -   -   pipe
  flags=R user=cyrus argv=/usr/lib/cyrus/bin/deliver -e -m ${extension}
${user}
uucp  unix  -   n   n   -   -   pipe
  flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail
($recipient)
ifmailunix  -   n   n   -   -   pipe
  flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp unix  -   n   n   -   -   pipe
  flags=Fq. user=foo argv=/usr/local/sbin/bsmtp -f $sender $nexthop
$recipient
vscan unix  -   n   n   -   10   pipe
  user=vscan argv=/usr/sbin/amavis ${sender} ${recipient}
procmail  unix  -   n   n   -   -   pipe
  flags=R user=nobody argv=/usr/bin/procmail -t -m /etc/procmailrc
${sender} ${recipient}
127.0.0.1:10025 inet  n  n  n  -  10 spawn
   user=filter   argv=/opt/kav/bin/smtpscanner
127.0.0.1:10026 inet  n  -  n  -  10  smtpd
-o content_filter= -o myhostname=mailgate


i have few days back increased the smtpd process count to 100 which was
specified as 50.

how do i go about resolving it.


rgds,


Santosh Malavade

Re: Postfix very slow accepting a mail having a massive recipient list

[Stan Hoeppner]

On 1/19/2012 5:07 AM, Konrad Rzepecki wrote:
> W dniu 19.01.2012 08:15, Stan Hoeppner pisze:
> 
>> To demonstrate that fsync alone shouldn't be a factor here,
> 
> But it is. I've straced sendmail to "fsync" waiting lot of time. It was
> 80% or more of queue time.
> 
>> Queuing 15K messages took 6 minutes 30 seconds on a single 7.2K drive,
>> again while competing with the delivery agent for spindle time.
> 
> My previous 1 drive 1 cpu box was also quick.
> 
>> If your kernel is using CFQ you may want to try deadline.
> 
> No change. Also try disable NCQ, set noatime, switch to reiser also - no
> effect either. Only change I found on 8 disk boot raid1 (no lvm) which
> appear even more slower.
> 
>> But that
>> alone isn't going to fix a 10x performance deficit.  You've probably got
>> multiple factors degrading performance.
> 
> Yes, you have right. But I found recently, that disk mounted on my
> server are slow 5.9K. My tests on in shows that they do fsync 1.5x-2x
> slower than 7.2K with quite often 5x-10x slower peak. Together with
> raid10, lvm, ext4, and much heavier load during delivery it may give
> effect I'm observing.

5.9K RPM?  Bingo.  There's the problem.  Those are "green" drives, from
one manufacturer or another, probably Western Digital EARS 2TB drives.
They are not suitable for RAID use, nor server use, nor any high
performance use whatsoever.  As you've seen first hand their performance
is low, unpredictable, and unreliable.

In addition, they are "Advanced Format" drives, meaning 4KB hardware
sectors but reported to the host as 512 byte sectors.  This can cause
stripe alignment problems with RAID and the filesystem, which will
exacerbate fsync delays.  Normally this misalignment is only an issue
with parity arrays but it can also affect non parity striped arrays in
certain configurations.

Needless to say, you're not going to get decent queue spooling
performance with these green drives, ever.  If you can't wholesale swap
these 8 drives for units suitable for mail server duty, consider
sticking two small inexpensive 7.2k SATA drives in the box and mirroring
them.  Move the Postfix spool directory onto them--and any other
applications you're running that need higher random IOPS performance
than you're going to get from these green drives.

This is likely the least expensive way, in both $$ and effort, to solve
your problem.

-- 
Stan

Re: Spamcop listed gmail?

[Steve Fatula]

From: Robert Fitzpatrick 
>To: Postfix  
>Sent: Monday, January 16, 2012 1:12 PM
>Subject: Spamcop listed gmail?
> 
>Perhaps this is not the place for this, I didn't find a mailing list on
>the spamcop site and just looking to see if this is experienced by
>others. Got two calls this morning, both not receiving mail from gmail
>users and both being blocked by my usage of 'reject_rbl_client
>bl.spamcop.net'. Anyone other users of this config parameter seeing this?
>
>You should not block outright. Either use a scoring system (perhaps 
>postscreen), or, DNSWL to first whitelist the servers. 

I personally report yahoo, gmail, etc. all the time via Spamcop when I get spam 
from them. My hope is they will at least find the account and disable it, 
possibly, with luck, even block emails going out just like it in the future.

Re: Declaring options for submission port daemon

[/dev/rob0]

On Thu, Jan 19, 2012 at 05:24:31PM -0500, Wietse Venema wrote:
> /dev/rob0:
> > If you want to see smtpd_restriction_classes gone crazy, refer
> > to my "howto" link from the site below. The particular page &
> > sections you would want is 02-postfix-sqlite.howto: see the
> > main.cf and the access-rcpt.query file therein. Bring a bottle
> > of aspirin.
>
> That looks like a good stress test for the new "unused parameter"
> checks in the postconf command :-)

Haha, that new feature actually did help in testing and debugging. 
When I did a "make upgrade" to a later snapshot I had some of them 
missing from the smtpd_restriction_classes list, and each iteration 
of postconf invoked from the Makefile complained about them. "Okay,
enough, I get it already, I will fix it!" :)
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: Declaring options for submission port daemon

[Wietse Venema]

/dev/rob0:
> If you want to see smtpd_restriction_classes gone crazy, refer to my 
> "howto" link from the site below. The particular page & sections you 
> would want is 02-postfix-sqlite.howto: see the main.cf and the 
> access-rcpt.query file therein. Bring a bottle of aspirin.

That looks like a good stress test for the new "unused parameter"
checks in the postconf command :-)

Wietse

Re: Declaring options for submission port daemon

[Noel Jones]

On 1/19/2012 3:24 PM, Nikolaos Milas wrote:
> On 19/1/2012 7:06 μμ, Noel Jones wrote:
> 
>> or define the restriction in main.cf and refer to it
>> ...
>> (or make up your own macro names)
> 
> Thank you all for your valuable suggestions.
> 
> These "macro names" seem really interesting. Can we use them in
> main.cf too (to define sets of restrictions) and how?
> 
> Thanks again,
> Nick

You can use them in main.cf, but I think they're more interesting in
master.cf.

An example to eliminate repetition:
# main.cf
mymap = hash:/etc/postfix/maps
smtpd_recipient_restrictions =
  permit_mynetworks
  reject_unauth_destination
  check_client_access $mymap/client_whitelist
  check_client_access $mymap/client_access
  check_sender_access $mymap/sender_access
  ...

documentation is at the top here:
http://www.postfix.org/postconf.5.html


If you're looking for a feature to do per-user restrictions, read up
on restriction classes
http://www.postfix.org/RESTRICTION_CLASS_README.html



  -- Noel Jones

Re: Declaring options for submission port daemon

[Wietse Venema]

Nikolaos Milas:
[ Charset UTF-8 unsupported, converting... ]
> On 19/1/2012 7:06 ??, Noel Jones wrote:
> 
> > or define the restriction in main.cf and refer to it
> > ...
> > (or make up your own macro names)
> 
> Thank you all for your valuable suggestions.
> 
> These "macro names" seem really interesting. Can we use them in main.cf 
> too (to define sets of restrictions) and how?

tls_export_cipherlist = ALL:+RC4:@STRENGTH
tls_high_cipherlist = ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH
tls_low_cipherlist = ALL:!EXPORT:+RC4:@STRENGTH
tls_medium_cipherlist = ALL:!EXPORT:!LOW:+RC4:@STRENGTH
tls_null_cipherlist = eNULL:!aNULL

I found these with: postconf | grep '[A-Z][A-Z][A-Z]:' :-)

Careful, this kind of settings provide a lot of opportunity
for shooting yourself into the foot.

Wietse

Re: Declaring options for submission port daemon

[/dev/rob0]

On Thu, Jan 19, 2012 at 11:24:10PM +0200, Nikolaos Milas wrote:
> On 19/1/2012 7:06 μμ, Noel Jones wrote:
> 
> >or define the restriction in main.cf and refer to it
> >...
> >(or make up your own macro names)
> 
> Thank you all for your valuable suggestions.
> 
> These "macro names" seem really interesting. Can we use them
> in main.cf too (to define sets of restrictions) and how?

Sure, but you might also be interested in this for groups of 
restrictions:

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

Using smtpd_restriction_classes allows you to use the class as a 
restriction in its own right, such as from another lookup table.

If you want to see smtpd_restriction_classes gone crazy, refer to my 
"howto" link from the site below. The particular page & sections you 
would want is 02-postfix-sqlite.howto: see the main.cf and the 
access-rcpt.query file therein. Bring a bottle of aspirin.

(Note: that howto document is not about restriction classes per se, 
but it contains an extreme example of how they can be used.)


PS: I wasn't going to announce that howto on the list until the 
rewrite is done. I'm working on that as we speak.
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: Declaring options for submission port daemon

[Nikolaos Milas]

On 19/1/2012 7:06 μμ, Noel Jones wrote:


or define the restriction in main.cf and refer to it
...
(or make up your own macro names)


Thank you all for your valuable suggestions.

These "macro names" seem really interesting. Can we use them in main.cf 
too (to define sets of restrictions) and how?


Thanks again,
Nick

Re: Declaring options for submission port daemon

[Nikolaos Milas]

On 19/1/2012 8:54 μμ, Mark Alan wrote:


This will give you a fairly secure submission:

submission inet n   -   -   -   -   smtpd
   -o syslog_name=postfix-submission
   -o tls_preempt_cipherlist=yes
   -o smtpd_tls_mandatory_ciphers=high
   -o smtpd_tls_exclude_ciphers=DES,3DES,MD5,aNULL
   -o smtpd_tls_security_level=encrypt
   -o smtpd_sasl_auth_enable=yes
   -o smtpd_client_restrictions=permit_sasl_authenticated,reject
   -o milter_macro_daemon_name=ORIGINATING

NOTES:
- in the submission line please note the second dash '-' instead of
   your 'n' (it is safe and wil spare you from a lot of chroot problems)

- if using a Postfix newer than v.2.2 you should use
   smtpd_tls_security_level=encrypt , instead of smtpd_enforce_tls=yes.
You can check postfix version using:  postconf | grep mail_version

- smtpd_tls_exclude_ciphers is used to exclude some of the weaker
   ciphers. Or, even better: DES,3DES,MD5,aNULL,AES128,CAMELLIA128
   To check what you will be getting execute:
openssl ciphers -v 'HIGH:!DES:!3DES:!MD5:!aNULL@STRENGTH'
openssl ciphers -v 'HIGH:!DES:!3DES:!MD5:!aNULL:!AES128:!CAMELLIA128@STRENGTH'



Thank you for the recommendations Mark.

I am running Postfix 2.8.3 (compiled from source) on Centos 5.7 64bit.

OpenSSL package is: openssl-0.9.8e-20.el5.

Here is the output (common for both commands you suggested):

# openssl ciphers -v 
'HIGH:!DES:!3DES:!MD5:!aNULL:!AES128:!CAMELLIA128@STRENGTH'

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
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1

What do we get from it?

Nick

Re: Declaring options for submission port daemon

[Mark Alan]

On Thu, 19 Jan 2012 18:43:28 +0200, Nikolaos Milas 
wrote:

> submission inet n   -   n   -   -   smtpd
>-o syslog_name=postfix/submission
>-o smtpd_enforce_tls=yes
>-o smtpd_sasl_auth_enable=yes
>   ...
> Any other options (except smtpd_*) which we should also redefine?

This will give you a fairly secure submission:

submission inet n   -   -   -   -   smtpd
  -o syslog_name=postfix-submission
  -o tls_preempt_cipherlist=yes
  -o smtpd_tls_mandatory_ciphers=high
  -o smtpd_tls_exclude_ciphers=DES,3DES,MD5,aNULL
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING

NOTES:
- in the submission line please note the second dash '-' instead of
  your 'n' (it is safe and wil spare you from a lot of chroot problems)

- if using a Postfix newer than v.2.2 you should use
  smtpd_tls_security_level=encrypt , instead of smtpd_enforce_tls=yes. 
You can check postfix version using:  postconf | grep mail_version

- smtpd_tls_exclude_ciphers is used to exclude some of the weaker
  ciphers. Or, even better: DES,3DES,MD5,aNULL,AES128,CAMELLIA128
  To check what you will be getting execute:
openssl ciphers -v 'HIGH:!DES:!3DES:!MD5:!aNULL@STRENGTH'
openssl ciphers -v 'HIGH:!DES:!3DES:!MD5:!aNULL:!AES128:!CAMELLIA128@STRENGTH'


 M.

Re: Declaring options for submission port daemon

[Noel Jones]

On 1/19/2012 10:43 AM, Nikolaos Milas wrote:
> Hello,
> 
> When defining options for the submission port (587) daemon in
> master.cf, we must re-define explicitly all smtpd_* settings or not,
> or some (*which?*) are inherited from the standard main.cf settings?

as others have responded, all settings are inherited.  You only need
to define settings that are different for that specific port.

> I also assume that we can also use here (i.e. in submission port
> options) for smtpd_recipient_restrictions check_recipient_access
> tables, the smtpd_restriction_classes we have defined in main.cf?

Yes, access tables and all smtpd* options can be used, but note
spaces aren't allowed in master.cf options.  As a workaround, use a
comma "," rather than a space ie.
 ...check_recipient_access,hash:/path/to/file

or define the restriction in main.cf and refer to it:
# main.cf
some_local_stuff =
  check_sender_access hash:/path/to/foo
  permit_sasl_authenticated
  reject
other_junk =
  check_client_access cidr:/path/to/bar

#master.cf
submission ... smtpd
  ...
  -o smtpd_client_restrictions=$other_junk
  -o smtpd_recipient_restrictions=$some_local_stuff
  ...

(or make up your own macro names)


  -- Noel Jones

Re: Declaring options for submission port daemon

[/dev/rob0]

On Thu, Jan 19, 2012 at 06:43:28PM +0200, Nikolaos Milas wrote:
> When defining options for the submission port (587) daemon in 
> master.cf, we must re-define explicitly all smtpd_* settings or 
> not, or some (*which?*) are inherited from the standard main.cf 
> settings?

All smtpd_* and relevant postconf(5) settings (default values if 
unset) are inherited by any smtpd(8) instance you define in your 
master.cf file -- UNLESS explicitly changed by -o options there. Use
"-o option" for those you need to have set differently.
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: Declaring options for submission port daemon

[Reindl Harald]

Am 19.01.2012 17:43, schrieb Nikolaos Milas:
> Hello,
> 
> When defining options for the submission port (587) daemon in master.cf, we 
> must re-define explicitly all smtpd_*
> settings or not, or some (*which?*) are inherited from the standard main.cf 
> settings? More specifically, should we
> define separately:

this should be enough
it's from a server with TLS and dovecot for SASL

submission  inet  n   -   n   -  50   smtpd
 -o smtpd_sasl_auth_enable=yes
 -o smtpd_delay_reject=yes
 -o smtpd_client_restrictions=permit_sasl_authenticated,reject



signature.asc
Description: OpenPGP digital signature

Declaring options for submission port daemon

[Nikolaos Milas]

Hello,

When defining options for the submission port (587) daemon in master.cf, 
we must re-define explicitly all smtpd_* settings or not, or some 
(*which?*) are inherited from the standard main.cf settings? More 
specifically, should we define separately:


submission inet n   -   n   -   -   smtpd
  -o syslog_name=postfix/submission
  -o smtpd_enforce_tls=yes
  -o smtpd_sasl_auth_enable=yes
  -o 
smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
  -o smtpd_recipient_restrictions=check_recipient_access 
hash:/etc/postfix/protected_destinations,

 permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination,
 reject_unknown_recipient_domain,reject_unverified_recipient
  -o smtpd_use_tls = yes
  -o smtpd_tls_auth_only = yes
  -o smtpd_tls_key_file = /etc/pki/tls/private/key.pem
  -o smtpd_tls_cert_file = /etc/pki/tls/certs/cert.pem
  -o smtpd_tls_CAfile = /etc/pki/tls/certs/chain.pem
  -o smtpd_tls_loglevel = 1
  -o smtpd_tls_received_header = yes
  -o smtpd_tls_session_cache_timeout = 3600s
  -o smtpd_sasl_auth_enable = yes
  -o smtpd_sasl_security_options = noanonymous
  -o broken_sasl_auth_clients = yes
  -o smtpd_sasl_type = dovecot
  -o smtpd_sasl_path = /var/spool/postfix/private/auth
  -o smtpd_delay_reject = yes

or is it enough to declare:

submission inet n   -   n   -   -   smtpd
  -o syslog_name=postfix/submission
  -o smtpd_enforce_tls=yes
  -o smtpd_sasl_auth_enable=yes
  -o 
smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
  -o smtpd_recipient_restrictions=check_recipient_access 
hash:/etc/postfix/protected_destinations,

 permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination,
 reject_unknown_recipient_domain,reject_unverified_recipient
  -o smtpd_use_tls = yes
  -o smtpd_tls_auth_only = yes
  -o smtpd_tls_received_header = yes
  -o smtpd_tls_session_cache_timeout = 3600s
  -o smtpd_sasl_auth_enable = yes
  -o smtpd_sasl_security_options = noanonymous
-o smtpd_delay_reject = yes

assuming that the following settings are inherited from main.cf?
  smtpd_tls_key_file = /etc/pki/tls/private/key.pem
smtpd_tls_cert_file = /etc/pki/tls/certs/cert.pem
smtpd_tls_CAfile = /etc/pki/tls/certs/chain.pem
smtpd_tls_loglevel = 1
broken_sasl_auth_clients = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = /var/spool/postfix/private/auth

I also assume that we can also use here (i.e. in submission port 
options) for smtpd_recipient_restrictions check_recipient_access tables, 
the smtpd_restriction_classes we have defined in main.cf?


Please correct me where I am wrong.

Any other options (except smtpd_*) which we should also redefine?

Thanks,
Nick

Re: log username for SMTP auth failures

[/dev/rob0]

On Wed, Jan 18, 2012 at 07:04:46PM -0800, William Yardley wrote:
> Running the RHEL 5 version of Postfix (2.3.3), and Cyrus SASL from
> version 2.1.22.
> 
> Currently, on an auth failure, saslauthd logs the username to
> the auth facility, but not the connecting IP (which presumably
> it doesn't know about). smtpd, which presumably does know the 
> username,

Wrong presumption.

> doesn't log it (not sure if this is to prevent logging
> in cases where someone sends a password as a username, or what).
> 
> e.g.,
> Jan 17 04:39:35 earth-doxen postfix/smtpd[14590]: warning: SASL 
> authentication failure: Password verification failed
> Jan 17 04:39:35 earth-doxen postfix/smtpd[14590]: warning: 
> ool-ad03c852.dyn.optonline.net[173.3.200.82]: SASL PLAIN 
> authentication failed: authentication failure
> 
> Once a user successfully authenticates, the sasl_username is
> logged.
> 
> Do later versions of Postfix log the username for auth failures?
> Is there any way to log this information with the version of
> Postfix that I have?

No, IIUC and in many/most cases it would not be possible, because 
when AUTH fails, there is no username to log:

> $smtpd_banner
< EHLO hostname.example
> (ehlo response including "250 AUTH PLAIN")
< AUTH PLAIN thisStringIsNotValidAUTH

Postfix is not equipped to decode that authentication token; it's 
merely passed along to the SASL implementation you chose.

If you are using Dovecot IMAP, you should not be using Cyrus SASL 
here, and Dovecot by default logs to mail facility. (Not necessarily 
what you want on a busy server, but in cases like you describe it 
helps, when using the Dovecot "auth_verbose = yes" setting.)

(There are numerous benefits to be had from upgrading to a current, 
supported Postfix version, but I'll not go into all that here.)

> Obviously, it's usually possible to piece together the saslauthd 
> and smtpd entries to figure out the whole story, but you could 
> imagine a scenario where there are two authentication failures 
> within the same second, or where for some other reason things
> don't match up perfectly.

That can be a problem even with all the logs in one file.
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: Problem with SMTPs SSL_accept error | lost connection after CONNECT

[Noel Jones]

On 1/19/2012 1:39 AM, bsd wrote:
> 
> Maybe I should use STARTTLS instead of the wrapper mode ? 

It's quite common to offer both, which I think is reasonable.

> 
> What are the pros and cons of each solution ? 

wrappermode is a non-standard legacy mode that some clients prefer.
 In their config screens, many clients refer to wrappermode on 465
as SSL, and STARTTLS as TLS.

There is no significant difference in security or functionality, but
the on-wire protocols are incompatible.

> 
> Can I provide both with the same auth backend mechanism (I use dovecot) ? 

You can enable both 587/STARTTLS and 465/wrappermode within the same
postfix with no extra configuration in the auth backend.

You can use syslog_name in master.cf to note which port a client is
using, something like:
smtps  smtpd
... everything else ...
-o syslog_name=postfix-smtps

submission ... smtpd
... everything else ...
-o syslog_name=postfix-submission



  -- Noel Jones

Re: Mailbox path not used

[/dev/rob0]

Top-posting fixed, please do not top-post your replies on this list.
Thanks.

On Thu, Jan 19, 2012 at 08:16:22AM +0100, Hervé Hénoch wrote:
> Le 18/01/2012 19:30, /dev/rob0 a écrit :
> >On Wed, Jan 18, 2012 at 10:59:46AM +0100, Hervé Hénoch wrote:
> >>In  main.cf  :
> >>
> >>home_mailbox = Maildir/
> >>virtual_mailbox_base = /mnt/vmail
> >>virtual_mailbox_domains = ldap:/etc/postfix/ldap-domains.cf
> >>virtual_mailbox_maps = ldap:/etc/postfix/ldap-accounts.cf
> >>virtual_alias_maps = ldap:/etc/postfix/ldap-aliases.cf
> >>
> >>In ldap-accounts.cf :
> >>query_filter =
> >>(&(objectClass=IscMailAccount)(mail=%s)(mailAccountActive=TRUE))
> >>result_attribute = mailbox
> >>
> >>So the drop directory for a user is the attribute mailbox prepended
> >>with "/mnt/vmail". I have putted for a user :
> >>
> >>mailbox = /opt/test
> >>
> >>But the mails always drop in /mnt/vmail// >>domain>  and not in /opt/test.

me:
> >You need to read and understand what virtual_mailbox_base is. It is
> >an absolute limit for where virtual(8) can deliver mail. You can
> >break that limit only if you hand off delivery to another delivery
> >agent without the limit.
> >
> >http://www.postfix.org/postconf.5.html#virtual_mailbox_base
> >http://www.postfix.org/virtual.8.html

Hervé:
> Thank you for your response. I've understood for the absolute 
> limit. But can you explain me what follows ?
> 
> virtual_mailbox_base = /mnt/vmail --> this is ok so all my 
> mailboxes directory will be under this directory.
> 
> But why for a user who has the following mail 
> "firstname.n...@isc84.org" the directory is 
> /mnt/vmail/isc84.org/firstname.name
> 
> even if I have setted the field mailbox to "test/toto". I expected
> to have /mnt/vmail/test/toto (under the absolute limit).

Okay, it seems I misunderstood what you were originally asking. The 
answer to that question lies in your virtual_mailbox_maps query. If

postmap -q firstname.n...@isc84.org ldap:/etc/postfix/ldap-accounts.cf

returns "isc84.org/firstname.name/" (with or without the trailing 
slash depending on mbox/maildir choice), perhaps you hardcoded a 
"result_format = %d/%u/" in /etc/postfix/ldap-accounts.cf .

http://www.postfix.org/LDAP_README.html
http://www.postfix.org/ldap_table.5.html
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: LDAP email-address translation

[Rolf E. Sonneveld]

On 1/19/12 12:19 PM, Michael Maymann wrote:

Hi List,

I have setup a mailrelay (outgoing mail only), and I would like to 
enable LDAP, so that all users localmail (maymann) on all my servers 
is send to my mailrelay and converted into globally-valid-addresses 
(michael.maym...@globaldomain.com 
) and we can read it from our 
standard globally-used-mailserver.


This is my current configuration:

main.cf :
---
queue_directory = /var/spool/postfix
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
mail_owner = postfix
mydomain = 
myorigin = $mydomain
inet_interfaces = all
mydestination = localhost, localhost.localdomain, $mydomain, 
dfm.test.com 

local_recipient_maps = unix:passwd.byname $alias_maps
unknown_local_recipient_
reject_code = 550
mynetworks = 127.0.0.0/8 , , , etc
relay_domains = $mydestination
relayhost = [] # this will be commented out when we effectuate 
the new config
# transport_maps = hash:/etc/postfix/transport # this will be 
commented in when we effectuate the new config

alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
debug_peer_level = 2
debugger_command =
 PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
 xxgdb $daemon_directory/$process_name $process_id & sleep 5
sendmail_path = /usr/sbin/sendmail.postfix
mailq_path = /usr/bin/mailq.postfix
setgid_group = postdrop
html_directory = no
manpage_directory = /usr/share/man
sample_directory = /usr/share/doc/postfix-2.3.3/samples
readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES
---

transport (everything will be commented in when we effectuate the new 
config):

---
## Relay own mail to own server
#our_own_domain  relay:
## Relay only mail to known external vendors
# relay:
# relay:
# relay:
# relay:
# relay:
---

Anyone who knows what is needed on my mailrelay for this to work ?


Use a canonical map of type ldap to replace sender addresses of the form 
usern...@host.maymann.org with first.l...@maymann.org.


/rolf

LDAP email-address translation

[Michael Maymann]

Hi List,

I have setup a mailrelay (outgoing mail only), and I would like to enable
LDAP, so that all users localmail (maymann) on all my servers is send to my
mailrelay and converted into globally-valid-addresses (
michael.maym...@globaldomain.com) and we can read it from our standard
globally-used-mailserver.

This is my current configuration:

main.cf:
---
queue_directory = /var/spool/postfix
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
mail_owner = postfix
mydomain = 
myorigin = $mydomain
inet_interfaces = all
mydestination = localhost, localhost.localdomain, $mydomain, dfm.test.com
local_recipient_maps = unix:passwd.byname $alias_maps
unknown_local_recipient_
reject_code = 550
mynetworks = 127.0.0.0/8, , , etc
relay_domains = $mydestination
relayhost = [] # this will be commented out when we effectuate the
new config
# transport_maps = hash:/etc/postfix/transport # this will be commented in
when we effectuate the new config
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
debug_peer_level = 2
debugger_command =
 PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
 xxgdb $daemon_directory/$process_name $process_id & sleep 5
sendmail_path = /usr/sbin/sendmail.postfix
mailq_path = /usr/bin/mailq.postfix
setgid_group = postdrop
html_directory = no
manpage_directory = /usr/share/man
sample_directory = /usr/share/doc/postfix-2.3.3/samples
readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES
---

transport (everything will be commented in when we effectuate the new
config):
---
## Relay own mail to own server
#our_own_domain  relay:
## Relay only mail to known external vendors
# relay:
# relay:
# relay:
# relay:
# relay:
---

Anyone who knows what is needed on my mailrelay for this to work ?

Thanks in advance :-) !
~maymann

Re: Postfix very slow accepting a mail having a massive recipient list

[Konrad Rzepecki]

W dniu 19.01.2012 08:15, Stan Hoeppner pisze:


To demonstrate that fsync alone shouldn't be a factor here,


But it is. I've straced sendmail to "fsync" waiting lot of time. It was 
80% or more of queue time.



Queuing 15K messages took 6 minutes 30 seconds on a single 7.2K drive,
again while competing with the delivery agent for spindle time.


My previous 1 drive 1 cpu box was also quick.


If your kernel is using CFQ you may want to try deadline.


No change. Also try disable NCQ, set noatime, switch to reiser also - 
no effect either. Only change I found on 8 disk boot raid1 (no lvm) 
which appear even more slower.



But that
alone isn't going to fix a 10x performance deficit.  You've probably got
multiple factors degrading performance.


Yes, you have right. But I found recently, that disk mounted on my 
server are slow 5.9K. My tests on in shows that they do fsync 1.5x-2x 
slower than 7.2K with quite often 5x-10x slower peak. Together with 
raid10, lvm, ext4, and much heavier load during delivery it may give 
effect I'm observing.


--
   Konrad Rzepecki

spamassassin setup for postfix 2.8 ?

[Frank Bonnet]

Hello

If someone could give some links to setup spammassassin
with postfix 2.8 ( FreeBSD ) ...  thank you

Re: Problem with SMTPs SSL_accept error | lost connection after CONNECT

[Fabrice MATHIEU]

Hello,

Le 19/01/2012 08:39, bsd a écrit :
> Le 19 janv. 2012 à 02:18, Wietse Venema a écrit :
>
>> bsd:
>>> I wanted to know what are the symptoms of "SSL_accept error" and
>>> "lost connection after CONNECT" ??
>> The client hangs up when Postfix expects the TLS handshake.
>>
>> There was two ways that Postfix provides TLS service. One is STARTTLS
>> mode (usually TCP port 587), and the other is TLS wrapper mode
>> (usually TCP port 465).
>>
>> Does the client connect to port 587 or to port 465? How do you know
>> that it connects to this port and not to the other one?
> ...
>
> From what I can read on netstat there is nothing listening on port 587. 
> Maybe the client tries to initiate a connexion on this port… but this will 
> surely fails ! 
>
>
> newmail ~ --> netstat -an -f inet | grep LISTEN
> ...
> tcp4   0  0 8x.9x.2x6.99.465   *.*LISTEN
> tcp4   0  0 8x.9x.2x6.99.25*.*LISTEN
> tcp4   0  0 *.993  *.*LISTEN
> tcp4   0  0 *.143  *.*LISTEN
> tcp4   0  0 *.110  *.*LISTEN
> ...
>
> Maybe I should use STARTTLS instead of the wrapper mode ? 
>
> What are the pros and cons of each solution ? 
I'am using STARTTLS and dovecot and it works great with Thunderbird, I
don't have made/test it with Apple Mail.
In this configuration client may be set to try or should starttls if
available.
So it first connect to standard smpt port (25 by default), present
themselves and then send startls command it the server capability list
contain it, like below.

#telnet 127.0.0.1 25
Trying 127.0.0.1 ...
...
220 server.com
EHLO toto.eu
...
250-STARTTLS
...
Client ask for opening SSL/TLS channel on the same port (there is a
technical name for this, I just don't remember what it is) before
sending any other smtp command.

In wrapper mode client is configured to connect directly on port 465 (by
default) is ssl mode, "like" https.
Then it talk with smtpd process.

STARTTLS was implemented after SSL port (wrapper mode).

Somebody will correct me if I was wrong.

I think this is a client misconfiguration (Certificate Authority or type
of port SSL/STARTTLS mode) or incompatibility.
Do you use your own certificate authority or your smtpd certificate is
signed by any kind of "official" CA.
_
_
> Can I provide both with the same auth backend mechanism (I use dovecot) ? 
>
Dovecot use a "socket" fie which is used by postfix process to check if
credential are valid or not.
As many mysql client on localhost can connect to the same server thought
the server socket, many postfix process could ask Dovecot.
So it should works.
Be careful about the socket file owner and permissions.