Re: real-world issues with smtpd_tls_ask_ccert?

[Florin Andrei]

Barney Desmond wrote:

Of course, you couldn't enforce this except on a
non-public-facing system, or on the submission port (587).


Actually, that's exactly what I just did. I configured a separate 
listener on 587 and moved all TLS stuff to it. I was reluctant to do so 
at first (the client is an iPhone and the mail config is rather 
primitive) but in the end it worked pretty well.


So, now I'm not worried about that option, since the listener on port 25 
is non-TLS.


Thanks,

--
Florin Andrei

http://florin.myip.org/

anyone? success with smtpd_tls_req_ccert and iPhone as client?

[Florin Andrei]

Using smtpd_tls_req_ccert=yes on port 587.


submission inet n   -   -   -   -   smtpd
  -o smtpd_tls_cert_file=/blah/server.crt
  -o smtpd_tls_key_file=/blah/server.key
  -o smtpd_tls_CAfile=/blah/ca.crt
  -o smtpd_tls_security_level=encrypt
  -o smtpd_tls_loglevel=2
  -o smtpd_tls_req_ccert=yes
  -o smtpd_tls_session_cache_database=btree:${data_directory}/smtpd_scache
  -o smtpd_sasl_type=dovecot
  -o smtpd_sasl_path=private/auth
  -o smtpd_sasl_auth_enable=yes
  -o 
smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination



The client is an iPhone 3G, latest OS. TLS on the iPhone works pretty 
well with Dovecot and imaps ("ssl_require_client_cert: yes" in 
dovecot.conf). Dovecot uses exactly the same certificates (ca.crt, 
server.crt, server.key) like Postfix. All is well with imaps.


But when trying to send email from the iPhone on port 587, I get this:

#
Aug 21 00:06:09 server postfix/smtpd[15709]: connect from some.host[X.Y.Z.K]
Aug 21 00:06:09 server postfix/smtpd[15709]: setting up TLS connection
from some.host[X.Y.Z.K]
Aug 21 00:06:09 server postfix/smtpd[15709]: some.host[X.Y.Z.K]: TLS
cipher list "ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!aNULL"
Aug 21 00:06:09 server postfix/smtpd[15709]: SSL_accept:before/accept
initialization
Aug 21 00:06:09 server postfix/smtpd[15709]: SSL_accept:SSLv3 read
client hello B
Aug 21 00:06:09 server postfix/smtpd[15709]: SSL_accept:SSLv3 write
server hello A
Aug 21 00:06:09 server postfix/smtpd[15709]: SSL_accept:SSLv3 write
certificate A
Aug 21 00:06:09 server postfix/smtpd[15709]: SSL_accept:SSLv3 write
server done A
Aug 21 00:06:09 server postfix/smtpd[15709]: SSL_accept:SSLv3 flush data
Aug 21 00:06:09 server postfix/smtpd[15709]: SSL_accept:SSLv3 read
client key exchange A
Aug 21 00:06:09 server postfix/smtpd[15709]: SSL_accept:SSLv3 read
finished A
Aug 21 00:06:09 server postfix/smtpd[15709]: SSL_accept:SSLv3 write
change cipher spec A
Aug 21 00:06:09 server postfix/smtpd[15709]: SSL_accept:SSLv3 write
finished A
Aug 21 00:06:09 server postfix/smtpd[15709]: SSL_accept:SSLv3 flush data
Aug 21 00:06:09 server postfix/smtpd[15709]: Anonymous TLS connection
established from some.host[X.Y.Z.K]: TLSv1 with cipher AES128-SHA
(128/128 bits)
Aug 21 00:06:09 server postfix/smtpd[15709]: NOQUEUE: abort: TLS from
some.host[X.Y.Z.K]: No client certificate presented
Aug 21 00:06:09 server postfix/smtpd[15709]: disconnect from
some.host[X.Y.Z.K]
Aug 21 00:06:09 server postfix/smtpd[15709]: connect from some.host[X.Y.Z.K]
Aug 21 00:06:09 server postfix/smtpd[15709]: lost connection after HELO
from some.host[X.Y.Z.K]
Aug 21 00:06:09 server postfix/smtpd[15709]: disconnect from
some.host[X.Y.Z.K]
#

If I change it to smtpd_tls_req_ccert=no then everything is fine, an
anonymous TLS connection is established and email is delivered:

###
Aug 21 00:13:37 server postfix/smtpd[16301]: connect from some.host[X.Y.Z.K]
Aug 21 00:13:37 server postfix/smtpd[16301]: setting up TLS connection
from some.host[X.Y.Z.K]
Aug 21 00:13:37 server postfix/smtpd[16301]: some.host[X.Y.Z.K]: TLS
cipher list "ALL:!EXPORT:!LOW:+RC4:@STRENGTH"
Aug 21 00:13:37 server postfix/smtpd[16301]: SSL_accept:before/accept
initialization
Aug 21 00:13:37 server postfix/smtpd[16301]: SSL_accept:SSLv3 read
client hello B
Aug 21 00:13:37 server postfix/smtpd[16301]: SSL_accept:SSLv3 write
server hello A
Aug 21 00:13:37 server postfix/smtpd[16301]: SSL_accept:SSLv3 write
certificate A
Aug 21 00:13:37 server postfix/smtpd[16301]: SSL_accept:SSLv3 write
server done A
Aug 21 00:13:37 server postfix/smtpd[16301]: SSL_accept:SSLv3 flush data
Aug 21 00:13:37 server postfix/smtpd[16301]: SSL_accept:SSLv3 read
client key exchange A
Aug 21 00:13:37 server postfix/smtpd[16301]: SSL_accept:SSLv3 read
finished A
Aug 21 00:13:37 server postfix/smtpd[16301]: SSL_accept:SSLv3 write
change cipher spec A
Aug 21 00:13:37 server postfix/smtpd[16301]: SSL_accept:SSLv3 write
finished A
Aug 21 00:13:37 server postfix/smtpd[16301]: SSL_accept:SSLv3 flush data
Aug 21 00:13:37 server postfix/smtpd[16301]: Anonymous TLS connection
established from some.host[X.Y.Z.K]: TLSv1 with cipher AES128-SHA
(128/128 bits)
#

