Re: Best Suggestion For Blacklisting Senders

[Ansgar Wiechers]

On 2010-01-22 Carlos Williams wrote:
> On Thu, Jan 21, 2010 at 2:43 PM, Brian Evans - Postfix List wrote:
>> This is a client IP not a sender, e. g. 'MAIL FROM: br...@example.com'
>>
>> The IP should go into a file referenced by a check_client_access
>> restriction.
> 
> I think I still don't have a understanding at how to properly read /
> understand message headers in order to create good filters in Postfix.
> I am very sorry for my confusion but can someone please tell me what
> the difference is between these two IP's I show in the headers. I am
> guessing one IP is the actual 'senders' IP address in which is
> initiating SMTP from using a client like Outlook / Thunderbird and the
> other IP I am guessing is the address of the senders SMTP server which
> establishes a connection with my Postfix MTA, right? Do I at least
> have this correct?
[...]
> Received: from civismtp.uas.coop (civismtp.uas.coop [67.212.170.242])
> by mail.iamghost.com (Postfix) with ESMTP id C00DB77A862 for
> ; Fri, 22 Jan 2010 05:29:30 -0500 (EST)
> Received: from wfmc.org (HELO www.wfmc.org) (192.220.23.216)
> (smtp-auth username editor, mechanism cram-md5) by civismtp.uas.coop
> (qpsmtpd/0.40) with ESMTPA; Fri, 22 Jan 2010 03:50:52 -0600
[...]
> There are two (2) 'Received: from' lines which both have two
> completely different IP's. One has a HELO & 'smtp-auth' username
> (editor) which I assume this line to be the client sending the
> message, not the MTA, is this correct?

No. E-Mail has a so-called store-and-forward architecture, meaning that
a mail may pass through several hops, each of which accepts and forwards
the mail to the next hop.

User-Client -> MTA -> MTA -> MTA -> MTA -> Recipient mailbox
A  B  C  D

In every connection (->) the sending hop is the client, and the
receiving hop is the server.

Of course a user's mail client (or rather Mail User Agent, MUA) is also
a client. It depends on the context who is the client in any given
situation.

HTH

Regards
Ansgar Wiechers
-- 
"Abstractions save us time working, but they don't save us time learning."
--Joel Spolsky

smtp auth over ssl for smartrelay configuration

[Jelle de Jong]

Hello everybody,

I got a hole set >20 of Debian systems connected to mobile broadband
internet. They are behind a NAT of with dynamic ip's.

I want these systems to be able to sent emails to my server for all
kind of reasons like monitoring, security updates etcetera.

I want to use postfix to authorise to my secured SMTP server to be
able to deliver mail. The authorisation should be like the one's used
on my MTA's like Mozilla Thunderbird with SMTP authorisation.

Configuration option I made up:

authuser=usern...@powercraft.nl
authpass=password
authmethod=plain
mailhub=secure.powercraft.nl:465
usessl=true

Can somebody show me an example how to setup up a simple outgoing only
email configuration that uses SMTP AUTH over SSL?

Thanks in advance,

Kind regards,

Jelle

Re: smtp auth over ssl for smartrelay configuration

[Wietse Venema]

Jelle de Jong:
> Hello everybody,
> 
> I got a hole set >20 of Debian systems connected to mobile broadband
> internet. They are behind a NAT of with dynamic ip's.
> 
> I want these systems to be able to sent emails to my server for all
> kind of reasons like monitoring, security updates etcetera.
> 
> I want to use postfix to authorise to my secured SMTP server to be
> able to deliver mail. The authorisation should be like the one's used
> on my MTA's like Mozilla Thunderbird with SMTP authorisation.
> 
> Configuration option I made up:
> 
> authuser=usern...@powercraft.nl
> authpass=password
> authmethod=plain
> mailhub=secure.powercraft.nl:465
> usessl=true
> 
> Can somebody show me an example how to setup up a simple outgoing only
> email configuration that uses SMTP AUTH over SSL?

Postfix SASL: http://www.postfix.org/SASL_README.html

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

