TLS certificate validation woes

[Bernhard Schmidt]

Hi,

I'm having an issue I can't quite understand at the moment.

We are part of a larger PKI infrastructure run by the german NREN, which 
is in the end rooted at the Deutsche Telekom.


- Deutsche Telekom Root CA 2
  - DFN-Verein PCA Global - G01
- LRZ-CA - G01   <-- this is ours
  - some client cert
- LMU-CA <-- this is ours
  - some client cert
- TUM-CA <-- this is ours
  - some client cert
- more weirdos
  - other weirdos

We want to allow relaying for all certificates issued by our CAs. Which 
I thought to be pretty easy


smtpd_tls_CApath = /etc/postfix-postout/certs
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_ask_ccert=yes

smtpd_recipient_restrictions = permit_tls_all_clientcerts, reject

lxmhs33:~ # ls -la /etc/postfix-postout/certs/
drwxr-xr-x 2 postmaster root 4096 20. Dez 08:46 .
drwxr-xr-x 4 postmaster root 4096 20. Dez 08:46 ..
lrwxrwxrwx 1 postmaster root   10 20. Dez 08:46 1ebd942d.0 -> TUM-CA.pem
lrwxrwxrwx 1 postmaster root   10 20. Dez 08:46 367d1e35.0 -> LRZ-CA.pem
lrwxrwxrwx 1 postmaster root   10 20. Dez 08:46 7ece279c.0 -> LMU-CA.pem
-rw-r--r-- 1 postmaster root 1826 24. Jul 2010  LMU-CA.pem
-rw-r--r-- 1 postmaster root 1850 24. Jul 2010  LRZ-CA.pem
-rw-r--r-- 1 postmaster root 1724 24. Jul 2010  TUM-CA.pem

Dec 20 08:59:59 lxmhs33 postfix-postout/smtpd[9870]: setting up TLS 
connection from postout.lrz.de[129.187.254.115]
Dec 20 08:59:59 lxmhs33 postfix-postout/smtpd[9870]: CA certificate 
verification failed for postout.lrz.de[129.187.254.115]: num=2:unable to 
get issuer certificate
Dec 20 08:59:59 lxmhs33 postfix-postout/smtpd[9870]: 
postout.lrz.de[129.187.254.115]: Untrusted: subject_CN=postout.lrz.de, 
issuer=LRZ-CA - G01, 
fingerprint=18:4B:79:22:82:67:DC:1E:60:35:41:F2:E4:A0:9F:1F
Dec 20 08:59:59 lxmhs33 postfix-postout/smtpd[9870]: Untrusted TLS 
connection established from postout.lrz.de[129.187.254.115]: TLSv1 with 
cipher DHE-RSA-AES256-SHA (256/256 bits)


It only works when I put the full chain (including Deutsche Telekom and 
DFN) into the certs-directory, but then permit_tls_all_clientcerts would 
be stupid.


Dec 20 08:47:37 lxmhs33 postfix-postout/smtpd[9870]: connect from 
postout.lrz.de[129.187.254.115]
Dec 20 08:47:37 lxmhs33 postfix-postout/smtpd[9870]: setting up TLS 
connection from postout.lrz.de[129.187.254.115]
Dec 20 08:47:37 lxmhs33 postfix-postout/smtpd[9870]: 
postout.lrz.de[129.187.254.115]: Trusted: subject_CN=postout.lrz.de, 
issuer=LRZ-CA - G01, fingerprint=18:4B:79:22:82:67:DC:1E:60:35:41:

F2:E4:A0:9F:1F
Dec 20 08:47:37 lxmhs33 postfix-postout/smtpd[9870]: Trusted TLS 
connection established from postout.lrz.de[129.187.254.115]: TLSv1 with 
cipher DHE-RSA-AES256-SHA (256/256 bits)



This is SLES11.1 with postfix 2.8.7, openssl 0.9.8h.

Any idea how to allow all certificates issued by specific Sub-CAs, 
without trusting everyone?


Bernhard

hotmail rate limit

[Helder Oliveira]

Hello,

Recently we start sending lots of emails to hotmail accounts and lots of them 
are in the active queue waiting for delivery for long time...
Some of our clients have  hotmail accounts for testing and are complaining 
about delivery times.

Our server has a good reputation but that is not enough to get a higher 
delivery rate.

Any tip for increase our delivery rate to hotmail accounts ?

A certification ?
An agreement with Microsoft ?

Thanks.

Re: TLS certificate validation woes

[lst_hoe02]

Zitat von Bernhard Schmidt :


Hi,

I'm having an issue I can't quite understand at the moment.

We are part of a larger PKI infrastructure run by the german NREN,  
which is in the end rooted at the Deutsche Telekom.


- Deutsche Telekom Root CA 2
  - DFN-Verein PCA Global - G01
- LRZ-CA - G01   <-- this is ours
  - some client cert
- LMU-CA <-- this is ours
  - some client cert
- TUM-CA <-- this is ours
  - some client cert
- more weirdos
  - other weirdos

We want to allow relaying for all certificates issued by our CAs.  
Which I thought to be pretty easy


