Hello There,

       Can anybody please suggest me on the below error while adding new
aliases to the root user. I am just trying to forward all emails of
the root user to my own account but #newaliases command result with
the below error. I am a newbie on postfix please suggest me.

Error:
======
[root@r1 ~]# newaliases
/etc/aliases: 77 aliases, longest 36 bytes, 805 bytes total

--
Manoj M. Burande,
Artificial Machines Pvt Ltd,
System Administrator.

Anybody knows how to set up server-side filtering using Sieve?
My server is running openSuse with postfix and cyrus-imap. I guess
both of them have to be somehow configured to use Sieve as a filter.
I need to move all messages marked as spam (by SpamAssasin) to user's
"Junk" folder.


--
ToMasz

HI ALL:

I try to understand how the initial_destination_concurrency and default_destination_concurrency_limit work? How can it support to improve the output of delivery. I do a small test.

I config the postfix like this:

qmgr_message_active_limit = 50

qmgr_message_recipient_limit = 50

initial_destination_concurrency = 10

default_destination_concurrency_limit = 10 default_destination_rate_delay = 10s

 

and then, I send 5 mail to one server, such as test@..., 5 mail for the other server, such as test@....

From the server side, I can see postfix send mail one by one. For instance, from A.com, I can see 5 mails, each is 10s delay the previous one. B.com is the same with A.

So I feel confuse about how can I use initial_destination_concurrency and default_destination_concurrency_limit parameters. Because if I change these 2 parameters to 1, the test result is the same.

 

Does anyone know my problem? How can I make postfix work like the manual described?

thank you all.

HI ALL:
I try to understand how the initial_destination_concurrency and
default_destination_concurrency_limit work? How can it support to improve
the output of delivery. I do a small test.
I config the postfix like this:
qmgr_message_active_limit = 50
qmgr_message_recipient_limit = 50
initial_destination_concurrency = 10
default_destination_concurrency_limit = 10
default_destination_rate_delay = 10s

and then, I send 5 mail to one server, such as test@..., 5 mail for the
other server, such as test@....
From the server side, I can see postfix send mail one by one. For instance,
from A.com, I can see 5 mails, each is 10s delay the previous one. B.com is
the same with A.
So I feel confuse about how can I use initial_destination_concurrency and
default_destination_concurrency_limit parameters. Because if I change these
2 parameters to 1, the test result is the same.

Does anyone know my problem? How can I make postfix work like the manual
described?

man pipe

suomi

On 2009-11-10 07:49, Arora, Sumit wrote:
> Hi folks,
>
> I'm using mysql local_recipient_maps for rejecting email for unknown
> local users.
>
> Here are the changes in my main.cf
>
> local_recipient_maps = proxy:unix:passwd.byname $alias_maps
> virtual_alias_maps = mysql:/etc/postfix/mysql-relays.cf
>
> Here is my mysql-relays.cf
>
> hosts=16.123.123.123
>
> user=root
>
> password=*****
>
> dbname=testDB
>
> table=users
>
> query = select emailaddress from users where emailaddress='%s'
>
> I'm able to query successfully.
>
> But I'm stuck as my requirement is to query database according to sender.
>
> Let's say some user with emailaddress 'sender@...' is sending
> email to my postfix and I need to validate him.
>
> query = select emailaddress from users where emailaddress='%s' &&
> allowedusers='sender@...'
>
> Can anybody suggest me how can I get the sender email address in
> mysql-relays.cf on runtime.
>
> Thanks,
>
> Sumit Arora
>

Hi,

On Tue, 10 Nov 2009 09:03:56 +0200, Jack Knowlton <jknowlton@...>
wrote:
> Is it possible to have a transport map with a regular expression? What I
> want is to use an external relay server for all the emails to be
> delivered
> on Yahoo domains (eg, yahoo.com, yahoo.co.uk, yahoo.es, ecc).
> If it is possible, how can I implement this?