Is there any magic incantation that needs to be performed to convince
the iPhone to present the certificate to Postfix? The puzzling part is 
that it seems to work fine with Dovecot and imaps.


I installed the client cert on the iPhone by uploading it to a local web
server and browsing it on the iPhone - Safari detects the cert and
installs it automatically.

--
Florin Andrei

http://florin.myip.org/

Re: real-world issues with smtpd_tls_ask_ccert?

[Ralf Hildebrandt]

* Florin Andrei :
> I'm setting up SASL with TLS for remote clients. As an additional
> security measure, I would like the server to ask the email clients to
> present their client certificates. According to the docs, this is
> accomplished with:
> 
> smtpd_tls_ask_ccert = yes
> 
> But there are some ominous warnings about broken MTAs which may have
> problems when delivering to Postfix if this option is used. If I
> understand correctly, the broken delivery should only occur when
> those MTAs attempt to do TLS to Postfix. So, this should not be a
> problem for all the regular, unencrypted email I receive normally, is
> that right?

Yes.
 
> Also, after enabling this option, I connected to Postfix with a
> TLS-enabled email client with all the certificates installed. I saw
> this line in the logs:
> 
> Aug 20 22:49:01 server postfix/smtpd[7724]: connect from
> unknown[XXX.YYY.ZZZ.KKK]
> Aug 20 22:49:02 server postfix/smtpd[7724]: setting up TLS connection
> from unknown[XXX.YYY.ZZZ.KKK]
> Aug 20 22:49:02 server postfix/smtpd[7724]: Anonymous TLS connection
> established from unknown[XXX.YYY.ZZZ.KKK]: TLSv1 with cipher
> AES128-SHA (128/128 bits)
> 
> Why does it say "Anonymous TLS connection"? 

Because the TLS certificate is not signed by a trusted CA.

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de

Re: anyone? success with smtpd_tls_req_ccert and iPhone as client?

[Noel Jones]

Florin Andrei wrote:


Is there any magic incantation that needs to be performed to convince
the iPhone to present the certificate to Postfix? The puzzling part is 
that it seems to work fine with Dovecot and imaps.




Very few mail clients support client certificates.  Unless you 
will be using only clients known to support certificates, 
don't bother with them.


  -- Noel Jones

Re: real-world issues with smtpd_tls_ask_ccert?

[Noel Jones]

Ralf Hildebrandt wrote:


Aug 20 22:49:01 server postfix/smtpd[7724]: connect from
unknown[XXX.YYY.ZZZ.KKK]
Aug 20 22:49:02 server postfix/smtpd[7724]: setting up TLS connection
from unknown[XXX.YYY.ZZZ.KKK]
Aug 20 22:49:02 server postfix/smtpd[7724]: Anonymous TLS connection
established from unknown[XXX.YYY.ZZZ.KKK]: TLSv1 with cipher
AES128-SHA (128/128 bits)

Why does it say "Anonymous TLS connection"? 


Because the TLS certificate is not signed by a trusted CA.



No, it's because an anonymous cipher is used when there is no 
client certificate.  If it was a certificate trust problem, 
the connection would be labeled "Untrusted".


  -- Noel Jones

Re: Significant relay delays

[Phill Macey]

Sorry in advance for the top posting or whatever gmail does on mobile
phones - i have no control over that. I bumped into a very similar
problem today. Mail was queuing up on one of our servers with exactly
the same messages as what you had. In our case a perl script on the
postfix server had gone crazy and started consuming all the memory and
swap space on the machine. Once that was fixed, the errors cleared up
and the mail queue emptied itself. HTH

On 8/21/09, MySQL Student  wrote:
> Hi,
>
> I have been using an older version of postfix on a relay server for
> quite a few years now, without any real incident. It accepts mail from
> one or two other servers and forwards it on to an internal Exchange
> server on the same network. It handles about 250k messages per day.
> It's configured with dual instances.
>
> It seems for the last few months there is an increasing delay in
> delivery times and I can't explain why. I suspect something on the
> Exchange side because nothing has changed on the postfix server. The
> administrators of the Exchange box aren't able to provide any ideas
> either. I'm also pretty sure it's not a network issue. After passing
> billions of packets there isn't a single error. I'm also pretty sure
> DNS is configured properly.
>
> I'm seeing occasions where there will be a constant 50 messages in the
> second instance, and as many as 500 at times. The 500 messages may sit
> there for a half-hour, and then all of the sudden they are delivered.
> However, there remains a constant 50 in the queue with status info
> like "conversation timed out while sending end of data -- message may
> be sent more than once" or "Error: timeout exceeded (in reply to end
> of DATA command)".
>
> The messages may sit in the queue for even a few weeks, and I assume
> are eventually delivered.
>
> In my mail log, I see info like the following:
>
> Aug 20 01:08:12 bocmailrelay POSTFIX_F/smtp[1186]: C638B1A8008: to= l...@example.com>, relay=mail.example.com[xxx.yyy.zzz.3], delay=625109, st
> atus=deferred (conversation with mail.example.com[xxx.yyy.zzz.3] timed out
> while sending end of data -- message may be sent more than once)
>
> I'm having difficulty discerning messages entering the second queue
> (with delay=0, typically) and messages being
> queued because they couldn't immediately be delivered. Is there an
> easier way to establish which messages are
> being queued because they couldn't easily be delivered?
>
> I thought I would try "debug_peer_list" and increase logging to try
> and get information on delays from a specific domain, but I'm not sure
> that is what this variable is used for. Is there another way to
> increase logging either for a specific domain or for this problem to
> better troubleshoot it?
>
> Thanks,
> Alex Hayes
>

-- 
Sent from Gmail for mobile | mobile.google.com

Phill

--
There's no such thing as a stupid question,
but they're the easiest to answer!

At the end of the game, the king and the pawn go back in the same box.

I souport publik edukashun

"Build a man a fire, and he'll be warm for a day. Set a man on fire,
and he'll be warm for the rest of his life."
Terry Pratchett

Re: real-world issues with smtpd_tls_ask_ccert?

[Victor Duchovni]

On Fri, Aug 21, 2009 at 06:09:52AM -0500, Noel Jones wrote:

> Ralf Hildebrandt wrote:
>>>
>>> Aug 20 22:49:01 server postfix/smtpd[7724]: connect from
>>> unknown[XXX.YYY.ZZZ.KKK]
>>> Aug 20 22:49:02 server postfix/smtpd[7724]: setting up TLS connection
>>> from unknown[XXX.YYY.ZZZ.KKK]
>>> Aug 20 22:49:02 server postfix/smtpd[7724]: Anonymous TLS connection
>>> established from unknown[XXX.YYY.ZZZ.KKK]: TLSv1 with cipher
>>> AES128-SHA (128/128 bits)
>>>
>>> Why does it say "Anonymous TLS connection"? 
>> Because the TLS certificate is not signed by a trusted CA.
>
> No, it's because an anonymous cipher is used when there is no client 
> certificate.  If it was a certificate trust problem, the connection would 
> be labeled "Untrusted".

No, it is because the client did not provide a certificate. The cipher
AES128-SHA is not an "anonymous" cipher, the server did provide a
certificate to the client, but the converse was false.

Don't confuse anonymous ciphers, with anonymous clients using a cipher
that (if the client bothers, ...) authenticates the server.

-- 
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: anyone? success with smtpd_tls_req_ccert and iPhone as client?

[Victor Duchovni]

On Fri, Aug 21, 2009 at 06:02:41AM -0500, Noel Jones wrote:

> Florin Andrei wrote:
>> Is there any magic incantation that needs to be performed to convince
>> the iPhone to present the certificate to Postfix? The puzzling part is 
>> that it seems to work fine with Dovecot and imaps.
>
> Very few mail clients support client certificates.  Unless you will be 
> using only clients known to support certificates, don't bother with them.

The only mainstream fully-featured MUA I've found that supports client
certs with SMTP is Mulberry. Outlook, Mail.app, Thunderbird, ... do not
IIRC.

-- 
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: anyone? success with smtpd_tls_req_ccert and iPhone as client?

[Patrick Ben Koetter]

* Victor Duchovni :
> On Fri, Aug 21, 2009 at 06:02:41AM -0500, Noel Jones wrote:
> 
> > Florin Andrei wrote:
> >> Is there any magic incantation that needs to be performed to convince
> >> the iPhone to present the certificate to Postfix? The puzzling part is 
> >> that it seems to work fine with Dovecot and imaps.
> >
> > Very few mail clients support client certificates.  Unless you will be 
> > using only clients known to support certificates, don't bother with them.
> 
> The only mainstream fully-featured MUA I've found that supports client
> certs with SMTP is Mulberry. Outlook, Mail.app, Thunderbird, ... do not
> IIRC.

Thunderbird does.
Turn on smtpd_tls_req_ccert and try to send using Thunderbird.

p...@rick

-- 
All technical questions asked privately will be automatically answered on the
list and archived for public access unless privacy is explicitely required and
justified.

saslfinger (debugging SMTP AUTH):

Re: real-world issues with smtpd_tls_ask_ccert?

[Noel Jones]

Victor Duchovni wrote:

On Fri, Aug 21, 2009 at 06:09:52AM -0500, Noel Jones wrote:


Ralf Hildebrandt wrote:

Aug 20 22:49:01 server postfix/smtpd[7724]: connect from
unknown[XXX.YYY.ZZZ.KKK]
Aug 20 22:49:02 server postfix/smtpd[7724]: setting up TLS connection
from unknown[XXX.YYY.ZZZ.KKK]
Aug 20 22:49:02 server postfix/smtpd[7724]: Anonymous TLS connection
established from unknown[XXX.YYY.ZZZ.KKK]: TLSv1 with cipher
AES128-SHA (128/128 bits)

Why does it say "Anonymous TLS connection"? 

Because the TLS certificate is not signed by a trusted CA.
No, it's because an anonymous cipher is used when there is no client 
certificate.  If it was a certificate trust problem, the connection would 
be labeled "Untrusted".


No, it is because the client did not provide a certificate. The cipher
AES128-SHA is not an "anonymous" cipher, the server did provide a
certificate to the client, but the converse was false.

Don't confuse anonymous ciphers, with anonymous clients using a cipher
that (if the client bothers, ...) authenticates the server.



Bah!  I always mess that up, maybe next time I'll get it 
right.  Thanks for the clarification and glad to have you back.


  -- Noel Jones

Re: anyone? success with smtpd_tls_req_ccert and iPhone as client?

[Victor Duchovni]

On Fri, Aug 21, 2009 at 04:51:45PM +0200, Patrick Ben Koetter wrote:

> * Victor Duchovni :
> > On Fri, Aug 21, 2009 at 06:02:41AM -0500, Noel Jones wrote:
> > 
> > > Florin Andrei wrote:
> > >> Is there any magic incantation that needs to be performed to convince
> > >> the iPhone to present the certificate to Postfix? The puzzling part is 
> > >> that it seems to work fine with Dovecot and imaps.
> > >
> > > Very few mail clients support client certificates.  Unless you will be 
> > > using only clients known to support certificates, don't bother with them.
> > 
> > The only mainstream fully-featured MUA I've found that supports client
> > certs with SMTP is Mulberry. Outlook, Mail.app, Thunderbird, ... do not
> > IIRC.
> 
> Thunderbird does.
> Turn on smtpd_tls_req_ccert and try to send using Thunderbird.

It has been some time since I looked at this, hence the IIRC. Mulberry
made the setting explicit, and perhaps allowed one to choose the right
client cert. If I recall correctly, Thunderbird uses certificates
silently, without explicit configuration control... I any case, this
is not a very frequently used MUA feature.

-- 
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: real-world issues with smtpd_tls_ask_ccert?

[Wietse Venema]