smtpd_tls_CApath = /etc/postfix-postout/certs
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_ask_ccert=yes

smtpd_recipient_restrictions = permit_tls_all_clientcerts, reject

lxmhs33:~ # ls -la /etc/postfix-postout/certs/
drwxr-xr-x 2 postmaster root 4096 20. Dez 08:46 .
drwxr-xr-x 4 postmaster root 4096 20. Dez 08:46 ..
lrwxrwxrwx 1 postmaster root   10 20. Dez 08:46 1ebd942d.0 -> TUM-CA.pem
lrwxrwxrwx 1 postmaster root   10 20. Dez 08:46 367d1e35.0 -> LRZ-CA.pem
lrwxrwxrwx 1 postmaster root   10 20. Dez 08:46 7ece279c.0 -> LMU-CA.pem
-rw-r--r-- 1 postmaster root 1826 24. Jul 2010  LMU-CA.pem
-rw-r--r-- 1 postmaster root 1850 24. Jul 2010  LRZ-CA.pem
-rw-r--r-- 1 postmaster root 1724 24. Jul 2010  TUM-CA.pem

Dec 20 08:59:59 lxmhs33 postfix-postout/smtpd[9870]: setting up TLS  
connection from postout.lrz.de[129.187.254.115]
Dec 20 08:59:59 lxmhs33 postfix-postout/smtpd[9870]: CA certificate  
verification failed for postout.lrz.de[129.187.254.115]:  
num=2:unable to get issuer certificate
Dec 20 08:59:59 lxmhs33 postfix-postout/smtpd[9870]:  
postout.lrz.de[129.187.254.115]: Untrusted:  
subject_CN=postout.lrz.de, issuer=LRZ-CA - G01,  
fingerprint=18:4B:79:22:82:67:DC:1E:60:35:41:F2:E4:A0:9F:1F
Dec 20 08:59:59 lxmhs33 postfix-postout/smtpd[9870]: Untrusted TLS  
connection established from postout.lrz.de[129.187.254.115]: TLSv1  
with cipher DHE-RSA-AES256-SHA (256/256 bits)


It only works when I put the full chain (including Deutsche Telekom  
and DFN) into the certs-directory, but then  
permit_tls_all_clientcerts would be stupid.


Dec 20 08:47:37 lxmhs33 postfix-postout/smtpd[9870]: connect from  
postout.lrz.de[129.187.254.115]
Dec 20 08:47:37 lxmhs33 postfix-postout/smtpd[9870]: setting up TLS  
connection from postout.lrz.de[129.187.254.115]
Dec 20 08:47:37 lxmhs33 postfix-postout/smtpd[9870]:  
postout.lrz.de[129.187.254.115]: Trusted: subject_CN=postout.lrz.de,  
issuer=LRZ-CA - G01, fingerprint=18:4B:79:22:82:67:DC:1E:60:35:41:

F2:E4:A0:9F:1F
Dec 20 08:47:37 lxmhs33 postfix-postout/smtpd[9870]: Trusted TLS  
connection established from postout.lrz.de[129.187.254.115]: TLSv1  
with cipher DHE-RSA-AES256-SHA (256/256 bits)



This is SLES11.1 with postfix 2.8.7, openssl 0.9.8h.

Any idea how to allow all certificates issued by specific Sub-CAs,  
without trusting everyone?


As far as i understand you have to list the complete chain but only  
your sub-CA to get it working. So create a smtpd_tls_CAfile with the  
Telekom root and your sub-CA and nothing else. This would allow  
relaying for any certificate your sub-CA or the Telekom root CA has  
issued, but not for certificates issued by any sub-CA of the Telekom  
beside yours. Be aware that you should not do this on a public facing  
port 25.


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Vacation problems (again)

[Claudio Prono]

Il 19/12/2011 17.41, Wietse Venema ha scritto:
> Claudio Prono:
>> cat 1324286018.V811I1ea270M489235.mail | strace /usr/bin/vacation -t1
>> testmedia
>>
>> But no way, no results at all
> This will only send a reply if the message has testmedia
> in the To: or Cc: header.
>
>   Wietse
>
In fact, this is the header of the mail:

Return-Path: 
X-Original-To: testme...@domain.it
Delivered-To: testme...@domain.it

I have also tried to specify the alias, like

/usr/bin/vacation -a testme...@domain.it -t0 testmedia

But no results at all

Help!!!


> !DSPAM:1,4eef6ac2100348045416055!
>
>
>

-- 

Claudio Prono OPST
System Developer   
  Gsm: +39-349-54.33.258
@PSS Srl  Tel: +39-011-32.72.100
Via Santorelli, 15Fax: +39-011-32.46.497
10095 Grugliasco (TO) ITALY   http://atpss.net/disclaimer

PGP Key - http://keys.atpss.net/c_prono.asc

Re: Vacation problems (again)

[Ralf Hildebrandt]

* Claudio Prono :

> In fact, this is the header of the mail:
> 
> Return-Path: 
> X-Original-To: testme...@domain.it
> Delivered-To: testme...@domain.it