I'm not an expert, but I believe this is possible by specifying your
transport file as "transport_maps=regexp:/etc/postfix/transport".  You may
also use PCRE instead of regexp if you prefer.  The only downside is that
the entire file needs to be set up in the regex/pcre fashion (as far as
I'm aware anyway).

ie:

/yahoo.[a-z]*/             relay:[127.0.0.2]
/test.com/                 relay:[127.0.0.3]

[postfix]$ postmap -q "yahoo.com" regexp:/etc/postfix/transport
smtp:[127.0.0.2]

Hope this helps you,
Cheers,
Marc

Hi all.
Is it possible to have a transport map with a regular expression? What I
want is to use an external relay server for all the emails to be delivered
on Yahoo domains (eg, yahoo.com, yahoo.co.uk, yahoo.es, ecc).
If it is possible, how can I implement this?
Thanks.

-JK

Cameron Smith wrote:
> We have a private network on our lan and a public network on our lan.
>
> We want to put a mail gateway running postfix in the public network and
> have it be the point of entry and egress for the other mail servers also
> running postfix on both our public and private networks.
>
> I can see here how to configure this:
> http://www.postfix.org/STANDARD_CONFIGURATION_README.html#local_network
>
> but I have a few questions.
>
> Are there any pointers or things I should watch out for when setting up
> this type of relationship?

Use sasl with tls or ssl.

see:

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

--
Eero

Micah Anderson:
> I would like to reduce the mysql transport retry time (or perhaps the
> proxymap retry time?), is there a variable that I can tweak down to
> reduce the time between retries of mysql transport connection losses?

Connections to database servers should not be lost routinely.

> Oct 27 13:24:37 mx1 postfix/proxymap[14768]: warning: mysql query failed: Lost
connection to MySQL server during query
> Oct 27 13:24:37 mx1 postfix/trivial-rewrite[11124]: fatal:
proxy:mysql:/etc/postfix/maps/mysql_aliases.cf(0,lock|fold_fix): table lookup
problem

If anything should retry the query, then it would be the mysql
client.  The proxymap can't make such decisions (for example, it
makes no sense to retry after a read error from a local file).

And in fact, the mysql client does implement retry logic. It retries
if you have more than one mysql server configured. Perhaps you
can specify the same server multiple times.

	 Wietse

I would like to reduce the mysql transport retry time (or perhaps the
proxymap retry time?), is there a variable that I can tweak down to
reduce the time between retries of mysql transport connection losses?

I'm using mysql for transport_maps and virtual_mailbox_maps.

transport_maps = proxy:mysql:$maps_dir/mysql_transport.cf
virtual_mailbox_maps = mysql:$maps_dir/mysql_aliases.cf

these are configured to contact a locat stunnel process which connects
to a mysql cluster over an encrypted connection. This works great,
except when the active node of the cluster crashes (and it seems to be
doing that more frequently lately). The cluster fails-over to the
standby, the connections are re-established and things return to
normal.

When the node fails, postfix naturally cannot communicate over the mysql
connection, until the cluster has failed over. This failover is fairly
fast, within seconds, but I think postfix, probably due to the use of
the proxy map, is not retrying very quickly. Is there a tunable
parameter that I can use to tweak this down to a shorter delay?

The erorrs that arrive are expected in this scenario, for example, here
is a subset:

Oct 27 13:24:23 mx1 postfix/smtpd[11045]: warning:
mysql:/etc/postfix/checks/mysql_suspended.cf: table lookup problem
Oct 27 13:24:37 mx1 postfix/proxymap[14768]: warning: mysql query failed: Lost
connection to MySQL server during query
Oct 27 13:24:37 mx1 postfix/trivial-rewrite[11124]: fatal:
proxy:mysql:/etc/postfix/maps/mysql_aliases.cf(0,lock|fold_fix): table lookup
problem
Oct 27 13:24:38 mx1 postfix/master[7511]: warning: process
/usr/lib/postfix/trivial-rewrite pid 11124 exit status 1
Oct 27 13:24:38 mx1 postfix/smtpd[12834]: warning: problem talking to service
rewrite: Connection reset by peer
Oct 28 09:01:57 mx1 postfix/smtpd[4945]: warning: problem talking to service
rewrite: Success
Oct 28 09:01:57 mx1 postfix/smtpd[4948]: warning: problem talking to service
rewrite: Connection reset by peer