These are organized in client and server sections, with examples.
There is no need to repeat this information on the mailing list.

Wietse

Best way to put spam on hold queue?

[Jozsef Kadlecsik]

Hello,

We plan to add the possibility for our users to choose that messages 
categorized as spam are put on the hold queue instead of the default 
reject. Thus it'll be possible to release the false positives, which 
can make life easier for them.

Currently I can see two ways to accomplish it, both have got pros and 
cons.

a. Single postfix instance with large enough queue partition. Easier,
   simpler, however if the queue partition becomes full, the normal 
   traffic is blocked as well.

b. Two postfix instances, the first one sends the messages to be held
   to the second one via a selected transport. (Two policy daemons are
   required as well.) The first instance handles all the good traffic 
   and diverts the bad one to the second instance, which has the single
   job to put messages onto its hold queue and release from there. 
   That way the hold queue can be separated and moved to a second 
   partition. Still, if the second instance stops working for whatever
   reason, the messages to be held will stuck at the first instance.

How could one achieve that the held messages are separated from the normal 
traffic (i.e. hold queue on another partition), but if the messages cannot 
be held, then those gets rejected instead of queued?

Best regards,
Jozsef
-
E-mail  : kad...@blackhole.kfki.hu, kad...@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
  H-1525 Budapest 114, POB. 49, Hungary

Re: Best way to put spam on hold queue?

[Wietse Venema]

Jozsef Kadlecsik:
> Hello,
> 
> We plan to add the possibility for our users to choose that messages 
> categorized as spam are put on the hold queue instead of the default 
> reject. Thus it'll be possible to release the false positives, which 
> can make life easier for them.
> 
> Currently I can see two ways to accomplish it, both have got pros and 
> cons.
> 
> a. Single postfix instance with large enough queue partition. Easier,
>simpler, however if the queue partition becomes full, the normal 
>traffic is blocked as well.
> 
> b. Two postfix instances, the first one sends the messages to be held
>to the second one via a selected transport. (Two policy daemons are
>required as well.) The first instance handles all the good traffic 
>and diverts the bad one to the second instance, which has the single
>job to put messages onto its hold queue and release from there. 
>That way the hold queue can be separated and moved to a second 
>partition. Still, if the second instance stops working for whatever
>reason, the messages to be held will stuck at the first instance.
> 
> How could one achieve that the held messages are separated from the normal 
> traffic (i.e. hold queue on another partition), but if the messages cannot 
> be held, then those gets rejected instead of queued?

Given Postfix's architecture, a loosely-coupled pipeline without
global feedback, there is no obvious way to build global feedback
into Postfix itself.

I suggest that you run an email monitoring system. When the secondary
system stops accepting mail for more than some minimum amount of
time (allowing enough time for the system to reboot), update the
configuration on the primary system.

Wietse

Recipient address rejected: Access denied while SASL/TLS enabled

[David Touzeau]

Dear 

I don't understand why but i think that Postfix did want to send the
authentication request in the SMTP protocol.
In this case , the client (thunderbird) cannot send authentication
parameters trough Internet.
When executing saslfinger, there is not information in the -- mechanisms
on localhost -- i think that perhaps this is the problem.

How can i resolv it

Many thanks

Output debug log