No To: or CC: header...
 
> I have also tried to specify the alias, like
> 
> /usr/bin/vacation -a testme...@domain.it -t0 testmedia
> 
> But no results at all
> 
> Help!!!
> 
> 
> > !DSPAM:1,4eef6ac2100348045416055!
> >
> >
> >
> 
> -- 
> 
> Claudio Prono OPST
> System Developer   
>   Gsm: +39-349-54.33.258
> @PSS Srl  Tel: +39-011-32.72.100
> Via Santorelli, 15Fax: +39-011-32.46.497
> 10095 Grugliasco (TO) ITALY   http://atpss.net/disclaimer
> 
> PGP Key - http://keys.atpss.net/c_prono.asc
> 
> 
> 
> 

-- 
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: hotmail rate limit

[Andrew Beverley]

On Tue, 2011-12-20 at 09:22 +, Helder Oliveira wrote:
> Hello,
> 
> Recently we start sending lots of emails to hotmail accounts and lots of them 
> are in the active queue waiting for delivery for long time...
> Some of our clients have  hotmail accounts for testing and are complaining 
> about delivery times.
> 
> Our server has a good reputation but that is not enough to get a higher 
> delivery rate.
> 
> Any tip for increase our delivery rate to hotmail accounts ?

As I'm sure others will tell you, Hotmail is one of the worst email
providers to deliver to.

Follow all the "best practice" is about the best you can do: remove
complainants quickly, subscribe to SNDS, use DKIM and SPF, use their
feedback loop and so on, as well as the things described here:

http://mail.live.com/mail/troubleshooting.aspx

> 
> A certification ?
> An agreement with Microsoft ?

Well you can use ReturnPath, but my limited experience to date has been
pretty poor, not to mention the extortionate fees they charge.

Andy

Re: TLS certificate validation woes

[Bernhard Schmidt]

Am 20.12.2011 10:24, schrieb lst_ho...@kwsoft.de:

Hello,

>> Any idea how to allow all certificates issued by specific Sub-CAs,
>> without trusting everyone?
> 
> As far as i understand you have to list the complete chain but only your
> sub-CA to get it working. So create a smtpd_tls_CAfile with the Telekom
> root and your sub-CA and nothing else. This would allow relaying for any
> certificate your sub-CA or the Telekom root CA has issued, but not for
> certificates issued by any sub-CA of the Telekom beside yours. Be aware
> that you should not do this on a public facing port 25.

Unfortunately no-go, the full chain needs to be in smtpd_tls_CApath,
otherwise I get the "unable to get issuer certificate". And doing that
would blow the purpose, since we would be an open relay for everyone
having a DTAG certificate.

Bernhard

Re: Vacation problems (again)

[Wietse Venema]

Useless uses of the "cat" command:
> cat 1324286018.V811I1ea270M489235.mail | strace /usr/bin/vacation -t1
> testmedia
>
> But no way, no results at all

Wietse:
> This will only send a reply if the message has testmedia
> in the To: or Cc: header.

Claudio Prono:
> In fact, this is the header of the mail:
> 
> Return-Path: 
> X-Original-To: testme...@domain.it
> Delivered-To: testme...@domain.it

This message has no testmedia in the To: or Cc: header, because
there are no To: or Cc: headers in the first place!

Wietse

problem with dspam

[fakessh @]

hello list
hello geek
hello guru
hello Fu

I have done tests on my smtp server used to  dspam.
after problems of housing road I realized that dspam removes Return-Path 
header

my emails are then intercepted as spam. 
I have not found a solution to my problem

please help me

i use a latest stable postfix release
with other tools

sincerely your


-- 
 http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x092164A7
 gpg --keyserver pgp.mit.edu --recv-key 092164A7

 http://urlshort.eu fakessh @
 http://gplus.to/sshfake
 http://gplus.to/sshswilting
 http://gplus.to/john.swilting


pgpCgw5pKqlj6.pgp
Description: PGP signature

Re: TLS certificate validation woes

[lst_hoe02]

Zitat von Bernhard Schmidt :


Am 20.12.2011 10:24, schrieb lst_ho...@kwsoft.de:

Hello,


Any idea how to allow all certificates issued by specific Sub-CAs,
without trusting everyone?


As far as i understand you have to list the complete chain but only your
sub-CA to get it working. So create a smtpd_tls_CAfile with the Telekom
root and your sub-CA and nothing else. This would allow relaying for any
certificate your sub-CA or the Telekom root CA has issued, but not for
certificates issued by any sub-CA of the Telekom beside yours. Be aware
that you should not do this on a public facing port 25.


Unfortunately no-go, the full chain needs to be in smtpd_tls_CApath,
otherwise I get the "unable to get issuer certificate". And doing that
would blow the purpose, since we would be an open relay for everyone
having a DTAG certificate.


To my knowledge you would *only* be an open relay for certificates  
issued directly by the Telekom root-CA and for certificates issued by  
your sub-CA, not for certificates issued by other Telekom sub-CAs not  
included in the file. Not sure if the Telekom root-CA is used to issue  
certificates anyway.