Noel Jones:
> Victor Duchovni wrote:
> > On Fri, Aug 21, 2009 at 06:09:52AM -0500, Noel Jones wrote:
> > 
> >> Ralf Hildebrandt wrote:
>  Aug 20 22:49:01 server postfix/smtpd[7724]: connect from
>  unknown[XXX.YYY.ZZZ.KKK]
>  Aug 20 22:49:02 server postfix/smtpd[7724]: setting up TLS connection
>  from unknown[XXX.YYY.ZZZ.KKK]
>  Aug 20 22:49:02 server postfix/smtpd[7724]: Anonymous TLS connection
>  established from unknown[XXX.YYY.ZZZ.KKK]: TLSv1 with cipher
>  AES128-SHA (128/128 bits)
> 
>  Why does it say "Anonymous TLS connection"? 
> >>> Because the TLS certificate is not signed by a trusted CA.
> >> No, it's because an anonymous cipher is used when there is no client 
> >> certificate.  If it was a certificate trust problem, the connection would 
> >> be labeled "Untrusted".
> > 
> > No, it is because the client did not provide a certificate. The cipher
> > AES128-SHA is not an "anonymous" cipher, the server did provide a
> > certificate to the client, but the converse was false.
> > 
> > Don't confuse anonymous ciphers, with anonymous clients using a cipher
> > that (if the client bothers, ...) authenticates the server.
> 
> Bah!  I always mess that up, maybe next time I'll get it 
> right.  Thanks for the clarification and glad to have you back.

I looked up TLS_README, and it would not hurt to have a short
sentence here and there to define terminology.

Wietse

Re: real-world issues with smtpd_tls_ask_ccert?

[Victor Duchovni]

On Fri, Aug 21, 2009 at 12:35:38PM -0400, Wietse Venema wrote:

> I looked up TLS_README, and it would not hurt to have a short
> sentence here and there to define terminology.

Will the following do?

Index: proto/TLS_README.html
--- proto/TLS_README.html   28 Apr 2009 21:44:30 -  1.1.1.2
+++ proto/TLS_README.html   21 Aug 2009 17:28:25 -
@@ -425,10 +425,40 @@
 
 
 /etc/postfix/main.cf:
-smtpd_tls_loglevel = 0
+smtpd_tls_loglevel = 1
 
 
 
+ With log levels 1 and higher, the TLS handshake status is logged
+as follows (example using syslog-ng with ISO date timestamps): 
+
+
+
+2009-08-21T12:00:00-0400 amnesiac postfix/smtpd[30440]: Anonymous TLS 
connection established from smtpout.example.com[192.0.2.1]: TLSv1 with cipher 
RC4-SHA (128/128 bits)
+
+
+
+ Here, "Anonymous" means that the remote SMTP client did not present
+a certificate to "prove" its identity, which is the usual case, since by
+default the Postfix SMTP server does not ask for a client certificate, and
+so none is sent even if the SMTP client is configured with a certificate
+(many are not). 
+
+ Do not confuse "Anonymous" clients (as above) with anonymous TLS
+ciphers.  With anonymous TLS ciphers, neither the server nor the client
+use certificates. Such ciphers have "ADH" (Anonymous Diffie-Hellman)
+or "AECDH" (Anonymous Elliptic Curve Diffie-Hellman) in their name,
+and in this case the Postfix SMTP client records the remote SMTP
+server as "Anonymous". 
+
+ When the Postfix SMTP server asks for a client certificate and
+the remote SMTP client presents one, "Anonymous" will be replaced by
+"Trusted" if the client certificate trust chain is valid and certificate
+is not expired, or "Untrusted" otherwise. Client certificates are never
+"Verified", as the Postfix SMTP server does not expect any particular
+client identity that it can verify. Postfix uses client certificates
+only for access control, not identity verification. 
+
  To include information about the protocol and cipher used as
 well as the client and issuer CommonName into the "Received:"
 message header, set the smtpd_tls_received_header variable to true.
@@ -1102,10 +1132,39 @@
 
 
 /etc/postfix/main.cf:
-smtp_tls_loglevel = 0
+smtp_tls_loglevel = 1
 
 
 
+ With log levels 1 and higher, the TLS handshake status is logged
+as follows (example using syslog-ng with ISO date timestamps): 
+
+
+
+2009-08-21T00:00:06-0400 amnesiac postfix/smtp[3592]: Untrusted TLS connection 
established to smtpin.example.com[192.0.2.1]:25: TLSv1 with cipher RC4-MD5 
(128/128 bits)
+
+
+
+ Here, "Untrusted" means that the remote SMTP server certificate is
+not signed by a trusted root CA, or is expired, or required intermediate
+certificates are not sent by the remote SMTP server, or some other issue
+makes it impossible to determine the server identity. This is the normal
+case with a self-signed remote server certificate. 
+
+ When the Postfix SMTP client is not configured to verify the
+server certificate (smtp_tls_security_level = "may" or "encrypt") some
+connections will use anonymous TLS ciphers, where the server does not
+present any certificate. In this case, "Untrusted" will be replaced by
+"Anonymous". 
+
+ When the remote SMTP server certificate is signed by a trusted root
+CA and is not expired, the connection will be logged as "Trusted" or
+"Verified". The latter means that the client is configured to verify the
+server's identity (smtp_tls_security_level = "fingerprint", "verify" or
+"secure") and the certificate matched the configured criteria. If the
+Postfix SMTP client is not verifying the server identity, the connection
+is logged as "Trusted". 
+
 Client-side TLS session cache 
 
  The remote SMTP server and the Postfix SMTP client negotiate a

-- 
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: real-world issues with smtpd_tls_ask_ccert?

[Wietse Venema]

Victor Duchovni:
> On Fri, Aug 21, 2009 at 12:35:38PM -0400, Wietse Venema wrote:
> 
> > I looked up TLS_README, and it would not hurt to have a short
> > sentence here and there to define terminology.
> 
> Will the following do?

Yes, that helps.

Wietse