Jan 23 15:09:23 mx1 postfix/smtpd[25192]: >>> START Sender address
RESTRICTIONS <<<
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: generic_checks:
name=permit_sasl_authenticated
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: generic_checks:
name=permit_sasl_authenticated status=0
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: generic_checks:
name=permit_mynetworks
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: permit_mynetworks:
129.168.201-77.rev.gaoland.net 77.201.168.129
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_hostname:
129.168.201-77.rev.gaoland.net ~? 127.0.0.0/8
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_hostaddr: 77.201.168.129
~? 127.0.0.0/8
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_hostname:
129.168.201-77.rev.gaoland.net ~? [:::127.0.0.0]/104
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_hostaddr: 77.201.168.129
~? [:::127.0.0.0]/104
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_hostname:
129.168.201-77.rev.gaoland.net ~? [::1]/128
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_hostaddr: 77.201.168.129
~? [::1]/128
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_hostname:
129.168.201-77.rev.gaoland.net ~? 91.121.48.19
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_hostaddr: 77.201.168.129
~? 91.121.48.19
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_list_match:
129.168.201-77.rev.gaoland.net: no match
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_list_match:
77.201.168.129: no match
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: generic_checks:
name=permit_mynetworks status=0
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: >>> END Sender address
RESTRICTIONS <<<
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: >>> START Recipient address
RESTRICTIONS <<<
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: generic_checks:
name=permit_sasl_authenticated
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: generic_checks:
name=permit_sasl_authenticated status=0
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: generic_checks:
name=permit_mynetworks
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: permit_mynetworks:
129.168.201-77.rev.gaoland.net 77.201.168.129
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_hostname:
129.168.201-77.rev.gaoland.net ~? 127.0.0.0/8
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_hostaddr: 77.201.168.129
~? 127.0.0.0/8
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_hostname:
129.168.201-77.rev.gaoland.net ~? [:::127.0.0.0]/104
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_hostaddr: 77.201.168.129
~? [:::127.0.0.0]/104
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_hostname:
129.168.201-77.rev.gaoland.net ~? [::1]/128
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_hostaddr: 77.201.168.129
~? [::1]/128
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_hostname:
129.168.201-77.rev.gaoland.net ~? 91.121.48.19
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_hostaddr: 77.201.168.129
~? 91.121.48.19
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_list_match:
129.168.201-77.rev.gaoland.net: no match
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_list_match:
77.201.168.129: no match
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: generic_checks:
name=permit_mynetworks status=0
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: generic_checks: name=reject
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: NOQUEUE: reject: RCPT from
129.168.201-77.rev.gaoland.net[77.201.168.129]: 554 5.7.1
: Recipient address rejected: Access denied;
from= to= proto=ESMTP
helo=<[192.168.1.20]>
Jan 23 15:09:23 mx1 postfix/smtpd[25192]: generic_checks: name=reject
status=2


Output of saslfinger, you can see there is no -- mechanisms on localhost
--

saslfinger - postfix Cyrus sasl configuration samedi 23 janvier 2010,
15:04:40 (UTC+0100)
version: 1.0.4
mode: server-side SMTP AUTH

-- basics --
Postfix: 2.5.5
System: Debian GNU/Linux 5.0 \n \l

-- smtpd is linked to --
libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0xb7d7c000)

-- active SMTP AUTH and TLS parameters for smtpd --
broken_sasl_auth_clients = yes
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_path = smtpd
smtpd_sasl_security_options = noanonymous
smtpd_tls_CAfile = /etc/ssl/certs/postfix/ca.csr
smtpd_tls_ask_ccert = no
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/ssl/certs/postfix/ca.crt
smtpd_tls_key_file = /etc/ssl/certs/postfix/ca.key
smtpd_tls_received_header = yes
smtpd_tls_req_ccert = no
smtpd_tls_security_level = none
smtpd_tls_session_cache_database = btree:$data_directory/smtpd_tls_cache
smtpd_use_tls = yes


-- content of /usr/lib/sasl2/smtpd.conf --
pwcheck_method: saslauthd
mech_list: plain login 
log_l

Re: Best way to put spam on hold queue?

[Jozsef Kadlecsik]

On Sat, 23 Jan 2010, Wietse Venema wrote:

> Jozsef Kadlecsik:
> > 
> > How could one achieve that the held messages are separated from the normal 
> > traffic (i.e. hold queue on another partition), but if the messages cannot 
> > be held, then those gets rejected instead of queued?
> 
> Given Postfix's architecture, a loosely-coupled pipeline without
> global feedback, there is no obvious way to build global feedback
> into Postfix itself.
> 
> I suggest that you run an email monitoring system. When the secondary
> system stops accepting mail for more than some minimum amount of
> time (allowing enough time for the system to reboot), update the
> configuration on the primary system.