Postmaster also gets quite a large number of bounces when this happens:

  In:  MAIL FROM:<xxx@...> SIZE=2158 BODY=8BITMIME
  Out: 250 2.1.0 Ok
  In:  RCPT TO:<xxx@...> ORCPT=rfc822;xxx@...
  Out: 451 4.3.0 <xxx@...>: Temporary lookup failure
  In:  DATA
  Out: 554 5.5.1 Error: no valid recipients
  In:  RSET
  Out: 250 2.0.0 Ok
  In:  QUIT
  Out: 221 2.0.0 Bye

Presumably these are non-fatal, due to the 451, and only postmaster sees
these, not the sender, and they are just retried, is that correct?

Thanks for any advice, I haven't found anything that specifically would
be related to this in
http://www.postfix.org/postconf.5.html#command_time_limit but I might
have missed something.

micah

On 9-Nov-2009, at 06:25, Arora, Sumit wrote:
> Hi folks,

Do not hijack other threads if you want help. Create a NEW message,
not a reply to other messages.

Also, read http://www.postfix.org/DEBUG_README.html#mail before posting.


--
I WILL NOT FAKE MY WAY THROUGH LIFE
	 Bart chalkboard Ep. 7F03

On Mon, Nov 09, 2009 at 06:42:53PM +0100, Henri wrote:

> I have also encountered the same situation : multiple results with one LDAP
> query. I first think about the expansion_limit parameter, but it still gives
> a lookup transport error.
> I have no possibility in adding a parameter to ensure that the LDAP query
> will only return one result.
>
> My ldap directory is quite large and we have several tools to ensure that
> there won't be any entries having the same address email.
> However it could still happens and I would really appreciate if you could
> give us the "solution" to fix that.
>
> >It is "possible" to work-around the inevitable multiple result values, but
> >I am loath to recommend it, so would prefer to not post such a "solution".

The best solution is to enforce primary key collisions when entries are
added to LDAP.

--
	 Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:majordomo@...?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

On Sun, Nov 08, 2009 at 04:30:30PM -0500, Mike Gering wrote:

> I've built my webserver on Amazon EC2 which, even with static IP addresses,
> does not handle reverse DNS lookup, causing (relatively few) recipient
> servers reject the mail. We've contracted with a mail relay service, but
> they are more expensive than the EC2 service itself! Since we're a
> municipal government, we need to reduce expenses as much as possible. The
> only solution I can think of is to have postfix attempt to deliver outgoing
> mail directly, and then for failures due to connection refusals, deliver
> them via the relay.

Sorry EC2 is a compute-farm not an email hosting service. IIRC, Amazon
have contributed the EC2 address space to the SpamHaus PBL, as they take
no responsibility for any email sent from that address space, spammers
can hire as many CPUs as they want, and try to send mail from EC2 if they
want.

Since most of the world uses zen.spamhaus.org, naturally neither you
nor the spammers will have much luck with sending email directly from
EC2.

It is hard to see how you save money on EC2 vs renting a dedicated Colo
node. EC2 is about scalability for variable loads, and the ability to rent
lots of CPU for a short-term compute project. If you need modest CPU +
bandwidth on an ongoing basis, you should be able to find something
reasonably competitive with EC2.

Instead of buying SMTP relay service. Rent a box, and deploy a relay
on it. Choose a reputable hosting provider, that does not tolerate
spammers, you don't want to be collateral damage when the hosting
provider's entire network is blocked.

--
	 Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:majordomo@...?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