Viktor will correct me if i'm wrong ;-)

Regards

Andreas





smime.p7s
Description: S/MIME Cryptographic Signature

Re: problem with dspam

[Jerry]

On Tue, 20 Dec 2011 14:12:16 +0100
fakessh @ articulated:

> I have done tests on my smtp server used to  dspam.
> after problems of housing road I realized that dspam removes
> Return-Path header
> 
> my emails are then intercepted as spam. 
> I have not found a solution to my problem

Maybe this should be directed to the Dspam mailing lists:
.

-- 
Jerry ✌
postfix-u...@seibercom.net
_
TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail
TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html

Have you ever considered the irony in the fact that we celebrate
Christ's birthday every year by ignoring the fact that he would have
celebrated Hanukkah?

Re: TLS certificate validation woes

[Bernhard Schmidt]

Am 20.12.2011 14:30, schrieb lst_ho...@kwsoft.de:

Hi,

 Any idea how to allow all certificates issued by specific Sub-CAs,
 without trusting everyone?
>>>
>>> As far as i understand you have to list the complete chain but only your
>>> sub-CA to get it working. So create a smtpd_tls_CAfile with the Telekom
>>> root and your sub-CA and nothing else. This would allow relaying for any
>>> certificate your sub-CA or the Telekom root CA has issued, but not for
>>> certificates issued by any sub-CA of the Telekom beside yours. Be aware
>>> that you should not do this on a public facing port 25.
>>
>> Unfortunately no-go, the full chain needs to be in smtpd_tls_CApath,
>> otherwise I get the "unable to get issuer certificate". And doing that
>> would blow the purpose, since we would be an open relay for everyone
>> having a DTAG certificate.
> 
> To my knowledge you would *only* be an open relay for certificates
> issued directly by the Telekom root-CA and for certificates issued by
> your sub-CA, not for certificates issued by other Telekom sub-CAs not
> included in the file. Not sure if the Telekom root-CA is used to issue
> certificates anyway.
> Viktor will correct me if i'm wrong ;-)

I thought so, too. But apparently it is enough that the client supplies
the rest of the certificate chain. I tested that by only allowing the
Telekom Root-CA and having the client (openssl s_client) send the whole
chain including the intermediate CAs ... bam, Trusted.

Bernhard

Re: hotmail rate limit

[Helder Oliveira]

Hello Andrew,

thanks for the answer

On Dec 20, 2011, at 10:16 AM, Andrew Beverley wrote:

> On Tue, 2011-12-20 at 09:22 +, Helder Oliveira wrote:
>> Hello,
>> 
>> Recently we start sending lots of emails to hotmail accounts and lots of 
>> them are in the active queue waiting for delivery for long time...
>> Some of our clients have  hotmail accounts for testing and are complaining 
>> about delivery times.
>> 
>> Our server has a good reputation but that is not enough to get a higher 
>> delivery rate.
>> 
>> Any tip for increase our delivery rate to hotmail accounts ?
> 
> As I'm sure others will tell you, Hotmail is one of the worst email
> providers to deliver to.
> 
> Follow all the "best practice" is about the best you can do: remove
> complainants quickly, subscribe to SNDS, use DKIM and SPF, use their
> feedback loop and so on, as well as the things described here:
> 
I am following most of these guidelines
> http://mail.live.com/mail/troubleshooting.aspx
This link i didn't know, will read it!
> 
>> 
>> A certification ?
>> An agreement with Microsoft ?
> 
> Well you can use ReturnPath, but my limited experience to date has been
> pretty poor, not to mention the extortionate fees they charge.
In some searches i found ReturnPath services and yes it's a quite expensive, 
but could be a solution if hotmail destinations keeps growing…

Has anyone experience with ReturnPath that can share ? Is the paid money worth 
the results ?

Helder

> 
> Andy
> 
> 

Re: Table has changed; restarting messages not appearing

[Who Me]

> > On the older box, every day I see a message stating that
> > hash:/etc/postfix/relay_recipients has changed -- restarting.
> 
> This happens when an smtpd(8) notices a table change after processing
> a request and just before accepting another. A sufficiently idle
> system will not have any mail coming in during or shortly after
> the table change, and no message is logged since no smtpd(8) process
> services multiple requests in a time interval that spans the table
> change time.
> 
> > However, my new box does not log this message.
> 
> It is likely "sufficiently idle".

This is a plausible explanation. If the Postfix daemon receives no
new client connection, the Postfix daemon just terminates when the
idle time limit is reached, without ever having looked at the table
after it was changed.

    Wietse


Prior to yesterday afternoon, the only mails flowing through the new box were 
the test messages I sent.  Yesterday afternoon, I started to phase in the new 
box, effectively removing the sufficiently idle condition.

This morning after the daily update process ran, the messages were generated, 
confirming Viktor's and Wietse's assessment.  Thank you very much!  I really 
appreciate your insight.

postfix devnull mailbox

[Roberto Greiner]

Hi,