Yes, monitoring is inevitable. And that imply you would prefer the two 
instances setup :-).

Just as a theoretical question, would it fit somehow into Postfix to 
support the hold queue *alone* in a separated partition? The flow would 
look like

- normal smtpd processing of incoming request
- if the action is HOLD and hold queue on a separate partition by 
  config, ask cleanup to forget about the queue entry in incoming and 
  request a new one in the hold queue
- if message cannot be queued successfully, report it to the client

Of course it might mean too much violation of the Postfix internals.

Best regards,
Jozsef
-
E-mail  : kad...@blackhole.kfki.hu, kad...@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
  H-1525 Budapest 114, POB. 49, Hungary

Re: Timeout of SMTP servers

[Sahil Tandon]

On Fri, 22 Jan 2010, Martijn de Munnik wrote:

> RFC2821 section 4.5.3.2 Timeouts reads
> 
> "An SMTP server SHOULD have a timeout of at least 5 minutes while it
> is awaiting the next command from the sender."

The key word is SHOULD, as opposed to MUST.

> When I try to connect to an one.com mx (mx-cluster1.one.com or
> mx-cluster2.one.com) I notice they will close the connection after about 3
> seconds. Why do they do this? Is anybody else using such short timeouts?

That timeout does seem foolishly short, but they might have legitimate
reasons that are best explained by ... them!  Try pinging their
postmaster.

-- 
Sahil Tandon 

Re: Timeout of SMTP servers

[Martijn de Munnik]

On Jan 23, 2010, at 4:24 PM, Sahil Tandon wrote:

> On Fri, 22 Jan 2010, Martijn de Munnik wrote:
> 
>> RFC2821 section 4.5.3.2 Timeouts reads
>> 
>> "An SMTP server SHOULD have a timeout of at least 5 minutes while it
>> is awaiting the next command from the sender."
> 
> The key word is SHOULD, as opposed to MUST.

"SHOULD" equals "MUST unless you have a really good reason". I'm trying to 
figure out if somebody on the list knows a really good reason.
> 
>> When I try to connect to an one.com mx (mx-cluster1.one.com or
>> mx-cluster2.one.com) I notice they will close the connection after about 3
>> seconds. Why do they do this? Is anybody else using such short timeouts?
> 
> That timeout does seem foolishly short, but they might have legitimate
> reasons that are best explained by ... them!  Try pinging their
> postmaster.
> 
> -- 
> Sahil Tandon 
> 

Re: smtp auth over ssl for smartrelay configuration

[Jelle de Jong]

Wietse Venema wrote, on 23-01-10 14:41:
> Jelle de Jong:
>> Can somebody show me an example how to setup up a simple outgoing only
>> email configuration that uses SMTP AUTH over SSL?
> 
> Postfix SASL: http://www.postfix.org/SASL_README.html
> Postfix TLS:  http://www.postfix.org/TLS_README.html
> 
> These are organized in client and server sections, with examples.
> There is no need to repeat this information on the mailing list.

Thank you Wietse for your fast response, seems the answer was so
obvious and I should have found it with some internet searching.

However it took me a good number of hours to get it actually working.
There for I am writing down some pointers here so other people may
find them in the mailinglist archives.

I used Debian stable to install postfix with:
apt-get install postfix ca-certificates
# no configuration or satellite

I received the following errors in my configuration:
# (SASL authentication failed; cannot authenticate to server
secure.powercraft.nl[84.245.3.195]: no mechanism available)

Seemed the configuration was fine but I was missing the actual
libaries. So I installed: apt-get install libsasl2-modules

Next pointer, for plain auth over ssl use the folllowing:
postconf -e 'smtp_sasl_auth_enable = yes'
postconf -e 'smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd'
postconf -e 'smtp_sasl_tls_security_options = noanonymous'
postconf -e 'smtp_tls_security_level = encrypt'
postconf -e 'smtp_tls_mandatory_protocols = !SSLv2, !TLSv1'