On Sun, Nov 08, 2009 at 08:16:27PM +0300, devel anaconda wrote:

> I think, that things will go faster, if postfix, instead of saving new
> messages to queue, will try to deliver it to deliver agent "in memory",
> and only if that fails, save the message to queue. Don't you think, this
> will be faster? Is that possible? I can make a patch (not for upstream,
> only for me).

If you are "patching" Postfix to this extent, Postfix is not the MTA
for you. Consider starting with some other MTA that is designed for your
use-case first and security/reliability second (third, ... or not at all).

--
	 Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:majordomo@...?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

hmm, on Mon, Nov 09, 2009 at 10:22:59AM -0500, Brian Evans - Postfix List said
that
> frantisek holop wrote:
> > thanks for the cluestick.  i moved that particular check into
> > smtpd_client_restrictions as whitelisting these clients is "absolute",
> > not just because they can't handle their own HELO.
> >
> > -f
> >
> No.
> Leave it in smtpd_helo_restrictions or the offending checks will still fail.
> Whitelisting is only valid per class.  Moving it to client_restrictions
> will give the same problem.
> You want to change *what* you are checking, not *where*.

ok, i wasn't aware of the "valid per class" part.
it makes sense of course :]

-f
--
bigamy: too many wives. monogamy: see bigamy.

frantisek holop wrote:
> hmm, on Mon, Nov 09, 2009 at 09:49:16AM -0500, Brian Evans - Postfix List said
that
>
>> frantisek holop wrote:
>>
>>> main.cf:
>>>
>>>
>>> smtpd_helo_restrictions =
>>>         permit_mynetworks
>>>         check_helo_access hash:/etc/postfix/client_checks
>>>         reject_unlisted_recipient
>>>         reject_invalid_helo_hostname
>>>         reject_non_fqdn_helo_hostname
>>>         reject_unknown_helo_hostname
>>>
>>> client_checks:
>>>
>>> # mailserver-with-invalid-helo.com
>>> aaa.bbb.ccc.ddd OK
>>>
>>>
>>>
>> Change check_helo_access to check_client_access.
>> helo access verifies what is passed with the HELO command (e.g. HELO
>> myserver)
>> client access verifies the IP of the connecting server
>>
>> You can include client checks in helo_restrictions per
>> http://www.postfix.org/postconf.5.html#smtpd_helo_restrictions
>>
>
> thanks for the cluestick.  i moved that particular check into
> smtpd_client_restrictions as whitelisting these clients is "absolute",
> not just because they can't handle their own HELO.
>
> -f
>
No.
Leave it in smtpd_helo_restrictions or the offending checks will still fail.
Whitelisting is only valid per class.  Moving it to client_restrictions
will give the same problem.
You want to change *what* you are checking, not *where*.

hmm, on Mon, Nov 09, 2009 at 09:49:16AM -0500, Brian Evans - Postfix List said
that
> frantisek holop wrote:
> > main.cf:
> >
> >
> > smtpd_helo_restrictions =
> >         permit_mynetworks
> >         check_helo_access hash:/etc/postfix/client_checks
> >         reject_unlisted_recipient
> >         reject_invalid_helo_hostname
> >         reject_non_fqdn_helo_hostname
> >         reject_unknown_helo_hostname
> >
> > client_checks:
> >
> > # mailserver-with-invalid-helo.com
> > aaa.bbb.ccc.ddd OK
> >
> >
> Change check_helo_access to check_client_access.
> helo access verifies what is passed with the HELO command (e.g. HELO
> myserver)
> client access verifies the IP of the connecting server
>
> You can include client checks in helo_restrictions per
> http://www.postfix.org/postconf.5.html#smtpd_helo_restrictions

thanks for the cluestick.  i moved that particular check into
smtpd_client_restrictions as whitelisting these clients is "absolute",
not just because they can't handle their own HELO.

-f
--
you will become rich and famous unless you don't.