I'm trying to create a /dev/null mailbox, but didn't get much success 
following the recipe at 
http://www.serverwatch.com/columns/article.php/3844371/Forwarding-a-Postfix-Virtual-Alias-to-devnull.htm


What I did was following:
- Add a "blackhole" alias in /etc/aliases (blackhole: /dev/null), an ran 
"newaliases" to validate it.

- Added the following in mysql_virtual_alias_maps.cf:
  no-reply@ = blackhole
- Ran:
  postmap /usr/local/etc/postfix/mysql_virtual_alias_maps.cf (it's a 
FreeBSD platform)

- Restarted Postfix.

Sending an email to no-reply@ got me the following error 
message in /var/log/maillog:
NOQUEUE: reject: RCPT from unknown[]: 450 4.1.1 
>: Recipient address rejected: User unknown in 
virtual mailbox table; from=<> to=domain>> proto=ESMTP helo=<[]>


I tried adding the same entry from mysql_virtual_alias_maps.cf into 
mysql_virtual_mailbox_maps.cf, but no success either. Also, just in 
case, the same page above mentions that adding a valid user for the 
aliases might be necessary. Didn't help either.


Any ideas would be welcome.

Thanks

Roberto

PS: My setup is the following:
FreeBSD 7.2 machine
Postfix 2.8.2
Postfixadmin 2.3.2


main.cf has at the end the following entries:
## MySQL access
virtual_alias_maps = 
mysql:/usr/local/etc/postfix/mysql_virtual_alias_maps.cf

virtual_gid_maps = static:125
virtual_mailbox_base = /var/mail
virtual_mailbox_domains = 
mysql:/usr/local/etc/postfix/mysql_virtual_domains_maps.cf

virtual_mailbox_limit = 104857600
virtual_mailbox_maps = 
mysql:/usr/local/etc/postfix/mysql_virtual_mailbox_maps.cf

virtual_minimum_uid = 125
virtual_transport = virtual
#virtual_transport = maildrop
virtual_uid_maps = static:125
# Additional for quota support
virtual_create_maildirsize = yes
virtual_mailbox_extended = yes
virtual_mailbox_limit_maps = 
mysql:/usr/local/etc/postfix/mysql_virtual_mailbox_limit_maps.cf

virtual_mailbox_limit_override = yes
virtual_maildir_limit_message = Desculpe, tamanho da caixa postal 
excedido, tente mais tarde! Sorry, mailbox size exceeded, try later!

virtual_overquota_bounce = yes


--
  -
Marcos Roberto Greiner

   Os otimistas acham que estamos no melhor dos mundos
Os pessimistas tem medo de que isto seja verdade
  James Branch Cabell
  -

Re: postfix devnull mailbox

[Patrick Ben Koetter]

* Roberto Greiner :
> I'm trying to create a /dev/null mailbox, but didn't get much
> success following the recipe at 
> http://www.serverwatch.com/columns/article.php/3844371/Forwarding-a-Postfix-Virtual-Alias-to-devnull.htm
> 
> What I did was following:
> - Add a "blackhole" alias in /etc/aliases (blackhole: /dev/null), an
> ran "newaliases" to validate it.
> - Added the following in mysql_virtual_alias_maps.cf:
>   no-reply@ = blackhole
> - Ran:
>   postmap /usr/local/etc/postfix/mysql_virtual_alias_maps.cf (it's a
> FreeBSD platform)
> - Restarted Postfix.

send messages to the discard service.

p@rick



> 
> Sending an email to no-reply@ got me the following error
> message in /var/log/maillog:
> NOQUEUE: reject: RCPT from unknown[]: 450 4.1.1
> >: Recipient address rejected: User unknown in
> virtual mailbox table; from=<> to= domain>> proto=ESMTP helo=<[]>
> 
> I tried adding the same entry from mysql_virtual_alias_maps.cf into
> mysql_virtual_mailbox_maps.cf, but no success either. Also, just in
> case, the same page above mentions that adding a valid user for the
> aliases might be necessary. Didn't help either.
> 
> Any ideas would be welcome.
> 
> Thanks
> 
> Roberto
> 
> PS: My setup is the following:
> FreeBSD 7.2 machine
> Postfix 2.8.2
> Postfixadmin 2.3.2
> 
> 
> main.cf has at the end the following entries:
> ## MySQL access
> virtual_alias_maps =
> mysql:/usr/local/etc/postfix/mysql_virtual_alias_maps.cf
> virtual_gid_maps = static:125
> virtual_mailbox_base = /var/mail
> virtual_mailbox_domains =
> mysql:/usr/local/etc/postfix/mysql_virtual_domains_maps.cf
> virtual_mailbox_limit = 104857600
> virtual_mailbox_maps =
> mysql:/usr/local/etc/postfix/mysql_virtual_mailbox_maps.cf
> virtual_minimum_uid = 125
> virtual_transport = virtual
> #virtual_transport = maildrop
> virtual_uid_maps = static:125
> # Additional for quota support
> virtual_create_maildirsize = yes
> virtual_mailbox_extended = yes
> virtual_mailbox_limit_maps =
> mysql:/usr/local/etc/postfix/mysql_virtual_mailbox_limit_maps.cf
> virtual_mailbox_limit_override = yes
> virtual_maildir_limit_message = Desculpe, tamanho da caixa postal
> excedido, tente mais tarde! Sorry, mailbox size exceeded, try later!
> virtual_overquota_bounce = yes
> 
> 
> -- 
>   -
> Marcos Roberto Greiner
> 
>Os otimistas acham que estamos no melhor dos mundos
> Os pessimistas tem medo de que isto seja verdade
>   James Branch Cabell
>   -
> 