On the server side use:
smtpd_sender_restrictions = permit_sasl_authenticated, ...

I still had one question of my own: I seem to be only able to use port
25 with postfix, my icedove mta uses secure.powercraft.nl:465 with
ssl, but I cant get that to work with postfix. It will just generate
an time-out after the connection. Port 25 is subjected to blocks and
filters on a increasing number of networks, so I like to keep using
other ports. If somebody found an solution for this, I would be happy
to use it.

Hope that helps some people :)

Kind regards,

Jelle

Re: smtp auth over ssl for smartrelay configuration

[Victor Duchovni]

On Sat, Jan 23, 2010 at 05:31:47PM +0100, Jelle de Jong wrote:

> postconf -e 'smtp_tls_security_level = encrypt'

Is this SMTP client going to send all mail to a small set of TLS enabled
relay hosts? Or are you choosing to not be able to send any email to
the vast majority of domains whose MX hosts don't offer TLS?

> postconf -e 'smtp_tls_mandatory_protocols = !SSLv2, !TLSv1'

Why disable both SSLv2 and TLSv1?! Leave this setting at its default
value, or disable just SSLv2. Does your client or server correctly handle
SSLv3, but fail to interoperate via TLSv1?

> Hope that helps some people :)

And does not mislead too many. A tutorial needs to not only provide
working settings, but also explain the use-case to which they apply
and why the settings are the right ones to the use-case at hand.

-- 
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:


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.

Re: Best way to put spam on hold queue?

[Wietse Venema]

Jozsef Kadlecsik:
> On Sat, 23 Jan 2010, Wietse Venema wrote:
>
> > Jozsef Kadlecsik:
> > >
> > > How could one achieve that the held messages are separated from the normal
> > > traffic (i.e. hold queue on another partition), but if the messages cannot
> > > be held, then those gets rejected instead of queued?
> >
> > Given Postfix's architecture, a loosely-coupled pipeline without
> > global feedback, there is no obvious way to build global feedback
> > into Postfix itself.
> >
> > I suggest that you run an email monitoring system. When the secondary
> > system stops accepting mail for more than some minimum amount of
> > time (allowing enough time for the system to reboot), update the
> > configuration on the primary system.
>
> Yes, monitoring is inevitable. And that imply you would prefer the two
> instances setup :-).
>
> Just as a theoretical question, would it fit somehow into Postfix to
> support the hold queue *alone* in a separated partition?

The architecture requires Postfix can move messages between queues
without having to make copies.

Wietse

Re: Timeout of SMTP servers

[Wietse Venema]

Martijn de Munnik:
> 
> On Jan 23, 2010, at 4:24 PM, Sahil Tandon wrote:
> 
> > On Fri, 22 Jan 2010, Martijn de Munnik wrote:
> > 
> >> RFC2821 section 4.5.3.2 Timeouts reads
> >> 
> >> "An SMTP server SHOULD have a timeout of at least 5 minutes while it
> >> is awaiting the next command from the sender."
> > 
> > The key word is SHOULD, as opposed to MUST.
> 
> "SHOULD" equals "MUST unless you have a really good reason". I'm
> trying to figure out if somebody on the list knows a really good
> reason.

Ask THEIR postmaster.

Wietse

Re: smtp auth over ssl for smartrelay configuration

[Jelle de Jong]

Victor Duchovni wrote, on 23-01-10 17:48:
> On Sat, Jan 23, 2010 at 05:31:47PM +0100, Jelle de Jong wrote:
> 
>> postconf -e 'smtp_tls_security_level = encrypt'
> 
> Is this SMTP client going to send all mail to a small set of TLS enabled
> relay hosts? Or are you choosing to not be able to send any email to
> the vast majority of domains whose MX hosts don't offer TLS?

The system is a satellite system that is only sending mail to one
secure mail server, the mailrelay is only affable for smtp auth over
ssl. the hostname of the sender will fail every sane check if it sent
to other machines, because it has no fixed ip, and is behind a series
of nat's.