> Index: proto/TLS_README.html
> --- proto/TLS_README.html 28 Apr 2009 21:44:30 -  1.1.1.2
> +++ proto/TLS_README.html 21 Aug 2009 17:28:25 -
> @@ -425,10 +425,40 @@
>  
>  
>  /etc/postfix/main.cf:
> -smtpd_tls_loglevel = 0
> +smtpd_tls_loglevel = 1
>  
>  
>  
> + With log levels 1 and higher, the TLS handshake status is logged
> +as follows (example using syslog-ng with ISO date timestamps): 
> +
> +
> +
> +2009-08-21T12:00:00-0400 amnesiac postfix/smtpd[30440]: Anonymous TLS 
> connection established from smtpout.example.com[192.0.2.1]: TLSv1 with cipher 
> RC4-SHA (128/128 bits)
> +
> +
> +
> + Here, "Anonymous" means that the remote SMTP client did not present
> +a certificate to "prove" its identity, which is the usual case, since by
> +default the Postfix SMTP server does not ask for a client certificate, and
> +so none is sent even if the SMTP client is configured with a certificate
> +(many are not). 
> +
> + Do not confuse "Anonymous" clients (as above) with anonymous TLS
> +ciphers.  With anonymous TLS ciphers, neither the server nor the client
> +use certificates. Such ciphers have "ADH" (Anonymous Diffie-Hellman)
> +or "AECDH" (Anonymous Elliptic Curve Diffie-Hellman) in their name,
> +and in this case the Postfix SMTP client records the remote SMTP
> +server as "Anonymous". 
> +
> + When the Postfix SMTP server asks for a client certificate and
> +the remote SMTP client presents one, "Anonymous" will be replaced by
> +"Trusted" if the client certificate trust chain is valid and certificate
> +is not expired, or "Untrusted" otherwise. Client certificates are never
> +"Verified", as the Postfix SMTP server does not expect any particular
> +client identity that it can verify. Postfix uses client certificates
> +only for access control, not identity verification. 
> +
>   To include information about the protocol and cipher used as
>  well as the client and issuer CommonName into the "Received:"
>  message header, set the smtpd_tls_received_header variable to true.
> @@ -1102,10 +1132,39 @@
>  
>  
>  /etc/postfix/main.cf:
> -smtp_tls_loglevel = 0
> +smtp_tls_loglevel = 1
>  
>  
>  
> + With log levels 1 and higher, the TLS handshake status is logged
> +as follows (example using syslog-ng with ISO date timestamps): 
> +
> +
> +
> +2009-08-21T00:00:06-0400 amnesiac postfix/smtp[3592]: Untrusted TLS 
> connection established to smtpin.example.com[192.0.2.1]:25: TLSv1 with cipher 
> RC4-MD5 (128/128 bits)
> +
> +
> +
> + Here, "Untrusted" means that the remote SMTP server certificate is
> +not signed by a trusted root CA, or is expired, or required intermediate
> +certificates are not sent by the remote SMTP server, or some other issue
> +makes it impossible to determine the server identity. This is the normal
> +case with a self-signed remote server certificate. 
> +
> + When the Postfix SMTP client is not configured to verify the
> +server certificate (smtp_tls_security_level = "may" or "encrypt") some
> +connections will use anonymous TLS ciphers, where the server does not
> +present any certificate. In this case, "Untrusted" will be replaced by
> +"Anonymous". 
> +
> + When the remote SMTP server certificate is signed by a trusted root
> +CA and is not expired, the connection will be logged as "Trusted" or
> +"Verified". The latter means that the client is configured to verify the
> +server's identity (smtp_tls_security_level = "fingerprint", "verify" or
> +"secure") and the certificate matched the configured criteria. If the
> +Postfix SMTP client is not verifying the server identity, the connection
> +is logged as "Trusted". 
> +
>  Client-side TLS session cache 
>  
>   The remote SMTP server and the Postfix SMTP client negotiate a
> 
> -- 
>   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: anyone? success with smtpd_tls_req_ccert and iPhone as client?

[Florin Andrei]

Victor Duchovni wrote:


It has been some time since I looked at this, hence the IIRC. Mulberry
made the setting explicit, and perhaps allowed one to choose the right
client cert. If I recall correctly, Thunderbird uses certificates
silently, without explicit configuration control... I any case, this
is not a very frequently used MUA feature.


That's pretty disappointing. Sounds like man-in-the-middle attacks might 
actually be doable then.


Would y'all be worried about the SASL authentication, given that the SSL 
layer has holes? I'm talking from a real-world perspective. Data - 
forget it, it's SMTP anyway. But the user/pass credentials - that's a 
different story.


Would you be comfortable sending authentication over this kind of SSL 
channel?


I'm trying pretty hard to avoid building a full-blown VPN just for the 
iPhone. I already use OpenVPN, but it doesn't work on the iPhone, so I 
would have to install / configure an IPSec thing from scratch if the 
iPhone doesn't play nice with SMTP / SSL / SASL. It's not rocket science 
but it's a lot of tedious work.


--
Florin Andrei

http://florin.myip.org/

Re: anyone? success with smtpd_tls_req_ccert and iPhone as client?

[Victor Duchovni]

On Fri, Aug 21, 2009 at 11:08:31AM -0700, Florin Andrei wrote:

> Victor Duchovni wrote:
>> It has been some time since I looked at this, hence the IIRC. Mulberry
>> made the setting explicit, and perhaps allowed one to choose the right
>> client cert. If I recall correctly, Thunderbird uses certificates
>> silently, without explicit configuration control... I any case, this
>> is not a very frequently used MUA feature.
>
> That's pretty disappointing. Sounds like man-in-the-middle attacks might 
> actually be doable then.

If the client has robust server certificate verification, there is no
need for client certs to fend off MITM.

The Postfix SMTP client has robust server certificate verification. As
for various MUAs, they typically validate the server certificate even
when they don't support client certs.

Unlike the Postfix SMTP client, their verification code may be vulnerable
to the NULL byte issue disclosed by Dan Kaminsky and "Moxie Marlinspike"
at the most recent Black Hat conference, but bugs aside, the MUAs should
be able resist MITM without client certs.

> Would y'all be worried about the SASL authentication, given that the SSL 
> layer has holes? I'm talking from a real-world perspective. Data - forget 
> it, it's SMTP anyway. But the user/pass credentials - that's a different 
> story.

Attacks on SSL would not be my primary concern, rather I'd be more
worried about phishing, malware, ... and other less sophisticated means
of compromising user credentials.

> Would you be comfortable sending authentication over this kind of SSL 
> channel?

If you want to avoid password compromise, use CRAM-MD5 or GSSAPI, ...

> I'm trying pretty hard to avoid building a full-blown VPN just for the 
> iPhone. I already use OpenVPN, but it doesn't work on the iPhone, so I 
> would have to install / configure an IPSec thing from scratch if the iPhone 
> doesn't play nice with SMTP / SSL / SASL. It's not rocket science but it's 
> a lot of tedious work.