-- 
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: postfix devnull mailbox

[/dev/rob0]

On Tuesday 20 December 2011 12:35:40 Roberto Greiner wrote:
> I'm trying to create a /dev/null mailbox, but didn't get much
> success following the recipe at
> http://www.serverwatch.com/columns/article.php/3844371/Forwarding-a
> -Postfix-Virtual-Alias-to-devnull.htm
> 
> What I did was following:
> - Add a "blackhole" alias in /etc/aliases (blackhole: /dev/null),
> an ran "newaliases" to validate it.

Okay so far, except that the concept of discarding mail is generally 
not a good idea. Why do you want to do that? What would be wrong with 
rejecting that address?

That said, as P@rick points out, we do have a discard(8) delivery 
agent which can be directed to using transport(5) maps.

http://www.postfix.org/transport.5.html
http://www.postfix.org/discard.8.html
http://www.postfix.org/postconf.5.html#transport_maps

> - Added the following in mysql_virtual_alias_maps.cf:
>no-reply@ = blackhole

This sounds wrong. Furthermore, it is not a good idea to use a bare 
username in place of a full email address. You should have used 
"blackh...@some.domain.listed.in.mydestination".

See virtual(5) for the format of virtual_alias_maps lookup keys and 
results. See mysql_table(5) for the details of setting up a query in 
Postfix. See MySQL documentation for information about setting up a 
database in mysql.

http://www.postfix.org/virtual.5.html
http://www.postfix.org/mysql_table.5.html
http://www.mysql.com/

> - Ran:
>postmap /usr/local/etc/postfix/mysql_virtual_alias_maps.cf (it's

You do not compile a query file with postmap. But, you can use postmap 
to test your lookups.

http://www.postfix.org/postmap.1.html

> a FreeBSD platform)
> - Restarted Postfix.

Not necessary.

> Sending an email to no-reply@ got me the following error
> message in /var/log/maillog:
> NOQUEUE: reject: RCPT from unknown[]: 450 4.1.1
> >: Recipient address rejected: User unknown in
> virtual mailbox table; from=<> to= domain>> proto=ESMTP helo=<[]>

The munged-out domain is in virtual_mailbox_domains, but the address 
no-reply@ is not listed in virtual_mailbox_maps.

> I tried adding the same entry from mysql_virtual_alias_maps.cf into
> mysql_virtual_mailbox_maps.cf, but no success either. Also, just in

Those sound like they are database queries, not actual map files.

> case, the same page above mentions that adding a valid user for the
> aliases might be necessary. Didn't help either.
> 
> Any ideas would be welcome.

If this doesn't help, http://www.postfix.org/DEBUG_README.html#mail 
tells you how to post here such that you can get more useful answers. 
Also, it might be difficult to figure out a mail routing issue where 
you have munged the domains.

> PS: My setup is the following:
> FreeBSD 7.2 machine
> Postfix 2.8.2
> Postfixadmin 2.3.2
> 
> 
> main.cf has at the end the following entries:
> ## MySQL access
> virtual_alias_maps =
> mysql:/usr/local/etc/postfix/mysql_virtual_alias_maps.cf

Yup, if this is right, it's a query file.

> virtual_gid_maps = static:125
> virtual_mailbox_base = /var/mail
> virtual_mailbox_domains =
> mysql:/usr/local/etc/postfix/mysql_virtual_domains_maps.cf
> virtual_mailbox_limit = 104857600
> virtual_mailbox_maps =
> mysql:/usr/local/etc/postfix/mysql_virtual_mailbox_maps.cf
> virtual_minimum_uid = 125
> virtual_transport = virtual
> #virtual_transport = maildrop
> virtual_uid_maps = static:125
> # Additional for quota support
> virtual_create_maildirsize = yes
> virtual_mailbox_extended = yes
> virtual_mailbox_limit_maps =
> mysql:/usr/local/etc/postfix/mysql_virtual_mailbox_limit_maps.cf
> virtual_mailbox_limit_override = yes
> virtual_maildir_limit_message = Desculpe, tamanho da caixa postal
> excedido, tente mais tarde! Sorry, mailbox size exceeded, try
> later!
> virtual_overquota_bounce = yes
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

Re: postfix devnull mailbox

[Dennis Carr]

On Tue, 20 Dec 2011, /dev/rob0 wrote:


Why do you want to do that? What would be wrong with
rejecting that address?


/dev/null is just the proper repository to recycle bits. We don't want to 
run out. =^_^=