>> postconf -e 'smtp_tls_mandatory_protocols = !SSLv2, !TLSv1'
> 
> Why disable both SSLv2 and TLSv1?! Leave this setting at its default
> value, or disable just SSLv2. Does your client or server correctly handle
> SSLv3, but fail to interoperate via TLSv1?

Well my server supports SSLv3 just fine, so I thought I disable
everything lower, and if better protocols come around postfix will
update and will still be able to use the newer stuff since I did not
force it to only use SSLv3.

>> Hope that helps some people :)
> 
> And does not mislead too many. A tutorial needs to not only provide
> working settings, but also explain the use-case to which they apply
> and why the settings are the right ones to the use-case at hand.

All true, that sad the pointer I gave were not related to above and
the documentation handles these points quite well.

Best regards,

Jelle

Putting $data_directory on a RAM filesystem

[Stefan Foerster]

In case of severe server "overload", with postscreen(8) complaining
about lookup and update times around 400ms almost every mail, is it
(reasonably) safe as a last desperate measure to put $data_directory,
or at least the file referenced by $postscreen_cache_map, on a ramdisk
(e.g. "tmpfs" with Linux)?

I know about RAM not being persistent across reboots, and I understand
what happens if the $postscreen_cache_map (or all the contents in
$data_directory) are lost.


Stefan

Re: Timeout of SMTP servers

[Sahil Tandon]

On Sat, 23 Jan 2010, Martijn de Munnik wrote:

> On Jan 23, 2010, at 4:24 PM, Sahil Tandon wrote:
> 
> > On Fri, 22 Jan 2010, Martijn de Munnik wrote:
> > 
> >> RFC2821 section 4.5.3.2 Timeouts reads
> >> 
> >> "An SMTP server SHOULD have a timeout of at least 5 minutes while
> >> it is awaiting the next command from the sender."
> > 
> > The key word is SHOULD, as opposed to MUST.
> 
> "SHOULD" equals "MUST unless you have a really good reason". I'm
> trying to figure out if somebody on the list knows a really good
> reason.

*yawn*.  Perhaps you will benefit from repetition: ask their postmaster,
as I advised in my initial response and others have since echoed.

-- 
Sahil Tandon 

Re: Putting $data_directory on a RAM filesystem

[Victor Duchovni]

On Sat, Jan 23, 2010 at 06:08:40PM +0100, Stefan Foerster wrote:

> In case of severe server "overload", with postscreen(8) complaining
> about lookup and update times around 400ms almost every mail, is it
> (reasonably) safe as a last desperate measure to put $data_directory,
> or at least the file referenced by $postscreen_cache_map, on a ramdisk
> (e.g. "tmpfs" with Linux)?

Yes, but I would still try to find out why the lookup times are so
absurdly large?

-- 
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:


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.

Re: smtp auth over ssl for smartrelay configuration

[Michael Orlitzky]

Jelle de Jong wrote:

Victor Duchovni wrote, on 23-01-10 17:48:

On Sat, Jan 23, 2010 at 05:31:47PM +0100, Jelle de Jong wrote:


postconf -e 'smtp_tls_security_level = encrypt'

Is this SMTP client going to send all mail to a small set of TLS enabled
relay hosts? Or are you choosing to not be able to send any email to
the vast majority of domains whose MX hosts don't offer TLS?


The system is a satellite system that is only sending mail to one
secure mail server, the mailrelay is only affable for smtp auth over
ssl. the hostname of the sender will fail every sane check if it sent
to other machines, because it has no fixed ip, and is behind a series
of nat's.


postconf -e 'smtp_tls_mandatory_protocols = !SSLv2, !TLSv1'

Why disable both SSLv2 and TLSv1?! Leave this setting at its default
value, or disable just SSLv2. Does your client or server correctly handle
SSLv3, but fail to interoperate via TLSv1?


Well my server supports SSLv3 just fine, so I thought I disable
everything lower, and if better protocols come around postfix will
update and will still be able to use the newer stuff since I did not
force it to only use SSLv3.


TLSv1 is newer stuff.