If you are using the Carrier networks, active attacks are not easy to
carry out. If you are using Wi-Fi, perhaps you need a client patched
against the NULL byte problem. Client certs are OK if the iPhone
mail client supports them, but it may not...

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

Errors from the Xserve

[The Doctor]

postconf -n 

command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
enable_server_options = yes
header_checks = regexp:/etc/postfix/header_checks
home_mailbox = Mailbox
html_directory = no
local_recipient_maps = unix:passwd.byname $alias_maps
mail_owner = _postfix
mailbox_command = /usr/bin/procmail
mailbox_size_limit = 0
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
message_size_limit = 1048576000
mydestination = 
$myhostname,localhost.$mydomain,localhost,$mydomain,mail.$mydomain,www.$mydomain,ftp.$mydomain
mydomain = vstudios.ca
mydomain_fallback = localhost
myhostname = mail.vstudios.ca
mynetworks = 204.209.81.19/32, 127.0.0.0/8, 208.118.93.0/24
newaliases_path = /usr/bin/newaliases
queue_directory = /private/var/spool/postfix
readme_directory = /usr/share/doc/postfix
sample_directory = /usr/share/doc/postfix/examples
sendmail_path = /usr/sbin/sendmail
setgid_group = _postdrop
smtpd_enforce_tls = no
smtpd_pw_server_security_options = login,plain
smtpd_recipient_restrictions = 
permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination,permit
smtpd_sasl_auth_enable = yes
smtpd_tls_cert_file = /etc/certificates/Default.crt
smtpd_tls_key_file = /etc/certificates/Default.key
smtpd_use_pw_server = yes
smtpd_use_tls = yes
transport_maps = hash:/etc/postfix/transport
unknown_local_recipient_reject_code = 550
virtual_alias_domains = innovationsmusic.com visionarycollege.ab.ca 
visionaryentertainment.ca camprockstar.ca futuresfest.com muse-musicunites.com
virtual_alias_maps = hash:/etc/mail/virtual

Here is the mail.log from that server

Aug 21 15:08:15 Xserve-002436F349EE postfix/master[78438]: fatal: open lock 
file pid/master.pid: unable to set exclusive lock: Resource temporarily 
unavailable
Aug 21 15:08:25 Xserve-002436F349EE postfix/master[78439]: fatal: open lock 
file pid/master.pid: unable to set exclusive lock: Resource temporarily 
unavailable
Aug 21 15:08:35 Xserve-002436F349EE postfix/master[78440]: fatal: open lock 
file pid/master.pid: unable to set exclusive lock: Resource temporarily 
unavailable
Aug 21 15:08:45 Xserve-002436F349EE postfix/master[78441]: fatal: open lock 
file pid/master.pid: unable to set exclusive lock: Resource temporarily 
unavailable
Aug 21 15:08:55 Xserve-002436F349EE postfix/master[78447]: fatal: open lock 
file pid/master.pid: unable to set exclusive lock: Resource temporarily 
unavailable
Aug 21 15:09:05 Xserve-002436F349EE postfix/master[78449]: fatal: open lock 
file pid/master.pid: unable to set exclusive lock: Resource temporarily 
unavailable
Aug 21 15:09:15 Xserve-002436F349EE postfix/master[78471]: fatal: open lock 
file pid/master.pid: unable to set exclusive lock: Resource temporarily 
unavailable
Aug 21 15:09:25 Xserve-002436F349EE postfix/master[78499]: fatal: open lock 
file pid/master.pid: unable to set exclusive lock: Resource temporarily 
unavailable
Aug 21 15:09:35 Xserve-002436F349EE postfix/master[78500]: fatal: open lock 
file pid/master.pid: unable to set exclusive lock: Resource temporarily 
unavailable
Aug 21 15:09:45 Xserve-002436F349EE postfix/master[78501]: fatal: open lock 
file pid/master.pid: unable to set exclusive lock: Resource temporarily 
unavailable 

And here is wht the PRimary DNS server is seeing


Aug 21 03:16:25 doctor postfix/smtp[6746]: 6D8BA12CFAD3: 
to=, relay=mail.vstudios.ca[204.209.81.19]:25, 
delay=0.19, delays=0.01/0.04/0.13/0.01, dsn=5.1.1, status=undeliverable (host 
mail.vstudios.ca[204.209.81.19] said: 550 5.1.1 : 
Recipient address rejected: User unknown in virtual alias table (in reply to 
RCPT TO command))
Aug 21 03:18:10 doctor postfix/smtp[6737]: 2F09E12CFAD4: 
to=, relay=mail.vstudios.ca[204.209.81.19]:25, 
delay=0.13, delays=0.01/0.01/0.11/0.01, dsn=5.1.1, status=undeliverable (host 
mail.vstudios.ca[204.209.81.19] said: 550 5.1.1 : 
Recipient address rejected: User unknown in virtual alias table (in reply to 
RCPT TO command))
Aug 21 07:03:24 doctor postfix/smtp[16638]: C2D3712CFAD3: 
to=, relay=mail.vstudios.ca[204.209.81.19]:25, 
delay=0.24, delays=0.05/0/0.18/0.01, dsn=5.1.1, status=undeliverable (host 
mail.vstudios.ca[204.209.81.19] said: 550 5.1.1 : 
Recipient address rejected: User unknown in virtual alias table (in reply to 
RCPT TO command))
Aug 21 07:21:57 doctor postfix/smtp[20043]: 4EC5612CFAD3: 
to=, relay=mail.vstudios.ca[204.209.81.19]:25, 
delay=0.16, delays=0.01/0/0.14/0.01, dsn=5.1.1, status=undeliverable (host 
mail.vstudios.ca[204.209.81.19] said: 550 5.1.1 : 
Recipient address rejected: User unknown in virtual alias table (in reply to 
RCPT TO command))
Aug 21 07:44:35 doctor postfix/smtp[24057]: 4246D12CFAD3: 
to=, relay=mail.vstudios.ca[204.209.81.19]:25, 
delay=0.2, delays=0.03/0.04/0.13/0.01, dsn=5.1.1, status=undeliverable (host 
mail.vstudios.ca[204.209.81.19] said: 550 5.1.1 : 
Recipient address rejected: User unknown in virtual alias ta

Re: MS-Exchange fails when receiving postfix has smtpd_enforce_tls=true

[Victor Duchovni]

On Fri, Aug 21, 2009 at 10:54:49PM +0200, gmx wrote:

> Hi Victor,
> 
> In http://marc.info/?l=postfix-users&m=116171112425304&w=2 you described
> problems with ciphers when connecting from MS-Exchange to postfix. Has there
> been any improvement in the last almost-3 years?

AFAIK, the problem is resolved in Vista at the latest SP levels.  XP,
and perhaps Server 2003 are AFAIK still broken for ciphers other than RC4.

> In a similar vein, we are having problems to mandatorily send TLS encrypted
> mails from an MS-Exchange to a postfix.
> 
> We always get a 
> 
> <<530 5.0.0 Permanent message delivery failure - 530 5.7.0 Must issue a
> STARTTLS command first (in reply to end of DATA command))>>