frantisek holop wrote:
> main.cf:
>
>
> smtpd_helo_restrictions =
>         permit_mynetworks
>         check_helo_access hash:/etc/postfix/client_checks
>         reject_unlisted_recipient
>         reject_invalid_helo_hostname
>         reject_non_fqdn_helo_hostname
>         reject_unknown_helo_hostname
>
> client_checks:
>
> # mailserver-with-invalid-helo.com
> aaa.bbb.ccc.ddd OK
>
>
Change check_helo_access to check_client_access.
helo access verifies what is passed with the HELO command (e.g. HELO
myserver)
client access verifies the IP of the connecting server

You can include client checks in helo_restrictions per
http://www.postfix.org/postconf.5.html#smtpd_helo_restrictions

thank's a lot, i try it as soon as possible

Brian Evans - Postfix List wrote:
> Matteo Cazzador wrote:
>
>> Hello, i've a question about postfix and hylafax email to fax,
>> excuse for my english,
>> I need to configure postfix to accept mail from internet (non only intranet)
>> to convert mail to fax, but i'don't want that  every mail like spam
>> to be converted in fax, so is it possibile to refuse mail sent to
>> @faxmydomain.it
>> that are not autenticated? i can create user account to send mail to my
>> domain.
>> There is a directive to refuse received mail non sasl authenticated like
>> smtp sasl autentication?
>> Every how to say: don't configure domain faxmydomain.it in dns but if i
>> want to convert mail from internet
>>
> If you want to do this for all domains you receive in Postfix:
> smtpd_recipient_restrictions = permit_mynetworks,
> permit_sasl_authenticated, reject
>
> If you just want just a list of domains to follow this:
> Add "check_recipient_access hash:/path/to/faxdomain_auth" after
> reject_unauth_destination in smtpd_recipient_restrictions (if you do not
> have one, run "postconf smtpd_recipient_restrictions")
>
> /path/to/faxdomain_auth:
>
> fax.example.com  permit_sasl_authenticated, reject
>
>

--
******************************************
Ing. Matteo Cazzador
NetLite snc di Cazzador Gagliardi
Corso Vittorio Emanuele II, 188 37069
Villafranca di Verona VR
Tel - Fax 0456300464
Email: matteo@...
Web: http://www.netlite.it
******************************************

Matteo Cazzador wrote:
> Hello, i've a question about postfix and hylafax email to fax,
> excuse for my english,
> I need to configure postfix to accept mail from internet (non only intranet)
> to convert mail to fax, but i'don't want that  every mail like spam
> to be converted in fax, so is it possibile to refuse mail sent to
> @faxmydomain.it
> that are not autenticated? i can create user account to send mail to my
> domain.
> There is a directive to refuse received mail non sasl authenticated like
> smtp sasl autentication?
> Every how to say: don't configure domain faxmydomain.it in dns but if i
> want to convert mail from internet
If you want to do this for all domains you receive in Postfix:
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated, reject

If you just want just a list of domains to follow this:
Add "check_recipient_access hash:/path/to/faxdomain_auth" after
reject_unauth_destination in smtpd_recipient_restrictions (if you do not
have one, run "postconf smtpd_recipient_restrictions")

/path/to/faxdomain_auth:

fax.example.com  permit_sasl_authenticated, reject

hi there,

i am having difficulties with smtpd_helo_restrictions because
of check_helo_access.

all the entries in my client_checks file seem to be ignored..
i tried debug_peer with the most recent entry in there:

mail.log:

Nov  9 14:49:13 ns postfix/smtpd[11842]: >>> START Helo command RESTRICTIONS <<<
Nov  9 14:49:13 ns postfix/smtpd[11842]: generic_checks: name=permit_mynetworks
...
Nov  9 14:49:13 ns postfix/smtpd[11842]: generic_checks: name=permit_mynetworks
status=0
Nov  9 14:49:13 ns postfix/smtpd[11842]: generic_checks: name=check_helo_access
Nov  9 14:49:13 ns postfix/smtpd[11842]: check_domain_access:
mailserver-with-invalid-helo.com
Nov  9 14:49:13 ns postfix/smtpd[11842]: generic_checks: name=check_helo_access
status=0