In all seriousness, I guess it depends on who you ask.  For the original 
poster's case, it's going to a "noreply" address, and I've seen cases 
where nore...@foo.bar is simply eaten, more often than not, rather than 
rejected. Besides, as far as I'm concerned, it does serve as an extra use: 
messages to noreply or similar black hole addresses can serve as a 
receptacle for flames.  Some yutz can decide he's going to e a jerk and 
flame somebody that doesn't actually exist - s/he feels good about 
{him,her}self in theory, and the only thing tat sees the message is 
postfix, which just relegates it to nothingness - leaving it to tie up 
storage resources only for as long as it takes for Postfix to chew on it.


 -Dennis
(who couldn't resist a bit if silliness and bounces null@ and some other 
addresses to /dev/null himself)

Re: postfix devnull mailbox

[Peter]

On 21/12/11 10:11, Dennis Carr wrote:
> In all seriousness, I guess it depends on who you ask.  For the original
> poster's case, it's going to a "noreply" address, and I've seen cases
> where nore...@foo.bar is simply eaten, more often than not, rather than
> rejected. Besides, as far as I'm concerned, it does serve as an extra
> use: messages to noreply or similar black hole addresses can serve as a
> receptacle for flames.  Some yutz can decide he's going to e a jerk and
> flame somebody that doesn't actually exist - s/he feels good about
> {him,her}self in theory,

...which is exactly why you should never drop email like that.  You are
advocating for tricking a sender into thinking that his email was
received when it was not.  The number of times of your scenario is going
to be far outweighed by the number of emails that contain important
information.  Even in your case it is likely that the ranting sender
wants to be removed from your mailing list and to make him think you've
received this email but not removed him from the list turns you into a
spammer.

There is very rarely a good reason to drop email.


Peter

Re: postfix devnull mailbox

[Reindl Harald]

Am 21.12.2011 00:47, schrieb Peter:
> On 21/12/11 10:11, Dennis Carr wrote:
>> In all seriousness, I guess it depends on who you ask.  For the original
>> poster's case, it's going to a "noreply" address, and I've seen cases
>> where nore...@foo.bar is simply eaten, more often than not, rather than
>> rejected. Besides, as far as I'm concerned, it does serve as an extra
>> use: messages to noreply or similar black hole addresses can serve as a
>> receptacle for flames.  Some yutz can decide he's going to e a jerk and
>> flame somebody that doesn't actually exist - s/he feels good about
>> {him,her}self in theory,
> 
> ...which is exactly why you should never drop email like that.  You are
> advocating for tricking a sender into thinking that his email was
> received when it was not.  The number of times of your scenario is going
> to be far outweighed by the number of emails that contain important
> information.  Even in your case it is likely that the ranting sender
> wants to be removed from your mailing list and to make him think you've
> received this email but not removed him from the list turns you into a
> spammer.

so why does he not use the reply-button and what is he thinking does
"nore...@mail.tld" mean? if you do not read the noreply-address it
is the same as drop the messages, the only difference is on the storage



signature.asc
Description: OpenPGP digital signature

Re: postfix devnull mailbox

[Peter]

On 21/12/11 13:21, Reindl Harald wrote:
> so why does he not use the reply-button and what is he thinking does
> "nore...@mail.tld" mean? if you do not read the noreply-address it
> is the same as drop the messages, the only difference is on the storage

I am not excusing the sender's actions, I am simply stating that if you
are going to accept an email for delivery then you should deliver it, to
do otherwise gives a false impression to the sender.


Peter

Re: TLS certificate validation woes

[Viktor Dukhovni]

On Tue, Dec 20, 2011 at 10:24:04AM +0100, lst_ho...@kwsoft.de wrote:

> As far as I understand you have to list the complete chain but only
> your sub-CA to get it working.

This is not the case:

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

Allow the remote SMTP client request if the client certificate
passes trust chain verification. Useful with private-label
CAs that only issue certificates to trusted clients (and
not otherwise).

Trust chain verification succeeds when the *root* CA is trusted, and
the client correctly provides the requisite trust chain, or perhaps
the local configuration provides the missing intermediate CA certs,
but this is neither expected nor required.

Postfix client certs are typically trusted by fingerprint (if you
issued the certs, you should have copies of them, so there is no
benefit from any of the CA authority bits, just list the cert
fingerprints in an access list).

If you want to trust some CA to imply relay rights rather than just
an identity mapping (this is unwise I think, it is not a CAs job
to entitle the bearer to any services, rather the CA just asserts
a key to identity binding) then it needs to be a dedicated private
root CA that just issues "right to relay email" certs.

-- 
Viktor.

Re: warning: problem talking to service private/scache: Operation timed out

[Sahil Tandon]

On Thu, 2011-12-15 at 19:26:39 -0500, Wietse Venema wrote:

> In the scache client, the file descriptor sending operation is
> always preceeded and followed by a data read. For this reason we
> can't be triggering the same bug that postscreen triggered, but
> maybe there is another bug in FreeBSD file descriptor passing code.

OK, thanks for the context.

-- 
Sahil Tandon

Re: postfix devnull mailbox

[Reindl Harald]