This is logged by the Postfix SMTP client, when sending mail out, not
the SMTP server. Perhaps you are inadvertantly enforcing TLS post
content filter, ...

> Postfix 2.4.6 settings are
> smtpd_tls_cipherlist = MEDIUM:HIGH:!MD5:!aNULL

This parameter is not used in 2.3 or later, and this setting is not wise
in any case.

> smtpd_tls_mandatory_ciphers=medium
> smtpd_tls_exclude_ciphers=aNULL

This is fine.

> smtpd_enforce_tls = yes

Ignored.

> smtpd_tls_security_level=encrypt

This makes the former unnecessary.

> When we turn off the last 2, it all works fine, and the received header
> still claims that the message had 
> 
> >  (using TLSv1 with cipher RC4-MD5 (128/128 bits))
> >  (No client certificate requested)
> >  (Authenticated sender: umbricht...@sig.privasphere.com)
> 
> but AFAIK without the last 2, we cannot prevent sending-side omissions of
> TLS from the receiving side and we would really like to ensure that as
> receivers.

Sure looks like you are having trouble forwarding mail received from
Exchange, not receiving from Exchange.

-- 
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: rbl checks, best place

[mouss]

Dave a écrit :
> Hello,
>   I'm running postfix, amavisd-new and spamassassin. Currently in my
> postfix smtpd_recipient_restrictions right at the end last thing i have some
> rbl checks. I'm wondering if that's the best place for them or should i
> disable that and activate them in spamassassin? Suggestions welcome.
> Thanks.
> Dave.
> 

think defense in depth. at each oignon layer, get rid of part of the
unwanted traffic.

- at the firewall level, get rid of those "hopeless networks".

- at postfix level, reject transactions that should not "occur"
(independently of content)

- at SA, tag mail based on its content.


at postfix level, use zen.spamhaus.org. it is safe and effective. you
can also use spamcop and korea.services.net but these won't catch a lot
of junk. other lists are better used in SA.

Re: rbl checks, best place

[mouss]

Olivier Nicole a écrit :
> Hi Dave,
> 
>>  I'm running postfix, amavisd-new and spamassassin. Currently in my
>> postfix smtpd_recipient_restrictions right at the end last thing i have some
>> rbl checks. I'm wondering if that's the best place for them or should i
>> disable that and activate them in spamassassin? Suggestions welcome.
> 
> This is a difficult question.
> 
> Do you really 100% trust the rbl you are using to have no false
> positive (some were listing gmail.com recently)?

some list the universe (voluntarily). I can setup one now, if I was not
sure some people would use it and complain...

but the existence of bad lists doesn't make good lists bad.

> 
> If yes, the you can keep the rbl in postfix, it rejects the email at
> earlier stage.
> 
> If no, you better test rbl in SA, as the rbl test only contributes to
> the final score.
> 
> I personnally use the second.
> 

- some lists are safe for blocking at router/firewall level.
- some lists are safe for rejection at postfix level
- some lists are safe for tagging in SA
- some lists are just unsafe

so the decision where/how to use a list doesn't result in "I use them
this way", but "I use different defenses at different places in
different ways".

here, a very small percentage ever makes it to SA.

virus_scan_failed

[Oscar m Cruz]

Hi list

I've been doing a problem with my server apparently all virus scan fail
after 2 weeks of working without reboot it, i suspect that my server is not
mount on the best equipment, because im runnning a postfix mail server, web
server, ftp server etc using an simple desktop computer, whenever this error
comes i have to reboot my server so that everything ok.

is there a far solution for using and solve that problem or is a
configuration error ?

if yes please let me know all help is welcome


now i show you the log


F003D25C001 2057 Fri Aug 21 16:10:58  u...@domain.com
(host 127.0.0.1[127.0.0.1] said: 451-4.5.0 Error in processing, id=08510-11,
virus_scan FAILED: virus_scan: ALL VIRUS SCANNERS FAILED: ClamAV-clamd
av-scanner FAILED: CODE(0x816e564) Too many retries to talk to
127.0.0.1:3310 (Can't connect to INET socket 127.0.0.1:3310: Connection
refused) at (eval 69) line 310. at (eval 69) line 511.; Avira AntiVir
av-scanner FAILED: /usr/sbin/antivir unexpected exit 200, output="error (not
enough memory available):  451-4.5.0  451-4.5.0 AntiVir / Linux Version
2.1.10-15 451-4.5.0 Copyright (c) 2007 by Avira GmbH. 451-4.5.0 All rights
reserved. 451 4.5.0 " at (eval 69) line 511.; ClamAV-clamscan av-scanner
FAILED: /usr/bin/clamscan run_command (open pipe): Can't fork at
/usr/lib/perl5/5.8.8/i586-linux-thread-multi/IO/File.pm line 192. at
/usr/sbin/amavisd line 2565. at (eval 69) line 511. (in reply to end of DATA
command))
 u...@domain.com