the IP of "mailserver-with-invalid-helo.com" is in client_checks.
however it is still being rejected because check_helo_access fails
to let it through.  this setup seemed to work before without problems.


main.cf:

smtpd_client_restrictions =
         check_client_access hash:/etc/postfix/access

smtpd_helo_restrictions =
         permit_mynetworks
         check_helo_access hash:/etc/postfix/client_checks
         reject_unlisted_recipient
         reject_invalid_helo_hostname
         reject_non_fqdn_helo_hostname
         reject_unknown_helo_hostname

smtpd_sender_restrictions =
         reject_non_fqdn_sender
         reject_unknown_sender_domain
         reject_unlisted_sender

smtpd_recipient_restrictions =
         permit_mynetworks
         reject_non_fqdn_recipient
         reject_unauth_destination
         reject_unknown_recipient_domain

smtpd_data_restrictions = reject_unauth_pipelining


client_checks:

# mailserver-with-invalid-helo.com
aaa.bbb.ccc.ddd OK


postconf -n (please note that reject_*_helo_hostname have
been removed already, so mail doesn't get blocked):

alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases
biff = no
config_directory = /etc/postfix
disable_vrfy_command = yes
duplicate_filter_limit = 2000
header_checks = regexp:/etc/postfix/header_checks
mailbox_command = /usr/bin/procmail -a "$USER"
mailbox_size_limit = 0
masquerade_domains = $mydomain
message_size_limit = 51200000
mydestination = /etc/postfix/local-host-names
mynetworks = 192.168.0.0/16 195.168.92.0/24  127.0.0.1
myorigin = $mydomain
notify_classes = resource, software
recipient_bcc_maps = hash:/etc/postfix/recipient_bcc
relay_domains = /etc/postfix/relay-domains
smtp_helo_name = mail.$mydomain
smtpd_banner = mail.$mydomain ESMTP
smtpd_client_restrictions = check_client_access hash:/etc/postfix/access
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks check_helo_access
hash:/etc/postfix/client_checks reject_unlisted_recipient
smtpd_recipient_limit = 2000
smtpd_recipient_restrictions = permit_mynetworks reject_non_fqdn_recipient
reject_unauth_destination reject_unknown_recipient_domain
smtpd_sender_restrictions = reject_non_fqdn_sender reject_unknown_sender_domain
reject_unlisted_sender
unknown_local_recipient_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/virtual

-f
--
doubt is the beginning of wisdom

Hello, i've a question about postfix and hylafax email to fax,
excuse for my english,
I need to configure postfix to accept mail from internet (non only intranet)
to convert mail to fax, but i'don't want that  every mail like spam
to be converted in fax, so is it possibile to refuse mail sent to
@faxmydomain.it
that are not autenticated? i can create user account to send mail to my
domain.
There is a directive to refuse received mail non sasl authenticated like
smtp sasl autentication?
Every how to say: don't configure domain faxmydomain.it in dns but if i
want to convert mail from internet?
Thank's a lot


--
******************************************
Ing. Matteo Cazzador
NetLite snc di Cazzador Gagliardi
Corso Vittorio Emanuele II, 188 37069
Villafranca di Verona VR
Tel - Fax 0456300464
Email: matteo@...
Web: http://www.netlite.it
******************************************

Andrzej Kukuła:
> On Mon, Nov 9, 2009 at 02:29, Wietse Venema <wietse@...> wrote:
> > Last week there was big news about a security hole in the TLS
> > protocol that allows a man-in-the-middle to prepend data to a
> > fully-secure TLS session.
>
> Thank you both gentlemen for your hard work on this. I've got possibly
> lame question. I assume STARTTLS is affected, but is also 'wrapper
> mode' vulnerable to this attack? I mean the mode in which client and
> server immediately estabilish encrypted channel, before issuing any
> SMTP command.

It was left as an exercise for the reader.

- At the top of the attack diagram, delete the plaintext phase (the
   "SMTP 220 welcome", "SMTP hello" and "SMTP starttls" command and
   reply boxes).

- Insert "SMTP 220 welcome" as the first server response after the
   renegotiation TLS handshake.

This attack works when the server's TLS engine renegotiates the
session before it encrypts the server's "SMTP 220 welcome".

In the Postfix SMTP server, wrappermode would not be affected for
the same reason that Postfix SMTP server STARTTLS is not affected.
Also, the same SMTP client defenses apply for detecting server
replies that are sent too soon.

	 Wietse

Hi folks,

I'm using mysql local_recipient_maps for rejecting email for unknown local
users.

Here are the changes in my main.cf

local_recipient_maps = proxy:unix:passwd.byname $alias_maps
virtual_alias_maps = mysql:/etc/postfix/mysql-relays.cf

Here is my mysql-relays.cf

hosts=16.123.123.123
user=root
password=*****
dbname=testDB
table=users
query = select emailaddress from users where emailaddress='%s'

I'm able to query successfully.

But I'm stuck as my requirement is to query database according to sender.
Let's say some user with emailaddress 'sender@...' is sending email
to my postfix and I need to validate him.

query = select emailaddress from users where emailaddress='%s' &&
allowedusers='sender@...'

Can anybody suggest me how can I get the sender email address in mysql-relays.cf
on runtime.

Thanks,
Sumit Arora

On Mon, Nov 9, 2009 at 02:29, Wietse Venema <wietse@...> wrote:
> Last week there was big news about a security hole in the TLS
> protocol that allows a man-in-the-middle to prepend data to a
> fully-secure TLS session.

Thank you both gentlemen for your hard work on this. I've got possibly
lame question. I assume STARTTLS is affected, but is also 'wrapper
mode' vulnerable to this attack? I mean the mode in which client and
server immediately estabilish encrypted channel, before issuing any
SMTP command.

Thanks,
Andrzej Kukula

Last week there was big news about a security hole in the TLS
protocol that allows a man-in-the-middle to prepend data to a
fully-secure TLS session.

That is, the server certificate verifies, and therefore no-one can
read or modify the network traffic. Or so we thought.

http://www.ietf.org/mail-archive/web/tls/current/msg03928.html
http://www.ietf.org/mail-archive/web/tls/current/msg03942.html

This hole was already known and a consortium of industry partners
was already working on solutions.  Meanwhile, a draft proposal has
been published for a TLS protocol change.

While looking at the possible impact for SMTP mail, I came up with
an attack that redirects and modifies SMTP mail that is sent over
a fully-secure TLS connection; Victor came up with an attack that
changes the first command in a TLS session.

You can find a preliminary analysis at:

     http://www.porcupine.org/postfix-mirror/smtp-renegotiate.pdf

It comes with a little tutorial on SMTP over TLS, and on TLS
renegotiation attacks.

The impact of all this should not be over-stated. Presently, most
SMTP clients don't verify the TLS certificates of SMTP servers.
Such clients are already vulnerable to ordinary man-in-the-middle
attacks, and TLS renegotiation introduces no new threats for them.

The Postfix SMTP server with OpenSSL is not affected by the TLS
renegotiation attack that redirects and modifies SMTP mail, due to
accidental details of the Postfix and OpenSSL implementations.
Other SMTP server implementations may be affected (my report
describes some of the requirements).  There may of course be other
attacks that I wasn't aware of when I wrote the analysis.

Most SMTP client implementations will not detect that a TLS
renegotiation attack has happened, including the Postfix SMTP
client.  Victor and I have looked into a number of workarounds
that can be implemented in the SMTP client, pending a bugfix in
the TLS protocol and in TLS implementations.  Some of these
workarounds may end up in Postfix.

	 Wietse