Am 21.12.2011 01:29, schrieb Peter:
> On 21/12/11 13:21, Reindl Harald wrote:
>> so why does he not use the reply-button and what is he thinking does
>> "nore...@mail.tld" mean? if you do not read the noreply-address it
>> is the same as drop the messages, the only difference is on the storage
> 
> I am not excusing the sender's actions, I am simply stating that if you
> are going to accept an email for delivery then you should deliver it, to
> do otherwise gives a false impression to the sender.

but this is not solveable in any way

if you reject mails to "nore...@yourdomain.com" you will fail
sender-verify everywhere



signature.asc
Description: OpenPGP digital signature

Re: postfix devnull mailbox

[Stan Hoeppner]

On 12/20/2011 6:29 PM, Peter wrote:
> On 21/12/11 13:21, Reindl Harald wrote:
>> so why does he not use the reply-button and what is he thinking does
>> "nore...@mail.tld" mean? if you do not read the noreply-address it
>> is the same as drop the messages, the only difference is on the storage
> 
> I am not excusing the sender's actions, I am simply stating that if you
> are going to accept an email for delivery then you should deliver it, to
> do otherwise gives a false impression to the sender.

The act of delivery to a mailbox does not guarantee the message will be
read by a human, nor replied to, ever.  Thus there is zero practical
difference, from the sender's POV, in this case, between delivering to
/dev/null and to a mailbox whose contents are never read, but deleted
each night via a cron job.  As someone else stated, the only difference
is disk space usage.

To further shoot your argument down, many postqueue Spamassassin
implementations at the MDA level discard spam before final delivery
millions of times a day around the world.  Using your definitions, doing
this is illegal/wrong as well.

Yes, in a perfect world it's best to reject any mail at smtpd which you
know you will not deliver.  But we don't live in a perfect world.  Thus,
now and then, 'imperfect' solutions must be used for certain
classes/types of problems.

-- 
Stan

Re: postfix devnull mailbox

[Peter]

On 21/12/11 16:01, Stan Hoeppner wrote:
> The act of delivery to a mailbox does not guarantee the message will be
> read by a human, nor replied to, ever.  Thus there is zero practical
> difference, from the sender's POV, in this case, between delivering to
> /dev/null and to a mailbox whose contents are never read, but deleted
> each night via a cron job.  As someone else stated, the only difference
> is disk space usage.

Note that I never said that the only solution is to deliver the email.
What I said was that if the email is accepted for delivery it should be
delivered.  In this case the email should be rejected.

> To further shoot your argument down, many postqueue Spamassassin
> implementations at the MDA level discard spam before final delivery
> millions of times a day around the world.  Using your definitions, doing
> this is illegal/wrong as well.

Yes, this is wrong, just because a lot of people configure SA to drop
email does not make the practice correct.

There is one case where I will drop email and that is if it contains a
virus.  In the case of SPAM the best solution is to deliver the email to
the user's SPAM folder (that is if it didn't get rejected by postscreen
already).

> Yes, in a perfect world it's best to reject any mail at smtpd which you
> know you will not deliver.  But we don't live in a perfect world.  Thus,
> now and then, 'imperfect' solutions must be used for certain
> classes/types of problems.

Yes in a perfect world everyone would follow RFCs and do the right thing
with email.  Just because the world is not perfect is not an excuse for
you to make it worse.


Peter

Re: postfix devnull mailbox

[Peter]

On 21/12/11 15:19, Reindl Harald wrote:
> 
> 
> Am 21.12.2011 01:29, schrieb Peter:
>> On 21/12/11 13:21, Reindl Harald wrote:
>>> so why does he not use the reply-button and what is he thinking does
>>> "nore...@mail.tld" mean? if you do not read the noreply-address it
>>> is the same as drop the messages, the only difference is on the storage
>>
>> I am not excusing the sender's actions, I am simply stating that if you
>> are going to accept an email for delivery then you should deliver it, to
>> do otherwise gives a false impression to the sender.
> 
> but this is not solveable in any way
> 
> if you reject mails to "nore...@yourdomain.com" you will fail
> sender-verify everywhere

You can reject emails but still allow the address to pass the VRFY
command, or better yet, just disable the VRFY command all-together which
has other benefits.


Peter

Envelope sender address authorization and command line tool "mail"

[Bartłomiej Romański]

Hi

Is there a way to restrict the "From" field for messages sent with the
command line tool "mail"?

For messages sent with SMTP we can simply do this:

http://www.postfix.org/SASL_README.html#server_sasl_authz_envelope

and it works fine, but users can execute:

mail t...@test.test -a 'From: some-other-u...@some-other-domain.com'

or:

cat mail.txt | /usr/sbin/sendmail -t t...@test.test

where mail.txt contains:

From: some-other-u...@some-other-domain.com
Subject: ble, ble, ble...

ble, ble, ble...

...and the message will be delivered with fake 'From' address. I've
already set "mynetworks" to the empty list, but it works only for
messages sent with SMTP not for local mail send with "mail" or
"sendmail".

Any ideas?

Thanks,
Bartek