646DE25C002   216850 Fri Aug 21 16:12:36  u...@domain.com
(host 127.0.0.1[127.0.0.1] said: 451-4.5.0 Error in processing, id=09817-05,
virus_scan FAILED: virus_scan: ALL VIRUS SCANNERS FAILED: ClamAV-clamd
av-scanner FAILED: CODE(0x816e564) Too many retries to talk to
127.0.0.1:3310 (Can't connect to INET socket 127.0.0.1:3310: Connection
refused) at (eval 69) line 310. at (eval 69) line 511.; Avira AntiVir
av-scanner FAILED: /usr/sbin/antivir run_command (open pipe): Can't fork at
/usr/lib/perl5/5.8.8/i586-linux-thread-multi/IO/File.pm line 192. at
/usr/sbin/amavisd line 2565. at (eval 69) lin 451 4.5.0 e 511.;
ClamAV-clamscan av-scanner FAILED: /usr/bin/clamscan run_command (open
pipe): Can't fork at /usr/lib/perl5/5.8.8/i586-linux-thread-multi/IO/File.pm
line 192. at /usr/sbin/amavisd line 2565. at (eval 69) line 511. (in reply
to end of DATA command))
 u...@domain.com

Reg:Virtual Aliases forwarding

[Priyanka Tyagi]

I have setup a virtual alias at my Postfix mail server
as:u...@mydomain.com--->
u...@gmail.com

I have set up SPF record for 'mydomain.com' and passes SPF, in case
email originates from my postfix server. But SPF verification fails while it
forwards email using virtual aliases. For example, an email is sent by
someu...@example.org (SPF record is not set up at DNS) to
u...@mydomain.com(SPF setup), that forwards it to
u...@gmail.com (Checks for SPF from example.org domain and Fails). Is there
any way to tell postfix, so that it can put an envelope around , that can
say email is coming from mydomain.com and make it to check mydomain.com SPF
record ?

Let me know for any other details.

Thanks,
Priyanka

Re: virus_scan_failed

[J.P. Trosclair]

Oscar m Cruz wrote:

F003D25C001 2057 Fri Aug 21 16:10:58  u...@domain.com
(host 127.0.0.1[127.0.0.1] said: 451-4.5.0 Error in processing, id=08510-11,
virus_scan FAILED: virus_scan: ALL VIRUS SCANNERS FAILED: ClamAV-clamd
av-scanner FAILED: CODE(0x816e564) Too many retries to talk to
127.0.0.1:3310 (Can't connect to INET socket 127.0.0.1:3310: Connection
refused) at (eval 69) line 310. at (eval 69) line 511.; Avira AntiVir
av-scanner FAILED: /usr/sbin/antivir unexpected exit 200, output="error (not
enough memory available):  451-4.5.0  451-4.5.0 AntiVir / Linux Version
2.1.10-15 451-4.5.0 Copyright (c) 2007 by Avira GmbH. 451-4.5.0 All rights
reserved. 451 4.5.0 " at (eval 69) line 511.; ClamAV-clamscan av-scanner
FAILED: /usr/bin/clamscan run_command (open pipe): Can't fork at
/usr/lib/perl5/5.8.8/i586-linux-thread-multi/IO/File.pm line 192. at
/usr/sbin/amavisd line 2565. at (eval 69) line 511. (in reply to end of DATA
command))
  u...@domain.com




Notice the out of memory error above:
error (not enough memory available)

I've seen this happen on our server before when people send us emails 
with large attachments. Check your mailq (postqueue -p) output, look at 
the size column. You may have a message in there that's so large is 
crashing amavisd while it attempts to scan it. If this indeed the 
problem you may want to extract or delete it (postsuper & postcat) from 
the mail spool and look at setting a lower message_size_limit in your 
main.cf file.

Fwd: Reg:Virtual Aliases forwarding

[Priyanka Tyagi]

Hello List,
I have setup a virtual alias at my Postfix mail server as:
u...@mydomain.com ---> u...@gmail.com

I have set up SPF record for 'mydomain.com' and passes SPF, in case
email originates from my postfix server. But SPF verification fails while it
forwards email using virtual aliases. For example, an email is sent by
someu...@example.org (SPF record is not set up at DNS) to
u...@mydomain.com(SPF setup), that forwards it to
u...@gmail.com (Checks for SPF from example.org domain and Fails). Is there
any way to tell postfix, so that it can put an envelope around , that can
say email is coming from mydomain.com and make it to check mydomain.com SPF
record ?

Let me know for any other details.

Thanks,
Priyanka

Re: virus_scan_failed

[Oscar m Cruz]

On Fri, Aug 21, 2009 at 5:09 PM, J.P. Trosclair  wrote:

>
> Oscar m Cruz wrote:
>
>> F003D25C001 2057 Fri Aug 21 16:10:58  u...@domain.com
>> (host 127.0.0.1[127.0.0.1] said: 451-4.5.0 Error in processing,
>> id=08510-11,
>> virus_scan FAILED: virus_scan: ALL VIRUS SCANNERS FAILED: ClamAV-clamd
>> av-scanner FAILED: CODE(0x816e564) Too many retries to talk to
>> 127.0.0.1:3310 (Can't connect to INET socket 127.0.0.1:3310: Connection
>> refused) at (eval 69) line 310. at (eval 69) line 511.; Avira AntiVir
>> av-scanner FAILED: /usr/sbin/antivir unexpected exit 200, output="error
>> (not
>> enough memory available):  451-4.5.0  451-4.5.0 AntiVir / Linux Version
>> 2.1.10-15 451-4.5.0 Copyright (c) 2007 by Avira GmbH. 451-4.5.0 All rights
>> reserved. 451 4.5.0 " at (eval 69) line 511.; ClamAV-clamscan av-scanner
>> FAILED: /usr/bin/clamscan run_command (open pipe): Can't fork at
>> /usr/lib/perl5/5.8.8/i586-linux-thread-multi/IO/File.pm line 192. at
>> /usr/sbin/amavisd line 2565. at (eval 69) line 511. (in reply to end of
>> DATA
>> command))
>>  u...@domain.com
>>
>>
>
> Notice the out of memory error above:
>error (not enough memory available)
>
> I've seen this happen on our server before when people send us emails with
> large attachments. Check your mailq (postqueue -p) output, look at the size
> column. You may have a message in there that's so large is crashing amavisd
> while it attempts to scan it. If this indeed the problem you may want to
> extract or delete it (postsuper & postcat) from the mail spool and look at
> setting a lower message_size_limit in your main.cf file.
>
>
> Thanks for your fast answer


   from now on i'm gonna block all messages with large attachments get more
memory
   'cause i running a cron backups and this is get me slowly tooo


Regards