Re: Timeout of SMTP servers

[LuKreme]

On Jan 23, 2010, at 9:17, Martijn de Munnik   
wrote:
"SHOULD" equals "MUST unless you have a really good reason". I'm  
trying to figure out if somebody on the list knows a really good  
reason.


There is no really good reason for a 3 second timeout in a public  
server. There are really good reason for having a timeout less than 5  
minutes though.

Re: smtp auth over ssl for smartrelay configuration

[Victor Duchovni]

On Sat, Jan 23, 2010 at 05:59:37PM +0100, Jelle de Jong wrote:

> >> postconf -e 'smtp_tls_mandatory_protocols = !SSLv2, !TLSv1'
> > 
> > Why disable both SSLv2 and TLSv1?! Leave this setting at its default
> > value, or disable just SSLv2. Does your client or server correctly handle
> > SSLv3, but fail to interoperate via TLSv1?
> 
> Well my server supports SSLv3 just fine, so I thought I disable
> everything lower, and if better protocols come around postfix will
> update and will still be able to use the newer stuff since I did not
> force it to only use SSLv3.

The default settings for advanced TLS features were chosen with care.
It is unwise to change them unless you are a TLS expert. TLSv 1.0 is
SSL 3.1. TLS 1.1 is SSL 3.2, ... There is no plan for TLSv2 at this
time, but it would be SSL version 4.

Don't change advanced TLS settings until you have read the relevant
OpenSSL documentation and/or RFCs and in some cases the OpenSSL source
code (sadly OpenSSL documentation is not as complete as the Postfix
documentation).

-- 
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:


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.

Re: Putting $data_directory on a RAM filesystem

[Wietse Venema]

Stefan Foerster:
> In case of severe server "overload", with postscreen(8) complaining
> about lookup and update times around 400ms almost every mail, is it
> (reasonably) safe as a last desperate measure to put $data_directory,
> or at least the file referenced by $postscreen_cache_map, on a ramdisk
> (e.g. "tmpfs" with Linux)?

Sure, but why do you expect that it will be FASTER?  

Are you perhaps running a busy mail server off a single disk drive?
In that case, splitting the load over multiple drives would make
a big difference.

Is perhaps your system slow because of swapping? In that case,
using tmpfs will make the system swap even more. Instead, even
reducing the process count by 20% could result in a big over-all
improvement.

I haven't seen any attempt at a quantitative analysis of the 
problem, so I won't speculate further.

Wietse

Re: Putting $data_directory on a RAM filesystem

[Stan Hoeppner]

Stefan Foerster put forth on 1/23/2010 11:08 AM:
> In case of severe server "overload", with postscreen(8) complaining
> about lookup and update times around 400ms almost every mail, is it
> (reasonably) safe as a last desperate measure to put $data_directory,
> or at least the file referenced by $postscreen_cache_map, on a ramdisk
> (e.g. "tmpfs" with Linux)?
> 
> I know about RAM not being persistent across reboots, and I understand
> what happens if the $postscreen_cache_map (or all the contents in
> $data_directory) are lost.

If the problem is due to an I/O bottleneck, I'd recommend going SSD instead of
RAM disk.  Get this Crucial 64GB SATA2 unit and put both the postfix spool and
postscreen db files on it:

http://www.newegg.com/Product/Product.aspx?Item=N82E16820148318

Or, like Wietse said, first identify the actual cause of the problem.  Then if
it's I/O related, get an SSD drive.  It's a relatively cheap path to massive
random I/O throughput.

-- 
Stan

451 4.3.0 Error: queue file write error

[Shawn Fee]

Is there a fix for the "451 4.3.0 Error: queue file write error" yet? I
heard to increase the smtp_proxy_timeout = 600s in the main.cf file, but
then I heard that can run down your server.

 

Is there any patches or hot fixes that actually work? I have Postfix 9.3.0
and the 451 error is still not fixed. 



 

Shawn Fee

SGF IT Solutions, LLC | IT Manager



813.817.8706

  s...@sgfitsolutions.com

 

<>