Re: Create additional sub-folders postfix/courier

[postfix]

And a last betterer/simpler way to do it.

 SELECT 
if(INSTR(maildir,'+'),concat(left(maildir,instr(maildir,'+')-1),'/Maildir/.',right(maildir,length(maildir)-instr(maildir,'+'))),CONCAT(maildir,'Maildir/')) 
from mailbox where username ='%s' and active='1'

Re: Create additional sub-folders postfix/courier

[postfix]

At 01:31 AM 2/11/2009, post...@corwyn.net wrote:

At 01:05 AM 2/11/2009, Victor Duchovni wrote:

On Wed, Feb 11, 2009 at 12:55:31AM -0500, post...@corwyn.net wrote:
This is a bad idea. You are allowing external parties to construct
mailbox filenames on your system. Potential for various directory pathname
injection attacks:

user+./../../not/where/you/exp...@example.com

You must specifically designate which folders are addressible in this way,
or at least limit the character-set of acceptable extensions.


Now it uses the data already in the table. Better?

select 
if(INSTR(maildir,'+'),concat(left(maildir,instr(maildir,'+')-1),'/Maildir/.',right(substring_index(maildir,'/',2),length(substring_index(maildir,'/',2))-instr(substring_index(maildir,'/',2),'+' 
)),'/'),CONCAT(maildir,'Maildir/')) from mailbox where username='%s' 
and active='1'


Rick

Re: Create additional sub-folders postfix/courier

[postfix]

At 01:05 AM 2/11/2009, Victor Duchovni wrote:

On Wed, Feb 11, 2009 at 12:55:31AM -0500, post...@corwyn.net wrote:
This is a bad idea. You are allowing external parties to construct
mailbox filenames on your system. Potential for various directory pathname
injection attacks:

user+./../../not/where/you/exp...@example.com

You must specifically designate which folders are addressible in this way,
or at least limit the character-set of acceptable extensions.



Grr, a very valid point. I'll try to put something together that only 
uses the maildir that's in the database. Better anyway because then 
it will work from when the account is created instead of having to 
manually tweak the maildir (which is what I did this time).  More to come ...


Rick

Re: Create additional sub-folders postfix/courier

[Victor Duchovni]

On Wed, Feb 11, 2009 at 12:55:31AM -0500, post...@corwyn.net wrote:

> At 11:04 PM 2/10/2009, post...@corwyn.net wrote:
>> At 05:24 PM 2/10/2009, mouss wrote:
>> While I can readily create a user  b...@example.com, who has a default 
>> maildir location for that sql of 'example.com/bob/'  I can't quite figure 
>> out how to change the SQL to get the folder for bob+t...@example.com to 
>> return:
>>
>> 'example.com/bob/Maildir/.test' without breaking everything else?
>
> To answer my own question (more correctly)
> SELECT 
> CONCAT(maildir,'Maildir/',if(INSTR(username,'+'),'.',''),if(INSTR(username,'+'),MID(username,INSTR(username,'+')+1,INSTR(username,'@')-INSTR(username,'+')-1),''))
>  
> FROM mailbox

This is a bad idea. You are allowing external parties to construct
mailbox filenames on your system. Potential for various directory pathname
injection attacks:

user+./../../not/where/you/exp...@example.com

You must specifically designate which folders are addressible in this way,
or at least limit the character-set of acceptable extensions.

-- 
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: Create additional sub-folders postfix/courier

[postfix]

At 11:04 PM 2/10/2009, post...@corwyn.net wrote:

At 05:24 PM 2/10/2009, mouss wrote:
While I can readily create a user  b...@example.com, who has a 
default maildir location for that sql of 'example.com/bob/'  I can't 
quite figure out how to change the SQL to get the folder for 
bob+t...@example.com to return:


'example.com/bob/Maildir/.test' without breaking everything else?


To answer my own question (more correctly)
SELECT 
CONCAT(maildir,'Maildir/',if(INSTR(username,'+'),'.',''),if(INSTR(username,'+'),MID(username,INSTR(username,'+')+1,INSTR(username,'@')-INSTR(username,'+')-1),'')) 
FROM mailbox



Rick

Re: Redirect all mail from one domain to the same u...@otherdomain?

[Jeff Weinberger]

jeff_homeip a écrit :

[snip]
 that creates some complications...and might be too difficult



a script and a Makefile... or sql as below:

 but why not use wildcard virtual aliases? You noted below that they  
break

recipient
 validations. Do you mean that smtp_recipient_restrictions won't  
work? at all

or parts?



no, it's not about smtpd restrictions. it's about rejecting mail to
invalid recipients.

 Wildcard virtual aliases seems like the best waybut I want to  
understand

the implications
 on everything esle before I proceed.

 Thanks!


 The reason is that if you use
 @example.com @example.org
 then this breaks recipient validation: smtpd will accept
 anything^example.com, then at delivery time, the user won't be  
found and
 a bounce will be generated. in short, you become a source of  
backscatter
 (you send bounces to innocents whose addresses were forged by  
spammers)


 Unless I don't bounce unknown addresses




and you'd do what with these? if you have a catchall, it's ok. but you
should not discard mail (people do mistype addresses some time, so  
it's

not just spammers trying invalid addresses).


I use a catchall for some domains instead of rejecting unknown
recipients, for exactly that reason. I find about 2-3% of catchall mai
is user errors (like mis-spellings) rather than spam.

So in this case, I can use a wildcard catchall.

So an alias map of:

@domain1.tld   @domain2.tld

will produce the expected result of anyuser @ domain1.tld being
redirected to the same user (anyuser) @ domain2.tld?

That would be by far the easiest to do in my setup.




you can generate the individual mappings with a script.

alternatively,

if you store users in sql, you can use sql statements to generate

these
"on the fly". examples have been posted multiple times to the list  
(a

long time ago, that said, but you may be lucky...).




it would be something like:

if (%d=3D'domain1.com') then select %...@domain2..com from

virtual_alias else select alias

from virtual_alias where address=3D%s

(that's not quite right in the syntax, but you get the idea). This

wont' work, as I'd have to
write a special select clause for each domain I want to work this  
way.





assuming you have a User table containing valid email addresses and a
AliasDomain table containing (alias, destination) domains:

select User.user from AliasDomain, User where
AliasDomain.alias =3D '%d'
AND
User.user =3D CONCAT('%u', '@', AliasDomain.destination)

you can avoid the CONCAT inside the "search" if you split your  
emails in

(user, domain) columns like I do. in which case, the query becomes

select CONCAT(User.user, '@', User.domain) where
AliasDomain.alias =3D '%d'
AND
AliasDomain.destination =3D User.domain
AND
User.user =3D '%u'


of course, this works for "1 depth" alias domains (it doesn't work if
example.net is an alis for example.org which is in turn an alias of
example.com). but this should be enough in most cases.


This is helpful, but I still need the query to take all the other
alias domains into account. So, I need the IF condition, or a second  
map.


Thank you for your help...it's informative as always!

if the wildcard alias will produce the result I need then this is
resolved.





--

Jeff Weinberger
http://disruptivemarketing.jeffweinberger.com

Re: Create additional sub-folders postfix/courier

[postfix]

At 05:24 PM 2/10/2009, mouss wrote:

You can create "dummy" mailboxes that use the folders as their maildir.
for example:
joe+s...@example.com/some/path/example.com/joe/Maildir/.Spam/
then tell amavisd-new to add the "+spam" extension to mail tagged as spam.

This may or may not be easy depending on your setup.

This approach can work for any folder as follows. you populate
virtual_mailbox_maps with things like:

joe+fol...@example.com  /some/path/example.com/joe/Maildir/.folder



Man this is clever. Clever enough I'm having a hard time wrapping my 
head around it.


My sql for determining the mail folder for virtual_mailbox_maps is:
query= SELECT CONCAT(maildir,'Maildir/') FROM mailbox WHERE 
username='%s' AND active = '1'


While I can readily create a user  b...@example.com, who has a default 
maildir location for that sql of 'example.com/bob/'  I can't quite 
figure out how to change the SQL to get the folder for 
bob+t...@example.com to return:


'example.com/bob/Maildir/.test' without breaking everything else?

Rick

Re: [Fwd: Re: Fwd: Re: postfix, dovecot auth and rip/lip]

[Nate]

At 06:45 PM 2/10/2009, post...@corwyn.net wrote:

At 07:22 PM 2/10/2009, Nate wrote:

At 03:53 PM 3/18/2008, you wrote:

Wietse Venema wrote:
We're using SMTP AUTH in postfix, querying the dovecot auth socket 
which works well; however, in our virtual hosted environment it 
requires that customers login with their full email 
address.  Great in practice, but impractical when a hosting 
account moves over and has 300, or 3000 subscribers all using 
username only authentication.  In that case, with dovecot 
currently the query is written to compare full email


Couldn't you just change the sql query to compare the login passed 
in to the left side of the User ID/email address?


Rick



Unfortunately not, because the server runs multiple domains, so if it 
compared r...@% for instance in the query it would likely return 
multiple results, and dovecot will reject on multiple results, as it should.


- Nate 

Re: Connection Refused

[Sahil Tandon]

On Tue, 10 Feb 2009, Jason Wohlford wrote:

> Is there a way to notify me (i.e. postmaster) when my smtpd_proxy_filter 
> fails? I see in the logs where a "warning: connect to proxy service 
> 127.0.0.1:10024: Connection refused" occurs. How do I get a message sent 
> to me when this happens?

Try monit, or some log monitoring service that notifies you when service X 
fails.  But if service X is required for root to send you email, you'll have
to figure out a way around that.

-- 
Sahil Tandon 

Re: [Fwd: Re: Fwd: Re: postfix, dovecot auth and rip/lip]

[postfix]

At 07:22 PM 2/10/2009, Nate wrote:

At 03:53 PM 3/18/2008, you wrote:

Wietse Venema wrote:
We're using SMTP AUTH in postfix, querying the dovecot auth socket 
which works well; however, in our virtual hosted environment it 
requires that customers login with their full email address.  Great 
in practice, but impractical when a hosting account moves over and 
has 300, or 3000 subscribers all using username only 
authentication.  In that case, with dovecot currently the query is 
written to compare full email


Couldn't you just change the sql query to compare the login passed in 
to the left side of the User ID/email address?


Rick

Connection Refused

[Jason Wohlford]

Is there a way to notify me (i.e. postmaster) when my  
smtpd_proxy_filter fails? I see in the logs where a "warning: connect  
to proxy service 127.0.0.1:10024: Connection refused" occurs. How do I  
get a message sent to me when this happens?


--
Jason Wohlford

Re: Whitelist assistance with dnswl.org

[David Cottle]

Sent from my iPhone

On 11/02/2009, at 13:04, Noel Jones  wrote:


David Cottle wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I have my own 'static' whitelisting working in  
smtpd_client_restrictions

I would also like to use the whitelisting in dnswl.org to override
blacklisting
I don't have much mail traffic, so rather than rsyncing, I want to do
this using normal DNS lookups.
The instructions say to:


Postfix doesn't have a DNS whitelist feature, so you will need to  
follow the rsync + access map instructions.


--
Noel Jones


Hi Noel,

Thanks for that!

Last question, where should I do it then?

As suggested or in my existing RBL right after my whitelist and check_  
tests?


Thanks!

Re: [Fwd: Re: Fwd: Re: postfix, dovecot auth and rip/lip]

[Wietse Venema]

Nate:
> I noticed somebody wrote a patch for postfix-2.3.8.  I'm not a C 
> programmer myself, so I'm not sure of it's quality or if this code 
> could be used or committed to the postfix source tree.  Found at 
> http://preview.tinyurl.com/b87z44

You are welcome to apply this patch, but it will not work correctly
with connections that use the XCLIENT command.

If it works for you then go for it.  I cannot release Postfix with
silly "do not use it here" disclaimers in the XCLIENT documentation
and it is too late for structural code changes in Postfix 2.6.

Wietse

Re: Whitelist assistance with dnswl.org

[Noel Jones]

David Cottle wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I have my own 'static' whitelisting working in smtpd_client_restrictions

I would also like to use the whitelisting in dnswl.org to override
blacklisting

I don't have much mail traffic, so rather than rsyncing, I want to do
this using normal DNS lookups.

The instructions say to:


Postfix doesn't have a DNS whitelist feature, so you will need 
to follow the rsync + access map instructions.


--
Noel Jones

Re: [Fwd: Re: Fwd: Re: postfix, dovecot auth and rip/lip]

[Nate]

At 03:53 PM 3/18/2008, you wrote:

Wietse Venema wrote:
> There is no reason why this can't be implemented, but I want to
> avoid chaos in Postfix. So I don't want to keep adding more and
> more ad-hoc parameters to the Postfix-to-SASL library interface.
>
> This interface is also used by Cyrus SASL and may be used for other
> non-Cyrus implementations later. Changes to this API should be
> carefully designed.

Alex:
> I understand. It's have to wait unless it can really be necessary for
> more users and could be part of 'official' API.
> I wrote about it as "for not near future" wish. As for 'some day'.

In the case of the Postfix TLS library we ran into a similar problem,
when APIs kept growing with more and more function call parameters.

To maintain some level of elegance I introduced function calls with
named parameters:

TLS_SERVER_START(...stuff...,
 ctx = smtpd_tls_ctx,
 stream = state->client,
 log_level = var_smtpd_tls_loglevel,
 timeout = var_smtpd_starttls_tmout,
 ...more stuff...);

C does not have named parameter lists, but they can be emulated
with a little bit of C preprocessor fu. This looks like a usable
approach for extending the Postfix-to-SASL library interface.

Another approach is using a call-back function that queries Postfix
for specific information. This is the approach taken with the
Postfix Milter client, but it is probably over-kill for SASL.

Wietse


I'll throw my request in for this feature to be prioritized.  We're 
using SMTP AUTH in postfix, querying the dovecot auth socket which 
works well; however, in our virtual hosted environment it requires 
that customers login with their full email address.  Great in 
practice, but impractical when a hosting account moves over and has 
300, or 3000 subscribers all using username only authentication.  In 
that case, with dovecot currently the query is written to compare 
full email (if exists to the database) and if not, it compares the 
local_ip value of the connection to the database to do a domain match 
so the full domain is not required and then concatenates the domain 
which was just looked up by local_ip to the username for a full match.


As the dovecot auth socket does not receive the local_ip information 
from postfix currently, this is not an option.  It would help us out 
a lot if this feature were in there.


I noticed somebody wrote a patch for postfix-2.3.8.  I'm not a C 
programmer myself, so I'm not sure of it's quality or if this code 
could be used or committed to the postfix source tree.  Found at 
http://preview.tinyurl.com/b87z44


- Nathan

Whitelist assistance with dnswl.org

[David Cottle]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I have my own 'static' whitelisting working in smtpd_client_restrictions

I would also like to use the whitelisting in dnswl.org to override
blacklisting

I don't have much mail traffic, so rather than rsyncing, I want to do
this using normal DNS lookups.

The instructions say to:

smtpd_recipient_restrictions = ...
 reject_unauth_destination,
 ...
 check_client_access cidr:/etc/postfix/postfix-dnswl-permit,


My question is then simply how can you do this using a normal lookup?

smtpd_recipient_restrictions = ...
reject_unauth_destination,
???

or can / should it be done on my existing smtp_client_restrictions
rather than smtpd_recipient_restrictions:

smtpd_client_restrictions = check_client_access
hash:/etc/postfix/whitelist, check_sender_access
hash:/etc/postfix/check_backscatterer, check_sender_access
hash:/etc/postfix/check_spamcannibal, reject_rbl_client
bl.spamcop.net, reject_rbl_client zen.spamhaus.org, reject_rbl_client
b.barracudacentral.org

Just I am not sure and also if I do it in
smtpd_recipient_restrictions, does this then get overwritten by the
last check in the smtpd_client_restrictions?  I naturally assume if it
is to go into smtpd_client_restrictions, it would go right after my
static whitelist, or my two check_ routines filtering out backscatter
bounces.

Sorry for all the questions.

Many thanks!

David


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkmSBUUACgkQi1lOcz5YUMhhhwCfcIhqrPd4Z7Bak7ieW4u3L9Ea
qAoAoKE02qHxknH+M+3ibVUB3zZvaSrO
=7wNN
-END PGP SIGNATURE-

begin:vcard
fn:David Cottle
n:Cottle;David
email;internet:webmas...@aus-city.com
title:Webmaster
version:2.1
end:vcard

Re: No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)

[João Miguel Neves]

Charles Marcus escreveu:

On 2/10/2009 1:49 PM, João Miguel Neves wrote:
  

Charles Marcus escreveu:


Here's a link informing why indiscriminate use of SAV is bad, and what
it should be used for:

http://www.backscatterer.org/?target=sendercallouts
  


  

OK, I've finished reading and analyzing that text. My conclusion is that
there's no reason not to use reject_unverified sender.



Your conclusion is flawed.
  
If the flaw is different from the one Pawel and mouss pointed out (I was 
inventing bounces), could you please point it out?

I agree with John. Please provide all IP addresses you are using so I
can block them all now.
  
I have no mail servers doing SAV at the moment. As I said before, I'm 
studying this.


Thanks for your input,
João Miguel Neves

--
Intraneia
http://www.intraneia.com/

Suporte a Software Livre
Tradução/Localização de software e sítios web
Desenvolvimento de software

Ao seu serviço...

Re: Create additional sub-folders postfix/courier

[mouss]

Gabriel Tartaglia a écrit :
> Hi all
> 
> I have a mail server which is courier, postfix, amavisd, using Postgres
> db and virtual mailboxes which I administer through postfixadmin.
> 
> I want to be able to add a set of default folders to all mailboxes
> created such as Possible Spam and some others.
> 
> I have investigated shared folders but this is not what i want, is there
> a way I can get courier/postfix to create a set of additional
> sub-folders when it creates a mailbox.
> 
> All mailboxes are accessed as IMAP mailboxes.
> 
> Is this possible? if so where would I go about doing this?
> 


You can create "dummy" mailboxes that use the folders as their maildir.
for example:

joe+s...@example.com/some/path/example.com/joe/Maildir/.Spam/

then tell amavisd-new to add the "+spam" extension to mail tagged as spam.

This may or may not be easy depending on your setup.

This approach can work for any folder as follows. you populate
virtual_mailbox_maps with things like:

joe+fol...@example.com  /some/path/example.com/joe/Maildir/.folder

then you send a "welcome" or "help" message to joe+fol...@example.com
and postfix will create the mailbox.


An alternative is to deliver via maildrop, and have maildrop create the
folders. since you already have courier working, adding maildrop should
be easy.

Re: No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)

[Paweł Leśniak]

mouss pisze:

João Miguel Neves a écrit :
  

OK, I'll take that into consideration if I re-enable SAV.





if you re-enable SAV, do as much checks as you can. the minimum is
zen.spamhaus.org. but you can also use spamcop.

it would also be good to do it after greylisting, but this means your GL
server need to return a defer instead of defer_if_permit.

what you can also do is run a log parser that counts the SAV probes you
send, and disable the feature if some threshold is reached (rate limit
per client network, per sender domain, and global).  (an alternative is
a policy server that implements this, but a log parser is enough).

I was under the impression that you did it before zen check because the
log you posted has a client listed in zen. but I now realize it may have
been listed later.
  
And again my 5 cents. I think that people should take advantage of SPF 
and/or DKIM records. If you'll check DKIM/SPF then you could for example 
do SAV for clients/senders who are not allowed via SPF/DKIM or do not 
provide those records. I believe this change is no cost for you, and is 
saving some resources on both sides. Anyways whether you'll do SAV for 
"bad" hosts or just reject emails from them is your choice. But no one 
will blame you if you reject those emails, as you should be informed by 
administrator (in terms of SPF/DKIM records) which hosts are permitted 
to send (relay) - if you're given SPF record it should be correct, right?


Pawel

Re: How to allow mails from some other servers to pass: reject_sender_login_mismatch

[mouss]

an...@iguanait.com a écrit :
> Hi,
> 
> i'm trying to slow down and block backscater mails and i try to use:
> reject_sender_login_mismatch and smtpd_sender_login_maps.
> 
> I have some questions about how to pass this restriction for some cases.
> The situation is this:
> 
> We have some other servers where we have installed other webapplication
> that send mail from there using for example i...@ourdomain.com without
> authentication.
> These mails are sending to our mail server, but now we filter all these
> addresses to prevent using our addresses in MAIL FROM to send mails to
> us.
> 
> How to allow these servers to pass the rule
> reject_sender_login_mismatch?
> 
> We have this configuration for sernder restrictions:
> 
> smtpd_sender_restrictions =
> permit_mynetworks,
> permit_sasl_authenticated,
> check_sender_access hash:/etc/postfix/access,
> #   reject_sender_login_mismatch,
> reject_non_fqdn_sender,
> reject_unknown_sender_domain,
> reject_unauth_pipelining,
> permit
> 
> i have commented out the parameter, temporary until i find out how to
> solve this problem.
> 
> I added in access file this kind of entry:
> serveripaddress OK
> 
> but this does not help, i got mailer-daemon mail when other server sent
> mail.
> 

your access file is used for check_SENDER_access, not for
check_client_access.

the easy way is to add the IP to mynetworks. otherwise add
check_client_access cidr:/etc/postfix/access_client
before reject_sender_login_mismatch and put the IP in acces_client:

10.1.2.3/32 OK

do not postmap this, since it is a cidr map.

Re: Redirect all mail from one domain to the same u...@otherdomain?

[mouss]

jeff_homeip a écrit :
> [snip]
> 
> that creates some complications...and might be too difficult
> 

a script and a Makefile... or sql as below:

> but why not use wildcard virtual aliases? You noted below that they break 
> recipient 
> validations. Do you mean that smtp_recipient_restrictions won't work? at all 
> or parts?
> 

no, it's not about smtpd restrictions. it's about rejecting mail to
invalid recipients.

> Wildcard virtual aliases seems like the best waybut I want to understand 
> the implications 
> on everything esle before I proceed.
> 
> Thanks!
> 
>> The reason is that if you use
>> @example.com @example.org
>> then this breaks recipient validation: smtpd will accept
>> anything^example.com, then at delivery time, the user won't be found and
>> a bounce will be generated. in short, you become a source of backscatter
>> (you send bounces to innocents whose addresses were forged by spammers)
> 
> Unless I don't bounce unknown addresses
> 

and you'd do what with these? if you have a catchall, it's ok. but you
should not discard mail (people do mistype addresses some time, so it's
not just spammers trying invalid addresses).

>> you can generate the individual mappings with a script. alternatively,
>> if you store users in sql, you can use sql statements to generate these
>> "on the fly". examples have been posted multiple times to the list (a
>> long time ago, that said, but you may be lucky...).
>>
>>
> 
> it would be something like:
> 
> if (%d='domain1.com') then select %...@domain2..com from virtual_alias else 
> select alias 
> from virtual_alias where address=%s 
> 
> (that's not quite right in the syntax, but you get the idea). This wont' 
> work, as I'd have to 
> write a special select clause for each domain I want to work this way.
> 


assuming you have a User table containing valid email addresses and a
AliasDomain table containing (alias, destination) domains:

select User.user from AliasDomain, User where
 AliasDomain.alias = '%d'
AND
 User.user = CONCAT('%u', '@', AliasDomain.destination)

you can avoid the CONCAT inside the "search" if you split your emails in
(user, domain) columns like I do. in which case, the query becomes

select CONCAT(User.user, '@', User.domain) where
AliasDomain.alias = '%d'
AND
AliasDomain.destination = User.domain
AND
User.user = '%u'


of course, this works for "1 depth" alias domains (it doesn't work if
example.net is an alis for example.org which is in turn an alias of
example.com). but this should be enough in most cases.

Re: No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)

[Charles Marcus]

On 2/10/2009 1:49 PM, João Miguel Neves wrote:
> Charles Marcus escreveu:
>> Here's a link informing why indiscriminate use of SAV is bad, and what
>> it should be used for:
>>
>> http://www.backscatterer.org/?target=sendercallouts

> OK, I've finished reading and analyzing that text. My conclusion is that
> there's no reason not to use reject_unverified sender.

Your conclusion is flawed.

> Most people disabled VRFY to prevent spammer tests for email addresses,
> nothing else. If you want to disable all tests for email addresses you
> accept all email for all email addresses, even non-existing ones and
> later discard the invalid ones. That's the only way to do it (and the
> reason why some of my clients are using catch-all addresses that they
> redirect to /dev/null).

Using catch-all for production mail servers is bad. It breaks recipient
validation - meaning, if Some Important Person sends an email to the
owner of one of the companies you are hosting, and typo's his email
address, the sender will NOT get an NDR, and will NOT know that his
important message was not delivered.

Security by obscurity simply does not work... it causes far more
problems than it solves, one of which is a FALSE sense of security.

> 2) That a spammer can create a DDOS using SAV.
> 
> You'll get a connection per server to which those were sent (postfix
> caches the request, so it will only validate an email adress once).
> 
> SAV actually helps reduce the effect of the DDOS attack. In the non-SAV
> scenario, you get 30 million bounce messages. In the SAV cenario, each
> server does one check per email adress (that costs you less bandwidth
> and disk space than a Bounce message) and that single check will avoid
> several bounce messages.

As I said, your conclusion is terribly flawed.

> 3) That SAV might create a loop.
> 
> The SAV check in postfix is done with the postmaster address by default.
> If the target server does the same check back, then the SAV server
> replies that postmaster is valid (assuming it's well-configured and
> RFC-compliant).
> 
> Have I missed anything?

Every SAV your server performs is arguably an ABUSE of the server being
probed. For small sites, that abuse would be negligible and even
unnoticeable.

I agree with John. Please provide all IP addresses you are using so I
can block them all now.

-- 

Best regards,

Charles

Re: No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)

[mouss]

Paweł Leśniak a écrit :
> [snip]
>> let me fork a little: SAV on _header_ addresses is plain dumb:
>>
>> Dec 15 11:25:33 imlil postmx/smtpd[23878]: NOQUEUE: warn: RCPT from
>> chlothar.bnv-bamberg.de[217.146.130.193]: Transaction logged:
>> PTR=chlothar.bnv-bamberg.de; from=
>> to= proto=ESMTP helo=
>>
>> if you post to the spamassassin-users list, and you log transactions,
>> you'll see such probes.
>>   
> Have you any clue whether they do those probes if sender's domain has
> SPF record? In case they do SAV if sender's domain is not using SPF/DKIM
> I'd say it's acceptable for me.
> 

they do this on the From: header (not on the envelope sender address)
for mail resent by the spamassassin-users list. SPF will change nothing
here (I will obviously not put the apache servers in my SPF record,
should I add one). and yes, my mail is DKIM signed as you can see by
checking this message.

actually, another probes has ceased after I contacted his hoster's abuse
address. and it appears that some implementations based on exim do this
(SAV on the header address) by default. I am not sure if someone patched
exim to do this or if the "guy" was simply wrong.

Re: No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)

[mouss]

João Miguel Neves a écrit :
> OK, I'll take that into consideration if I re-enable SAV.
> 


if you re-enable SAV, do as much checks as you can. the minimum is
zen.spamhaus.org. but you can also use spamcop.

it would also be good to do it after greylisting, but this means your GL
server need to return a defer instead of defer_if_permit.

what you can also do is run a log parser that counts the SAV probes you
send, and disable the feature if some threshold is reached (rate limit
per client network, per sender domain, and global).  (an alternative is
a policy server that implements this, but a log parser is enough).

I was under the impression that you did it before zen check because the
log you posted has a client listed in zen. but I now realize it may have
been listed later.

Re: No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)

[Paweł Leśniak]

mouss pisze:

no reason to overreact. I am not seeing SAV abuse (but I am seeing
backscatter and spam).
  
And I do under some circumstances. If I have SPF record, then I'm 
helping the other side to check if mail with sender from my domain is 
permitted or not. This means that sender already had to pass my tests 
and was permitted by my server to send mail. Why in hell would I give 
another resources to do checks which are *really* useless in such 
configuration? I know that SPF is not the cure for everything, but in 
war SPF vs SAV I prefer SPF which I can control rather than SAV which 
can be abused with backscatter.

let me fork a little: SAV on _header_ addresses is plain dumb:

Dec 15 11:25:33 imlil postmx/smtpd[23878]: NOQUEUE: warn: RCPT from
chlothar.bnv-bamberg.de[217.146.130.193]: Transaction logged:
PTR=chlothar.bnv-bamberg.de; from=
to= proto=ESMTP helo=

if you post to the spamassassin-users list, and you log transactions,
you'll see such probes.
  
Have you any clue whether they do those probes if sender's domain has 
SPF record? In case they do SAV if sender's domain is not using SPF/DKIM 
I'd say it's acceptable for me.


Pawel Lesniak

Re: No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)

[Wietse Venema]

Jo??o Miguel Neves:
> Pawe? Le?niak escreveu:
> > Jo?o Miguel Neves pisze:
> >> Charles Marcus escreveu:
> >>> Here's a link informing why indiscriminate use of SAV is bad, and what
> >>> it should be used for:
> >>>
> >>> http://www.backscatterer.org/?target=sendercallouts
> >> OK, I've finished reading and analyzing that text. My conclusion is 
> >> that there's no reason not to use reject_unverified sender.

Sender address probing works fine for tiny sites like mine, as long
as one uses it responsibly - after unknown recipient checks, other
sanity checks, blacklists and greylister, and with a decent amount
of caching.  I prefer not to spend the network, CPU and memory
resources that are needed for deep inspection.

Wietse

Re: No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)

[João Miguel Neves]

mouss escreveu:

João Miguel Neves a écrit :
  

Charles Marcus escreveu:


Here's a link informing why indiscriminate use of SAV is bad, and what
it should be used for:

http://www.backscatterer.org/?target=sendercallouts
  

OK, I've finished reading and analyzing that text. My conclusion is that
there's no reason not to use reject_unverified sender.

In this answer I'm assuming 1) the postfix implementation of SAV and
that any implementation and 2) that MTAs implement the RFCs (so they
have a configuration that matches, for instance, the Book of Postfix).

There are 3 claims in that text:

1) That by disabling VRFY, a sysadmin has decided to disable all kind of
email address verification.

Most people disabled VRFY to prevent spammer tests for email addresses,
nothing else. If you want to disable all tests for email addresses you
accept all email for all email addresses, even non-existing ones and
later discard the invalid ones. 



where did you get this? I disable VRFY because _I_ don't need it. you
have no business validating addresses on my server unless you want to
send me mail. my server is not here to help you filter your spam. I
already have my share.

I have no problem if the SAV client implements enough spam filtering
before knocking on my door, but this is not your case: you do SAV even
if the clien is listed in zen. you are free not to use zen, but you are
not free to mirror zen listed connections on my server.
  
Not the case. I'm doing SAV as the last anti-spam measure. Charles 
Marcus said that it shouldn't be part of my anti-spam measures, and I'm 
trying to understand if that's correct.

That's the only way to do it (and the
reason why some of my clients are using catch-all addresses that they
redirect to /dev/null).

2) That a spammer can create a DDOS using SAV.

You'll get a connection per server to which those were sent (postfix
caches the request, so it will only validate an email adress once)


you are confused. they send junk to N different servers. these different
servers have nothing to cache. they will then connect to my server to
validate the address. That's N smtp connections to my server.
  
OK, that's assuming 1 address per server. And yes, there's nothing to 
avoid that first probe. The page Charles indicated mentioned a 30 
million address DDoS, so I assumed (perhaps wrongly) that it wouldn't 
mean only one message per server.

SAV actually helps reduce the effect of the DDOS attack. In the non-SAV
scenario, you get 30 million bounce messages. 



why? I don't do SAV and I don't send bouncess
  

In the SAV cenario, each
server does one check per email adress (that costs you less bandwidth
and disk space than a Bounce message) and that single check will avoid
several bounce messages.


you are inventing bounces.
  

Sorry for that, you and Pawel are right.

The bounces only exist if the servers receiving the spam accept an email 
before validating the recipient address. I wrongly assumed that each 
email would generate a bounce. You're both right.


This means that there's no advantage in resources for the DDoS target 
for using SAV and that SAV can be used as an attack vector.

3) That SAV might create a loop.

The SAV check in postfix is done with the postmaster address by default.
If the target server does the same check back, then the SAV server
replies that postmaster is valid (assuming it's well-configured and
RFC-compliant).

Have I missed anything?


By using SAV, you want to filter _your_ spam using _my_ resources. If I
accept that, then it is a favour I am doing you. and I will only do this
favour if I think your are "nice":
- the minimum is to do enough checks before knocking my server.
- it must be easy to find who you are and how to contact you. This means
that if I see a probe in my logs, I must be able to find a web page to
know who you are and what you do, and you also must have a fully working
abuse address.
  

OK, I'll take that into consideration if I re-enable SAV.

Thanks for your input,
João Miguel Neves

--
Intraneia
http://www.intraneia.com/

Suporte a Software Livre
Tradução/Localização de software e sítios web
Desenvolvimento de software

Ao seu serviço...

Re: No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)

[mouss]

Paweł Leśniak a écrit :
> [snip]
> Well, to be honest, I believe you did. If you will do many checks to the
> same server (have on mind large ISPs with many domains) with different
> emails, then probably your server will get blacklisted to send email
> from postmaster@ (at least). If you want explanation why, here it is:
> SMTP session to do SAV check is naither an email from individual to
> individual, nor message from receiver's system to sender. Of course it's
> also not wanted by sender, so in any case - it's spam and your server
> should be treated like any other spamming server. You hopefully
> understand my point of view. You don't have to agree - it doesn't matter.
> 
> Maybe this thread is a good reason to create BL containing servers doing
> large amounts of SAV checks? I'd be very happy if I could use such BL to
> reject emails from postmaster at those domains (and probably <> also).
> 

no reason to overreact. I am not seeing SAV abuse (but I am seeing
backscatter and spam).

let me fork a little: SAV on _header_ addresses is plain dumb:

Dec 15 11:25:33 imlil postmx/smtpd[23878]: NOQUEUE: warn: RCPT from
chlothar.bnv-bamberg.de[217.146.130.193]: Transaction logged:
PTR=chlothar.bnv-bamberg.de; from=
to= proto=ESMTP helo=

if you post to the spamassassin-users list, and you log transactions,
you'll see such probes.

Re: No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)

[João Miguel Neves]

Paweł Leśniak escreveu:

João Miguel Neves pisze:

Charles Marcus escreveu:

Here's a link informing why indiscriminate use of SAV is bad, and what
it should be used for:

http://www.backscatterer.org/?target=sendercallouts
OK, I've finished reading and analyzing that text. My conclusion is 
that there's no reason not to use reject_unverified sender.


In this answer I'm assuming 1) the postfix implementation of SAV and 
that any implementation and 2) that MTAs implement the RFCs (so they 
have a configuration that matches, for instance, the Book of Postfix).


There are 3 claims in that text:

1) That by disabling VRFY, a sysadmin has decided to disable all kind 
of email address verification.


Most people disabled VRFY to prevent spammer tests for email 
addresses, nothing else. If you want to disable all tests for email 
addresses you accept all email for all email addresses, even 
non-existing ones and later discard the invalid ones. That's the only 
way to do it (and the reason why some of my clients are using 
catch-all addresses that they redirect to /dev/null).
Well, if you discard any message which can be "real" message (not 
containing viruses etc.) just with typos, you just have no users to 
complain they didn't get important emails. That's it. In that case 
(private SMTP with few addressess and small traffic) you won't 
probably get blacklisted. The other scenario (many users, big traffic) 
ends up with your server blacklisted.
Anyways - those clients which you mention, are in first scenario (few 
emails), or they don't use business cards and commercials in 
non-electronic forms, or there was no one to tell them what they are 
missing.

Yes, the couple of clients that do that are aware of the cost.


2) That a spammer can create a DDOS using SAV.

You'll get a connection per server to which those were sent (postfix 
caches the request, so it will only validate an email adress once).


SAV actually helps reduce the effect of the DDOS attack. In the 
non-SAV scenario, you get 30 million bounce messages. In the SAV 
cenario, each server does one check per email adress (that costs you 
less bandwidth and disk space than a Bounce message) and that single 
check will avoid several bounce messages.


That's not true. In some cases if you are checking envelope sender, 
you can see <>. How do you think you can deal with it? While you can 
get few thousands emails with forged return-path emails (existing or 
not - not a problem). Now imagine that your server is not the only one 
which received this amount of mails with same sender. Then you are 
performing DDoS.  Anyways - you should not bounce messages for 
non-existent users. You should rather reject them (and that's efficient).
<> won't generate a sender check. So what would be the problem generated 
by SAV here?
And what's the point of having catch-all address when you discard 
those emails? Have on mind that you are still open to dictionary 
attacks. And in most cases spammers don't care if your email is 
correct or not. Still your emails are cool to be used for backscatter.
The catch-all doesn't apply here. Was just an example on how to avoid 
dictionary attacks for probing addresses.

3) That SAV might create a loop.

The SAV check in postfix is done with the postmaster address by 
default. If the target server does the same check back, then the SAV 
server replies that postmaster is valid (assuming it's 
well-configured and RFC-compliant).


Have I missed anything?
Well, to be honest, I believe you did. If you will do many checks to 
the same server (have on mind large ISPs with many domains) with 
different emails, then probably your server will get blacklisted to 
send email from postmaster@ (at least). If you want explanation why, 
here it is: SMTP session to do SAV check is naither an email from 
individual to individual, nor message from receiver's system to 
sender. Of course it's also not wanted by sender, so in any case - 
it's spam and your server should be treated like any other spamming 
server. You hopefully understand my point of view. You don't have to 
agree - it doesn't matter.
Yes, I understand the point of view. I'm just trying to understand if it 
is really worst or better in terms of resource consumption.
Maybe this thread is a good reason to create BL containing servers 
doing large amounts of SAV checks? I'd be very happy if I could use 
such BL to reject emails from postmaster at those domains (and 
probably <> also).
It wouldn't be useful for you, as Noel Jones pointed out, postfix isn't 
using postmaster for SAV since 2.5.


Best regards,
João Miguel Neves

--
Intraneia
http://www.intraneia.com/

Suporte a Software Livre
Tradução/Localização de software e sítios web
Desenvolvimento de software

Ao seu serviço...

Re: No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)

[mouss]

João Miguel Neves a écrit :
> Charles Marcus escreveu:
>> Here's a link informing why indiscriminate use of SAV is bad, and what
>> it should be used for:
>>
>> http://www.backscatterer.org/?target=sendercallouts
> OK, I've finished reading and analyzing that text. My conclusion is that
> there's no reason not to use reject_unverified sender.
> 
> In this answer I'm assuming 1) the postfix implementation of SAV and
> that any implementation and 2) that MTAs implement the RFCs (so they
> have a configuration that matches, for instance, the Book of Postfix).
> 
> There are 3 claims in that text:
> 
> 1) That by disabling VRFY, a sysadmin has decided to disable all kind of
> email address verification.
> 
> Most people disabled VRFY to prevent spammer tests for email addresses,
> nothing else. If you want to disable all tests for email addresses you
> accept all email for all email addresses, even non-existing ones and
> later discard the invalid ones. 

where did you get this? I disable VRFY because _I_ don't need it. you
have no business validating addresses on my server unless you want to
send me mail. my server is not here to help you filter your spam. I
already have my share.

I have no problem if the SAV client implements enough spam filtering
before knocking on my door, but this is not your case: you do SAV even
if the clien is listed in zen. you are free not to use zen, but you are
not free to mirror zen listed connections on my server.

> That's the only way to do it (and the
> reason why some of my clients are using catch-all addresses that they
> redirect to /dev/null).
> 
> 2) That a spammer can create a DDOS using SAV.
> 
> You'll get a connection per server to which those were sent (postfix
> caches the request, so it will only validate an email adress once).
> 

you are confused. they send junk to N different servers. these different
servers have nothing to cache. they will then connect to my server to
validate the address. That's N smtp connections to my server.

> SAV actually helps reduce the effect of the DDOS attack. In the non-SAV
> scenario, you get 30 million bounce messages. 

why? I don't do SAV and I don't send bounces.

> In the SAV cenario, each
> server does one check per email adress (that costs you less bandwidth
> and disk space than a Bounce message) and that single check will avoid
> several bounce messages.
> 

you are inventing bounces.

> 3) That SAV might create a loop.
> 
> The SAV check in postfix is done with the postmaster address by default.
> If the target server does the same check back, then the SAV server
> replies that postmaster is valid (assuming it's well-configured and
> RFC-compliant).
> 
> Have I missed anything?
> 

By using SAV, you want to filter _your_ spam using _my_ resources. If I
accept that, then it is a favour I am doing you. and I will only do this
favour if I think your are "nice":
- the minimum is to do enough checks before knocking my server.
- it must be easy to find who you are and how to contact you. This means
that if I see a probe in my logs, I must be able to find a web page to
know who you are and what you do, and you also must have a fully working
abuse address.

hijacked NXDOMAIN (Re: DNS lookups not working?)

[mouss]

jan gestre a écrit :
> [snip]
>>> I have this same problem that I was not able to solve for almost a
>>> week now. I posted too on various mailing lists including this (mail
>>> from gmail and yahoo are blocked), some suggested to install a caching
>>> nameserver but obviously in your case it doesn't work too. Replaced
>>> OpenDNS with other DNS server to no avail, still the same result.

you can easily check your DNS service with

host 1.0.0.127.google.com

if this returns a result, then your DNS provider is lying to you and
there is nothing we can do for you.

if installing BIND on your postfix machine, without using any forwarder,
doesn't fix the problem, then your ISP is redirecting your DNS traffic,
and the only thing you can do is complain to your ISP or switch.

if all you do is forward to another lying provider, that won't fix your
problem.


a workaround is
reject_rbl_client bl.spamcop.net=127.0.0.2

you can do this for other DNSBLs, but you'll need to include every
possible return code.

but this is just a workaround.

BTW, everybody is encouraged to use dnswl.org before DNSBL calls. see
www.dnswl.org for details.


>>> [snip]
>>>
>>> Feb 10 21:34:46 kartero postfix/smtpd[14176]: NOQUEUE: reject: RCPT
>>> from wf-out-1314.google.com[209.85.200.172]: 554 5.7.1 Service
>>> unavailable; Client host [209.85.200.172] blocked using
>>> bl.spamcop.net; from=
>>> to= proto=ESMTP helo=

Re: best way to serve as specific system relay

[Noel Jones]

Victor Duchovni wrote:

On Tue, Feb 10, 2009 at 02:23:45PM -0500, post...@corwyn.net wrote:

machines that send FROM: the local address but TO: somewhere else I think I 
need postfix to serve as a relay for those machines.


I think I can fix it by setting
check_client_access hash:/etc/postfix/remotebranches
BEFORE reject_unauth_destination with the IP addresses of each of the 
branches listed as OK.


Just add the machines to "mynetworks". You can use a "cidr:" table if
that's helpful.



and recheck the docs for the fax machine.  Most of the ones 
smart enough to send mail can also do SMTP AUTH, although they 
sometimes call it something odd.


--
Noel Jones

Re: best way to serve as specific system relay

[Victor Duchovni]

On Tue, Feb 10, 2009 at 02:23:45PM -0500, post...@corwyn.net wrote:

> machines that send FROM: the local address but TO: somewhere else I think I 
> need postfix to serve as a relay for those machines.
>
> I think I can fix it by setting
> check_client_access hash:/etc/postfix/remotebranches
> BEFORE reject_unauth_destination with the IP addresses of each of the 
> branches listed as OK.

Just add the machines to "mynetworks". You can use a "cidr:" table if
that's helpful.

-- 
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: No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)

[Paweł Leśniak]

João Miguel Neves pisze:

Charles Marcus escreveu:

Here's a link informing why indiscriminate use of SAV is bad, and what
it should be used for:

http://www.backscatterer.org/?target=sendercallouts
OK, I've finished reading and analyzing that text. My conclusion is 
that there's no reason not to use reject_unverified sender.


In this answer I'm assuming 1) the postfix implementation of SAV and 
that any implementation and 2) that MTAs implement the RFCs (so they 
have a configuration that matches, for instance, the Book of Postfix).


There are 3 claims in that text:

1) That by disabling VRFY, a sysadmin has decided to disable all kind 
of email address verification.


Most people disabled VRFY to prevent spammer tests for email 
addresses, nothing else. If you want to disable all tests for email 
addresses you accept all email for all email addresses, even 
non-existing ones and later discard the invalid ones. That's the only 
way to do it (and the reason why some of my clients are using 
catch-all addresses that they redirect to /dev/null).
Well, if you discard any message which can be "real" message (not 
containing viruses etc.) just with typos, you just have no users to 
complain they didn't get important emails. That's it. In that case 
(private SMTP with few addressess and small traffic) you won't probably 
get blacklisted. The other scenario (many users, big traffic) ends up 
with your server blacklisted.
Anyways - those clients which you mention, are in first scenario (few 
emails), or they don't use business cards and commercials in 
non-electronic forms, or there was no one to tell them what they are 
missing.

2) That a spammer can create a DDOS using SAV.

You'll get a connection per server to which those were sent (postfix 
caches the request, so it will only validate an email adress once).


SAV actually helps reduce the effect of the DDOS attack. In the 
non-SAV scenario, you get 30 million bounce messages. In the SAV 
cenario, each server does one check per email adress (that costs you 
less bandwidth and disk space than a Bounce message) and that single 
check will avoid several bounce messages.


That's not true. In some cases if you are checking envelope sender, you 
can see <>. How do you think you can deal with it? While you can get few 
thousands emails with forged return-path emails (existing or not - not a 
problem). Now imagine that your server is not the only one which 
received this amount of mails with same sender. Then you are performing 
DDoS.  Anyways - you should not bounce messages for non-existent users. 
You should rather reject them (and that's efficient).
And what's the point of having catch-all address when you discard those 
emails? Have on mind that you are still open to dictionary attacks. And 
in most cases spammers don't care if your email is correct or not. Still 
your emails are cool to be used for backscatter.

3) That SAV might create a loop.

The SAV check in postfix is done with the postmaster address by 
default. If the target server does the same check back, then the SAV 
server replies that postmaster is valid (assuming it's well-configured 
and RFC-compliant).


Have I missed anything?
Well, to be honest, I believe you did. If you will do many checks to the 
same server (have on mind large ISPs with many domains) with different 
emails, then probably your server will get blacklisted to send email 
from postmaster@ (at least). If you want explanation why, here it is: 
SMTP session to do SAV check is naither an email from individual to 
individual, nor message from receiver's system to sender. Of course it's 
also not wanted by sender, so in any case - it's spam and your server 
should be treated like any other spamming server. You hopefully 
understand my point of view. You don't have to agree - it doesn't matter.


Maybe this thread is a good reason to create BL containing servers doing 
large amounts of SAV checks? I'd be very happy if I could use such BL to 
reject emails from postmaster at those domains (and probably <> also).



Pawel Lesniak

Re: Massive Double Bounce problems

[Wietse Venema]

Thomas Glanzmann:
> so what happened. erld671x is out of resources, it send an e-mail to
> postmas...@erld671x.erlf.siemens.de but because it is horrible
> misconfigured it sends that e-mail over its smart host which delivers it
> back, which results in a tempfailure which again triggers an out of
> resource e-mail. Thank you for staying with me on this one.
> 
> Feb 10 01:16:14 erld671x postfix/smtpd[6621]: NOQUEUE: reject: MAIL from 
> erld604x.erlf.siemens.de[194.138.228.204]: 452 Insufficient system storage; 
> proto=ESMTP helo=
> Feb 10 01:16:14 erld671x postfix/smtpd[6621]: warning: not enough free space 
> in mail queue: 1966080 bytes < 1.5*message size limit

Hmm, 2GB is not a lot of free space indeed.

Postfix tries to avoid the situation where the system is 100% full
and it can no longer get work done.

To completely avoid such conditions, Postfix would have to reserve
an amount of space the size of (message size limit * inbound
concurrency). Unfortunately, this is not practical in many cases,
so it settles for 1.5 times the message size limit.

> > > that softbounce and so on until I'm out of resources. Shouldn't postfix
> > > detect that this is a tempfailure and do exactly nothing and retry a few
> > > hours later? Again this was with postfix version 2.1.1.
> 
> > Not if you turn on postmaster notification for resource problems.
> 
> I was unaware of that option. Thank you for explicitly mention it:
> 
> (erld603x) [~] postconf | grep -i notify
> notify_classes = resource, software

Yes, the default includes "resource, software". That was a good
choice 10 years ago.

Wietse

best way to serve as specific system relay

[postfix]

Hi,

I've got a number of remote branches that send mail. for the users 
using a mail client, it's no problem to use SMTP auth. For the less 
intelligent FAX machines that send FROM: the local address but TO: 
somewhere else I think I need postfix to serve as a relay for those machines.


I think I can fix it by setting
check_client_access hash:/etc/postfix/remotebranches
BEFORE reject_unauth_destination with the IP addresses of each of the 
branches listed as OK.


I end up with:

smtpd_recipient_restrictions =
reject_non_fqdn_recipient
reject_non_fqdn_sender
reject_unknown_sender_domain
reject_unknown_recipient_domain
permit_mynetworks
permit_sasl_authenticated
check_client_access hash:/etc/postfix/remotebranches
reject_unauth_destination
check_client_access hash:/etc/postfix/access
check_helo_access pcre:/etc/postfix/helo_checks
reject_rbl_client dnsbl.sorbs.net
reject_rbl_client bl.spamcop.net
reject_rbl_client cbl.abuseat.org


Is that the best/right way to solve this?

thx.

Rick




Rick Steeves
http://www.sinister.net

"The journey is the destination"

Re: Delaying some email addresses

[Victor Duchovni]

On Tue, Feb 10, 2009 at 06:55:11PM +, Jo?o Miguel Neves wrote:

> Victor Duchovni escreveu:
>> On Tue, Feb 10, 2009 at 04:43:15PM +, Jo?o Miguel Neves wrote:
>>
>>   
> What I'm trying is dealing with the spam sent for a single address. My
> 
>> You still have not understood what REDIRECT does. Please see the
>> access(5) documentation.
>>
>>  http://www.postfix.org/access.5.html
>
> Unless you're claiming that REDIRECT will redirect different messages that 
> look like the redirected one, you're the one that didn't understand when I 
> said that I'm trying to deal with different spam messages sent to a single 
> email address.

When a single message with multiple recipients hits a spam-trap, REDIRECT
it to just the spam-trap.

When multiple messages are sent by a single IP address, and one of that
hits a spam-trap, you can consult a policy service that adds a header
that tags the mail as coming from a suspect source. Such mail can be
quarantined and released after a time delay, with potentially more
up-to-date rules able to filter the mail at that point.

Implementation of a quarantine is outside the scope of the Postfix
system, you can put mail in the hold queue, or build an LMTP server
that feeds the quarantine, and use "FILTER" to route mail to the
quarantine. The quantine server can feed Bayesian filters when
mail comes in, and hope that the filters are well trained when
the mail is finally released to the recipients.

-- 
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: No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)

[Noel Jones]

João Miguel Neves wrote:
The SAV check in postfix is done with the postmaster address by default. 


Recent postfix (2.5 and newer) use $double_bounce_sender as 
the default for address_verify_sender.  This recipient is 
always valid, never delivered.

http://www.postfix.org/postconf.5.html#address_verify_sender

Using $double_bounce_sender has been found to cause fewer 
compatibility problems than "postmas...@example.com" or "<>", 
which some sites don't like as a sender.


--
Noel Jones

Re: No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)

[John Peach]

On Tue, 10 Feb 2009 18:49:05 +
Jo__o Miguel Neves  wrote:

> Charles Marcus escreveu:
> > Here's a link informing why indiscriminate use of SAV is bad, and what
> > it should be used for:
> >
> > http://www.backscatterer.org/?target=sendercallouts
> OK, I've finished reading and analyzing that text. My conclusion is that 
> there's no reason not to use reject_unverified sender.
> 
> In this answer I'm assuming 1) the postfix implementation of SAV and 
> that any implementation and 2) that MTAs implement the RFCs (so they 
> have a configuration that matches, for instance, the Book of Postfix).
> 
[snip]
> Have I missed anything?
> 
Yes; your domain so that I can block it.

Re: Delaying some email addresses

[João Miguel Neves]

Victor Duchovni escreveu:

On Tue, Feb 10, 2009 at 04:43:15PM +, Jo?o Miguel Neves wrote:

  

What I'm trying is dealing with the spam sent for a single address. My


You still have not understood what REDIRECT does. Please see the
access(5) documentation.

http://www.postfix.org/access.5.html
  

Unless you're claiming that REDIRECT will redirect different messages that look 
like the redirected one, you're the one that didn't understand when I said that 
I'm trying to deal with different spam messages sent to a single email address.

Best regards,
João Miguel Neves

--
Intraneia
http://www.intraneia.com/

Suporte a Software Livre
Tradução/Localização de software e sítios web
Desenvolvimento de software

Ao seu serviço...

Re: how to accept some addresses but relay the rest?

[João Miguel Neves]

Andy Spiegl escreveu:

I want to configure postfix so that it accepts mails for:
 us...@example.com (domain name changed)
 us...@example.com
and delivers them locally to the users user1 and user2,
but relays any other *...@example.com to the MX of example.com.

I tried putting this into /etc/postfix/virtual :

 example.com anything
  

@example.com anything

You forgot the at-sign.

 us...@example.com   user1
 us...@example.com   user2

Now it accepts these two addresses but denies any others:

 : host x.de[10.10.10.10] said: 550 5.1.1
: Recipient address rejected: User unknown in
virtual alias table (in reply to RCPT TO command)

It this setup possible at all?

Thanks a lot,
 Andy.
  

Best regards,
João Miguel Neves

--
Intraneia
http://www.intraneia.com/

Suporte a Software Livre
Tradução/Localização de software e sítios web
Desenvolvimento de software

Ao seu serviço...

No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)

[João Miguel Neves]

Charles Marcus escreveu:

Here's a link informing why indiscriminate use of SAV is bad, and what
it should be used for:

http://www.backscatterer.org/?target=sendercallouts
OK, I've finished reading and analyzing that text. My conclusion is that 
there's no reason not to use reject_unverified sender.


In this answer I'm assuming 1) the postfix implementation of SAV and 
that any implementation and 2) that MTAs implement the RFCs (so they 
have a configuration that matches, for instance, the Book of Postfix).


There are 3 claims in that text:

1) That by disabling VRFY, a sysadmin has decided to disable all kind of 
email address verification.


Most people disabled VRFY to prevent spammer tests for email addresses, 
nothing else. If you want to disable all tests for email addresses you 
accept all email for all email addresses, even non-existing ones and 
later discard the invalid ones. That's the only way to do it (and the 
reason why some of my clients are using catch-all addresses that they 
redirect to /dev/null).


2) That a spammer can create a DDOS using SAV.

You'll get a connection per server to which those were sent (postfix 
caches the request, so it will only validate an email adress once).


SAV actually helps reduce the effect of the DDOS attack. In the non-SAV 
scenario, you get 30 million bounce messages. In the SAV cenario, each 
server does one check per email adress (that costs you less bandwidth 
and disk space than a Bounce message) and that single check will avoid 
several bounce messages.


3) That SAV might create a loop.

The SAV check in postfix is done with the postmaster address by default. 
If the target server does the same check back, then the SAV server 
replies that postmaster is valid (assuming it's well-configured and 
RFC-compliant).


Have I missed anything?

--
Intraneia
http://www.intraneia.com/

Suporte a Software Livre
Tradução/Localização de software e sítios web
Desenvolvimento de software

Ao seu serviço...

Re: Delaying some email addresses

[Victor Duchovni]

On Tue, Feb 10, 2009 at 04:43:15PM +, Jo?o Miguel Neves wrote:

>>> What I'm trying is dealing with the spam sent for a single address. My
>>> idea is the following:
>>>
>>> 1) Spammer sends emails to existing users and spamtraps;
>>>
>>> 2) Normal users email is frozen for 2 to 5 minutes;
>>>
>>> 3) Spamtraps are queued and teach spamassassin bayes filter;
>>>
>>> 4) Normal users email is unfrozen, spamassassin catches the spam, and it
>>> doesn't reach the user mailbox
>> Why bother delivering the normal users if you are definitely going to
>> catch the junk. This is needlessly complex and pointless.
>>   
> If I don't do the delay, what happens is that the junk goes thru because, 
> in a lot of cases, spamassassin doesn't know it's junk yet.

You still have not understood what REDIRECT does. Please see the
access(5) documentation.

http://www.postfix.org/access.5.html

-- 
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: Problems with Postfix / Round-Robin

[Wietse Venema]

Pablo Scheri:
> 
> Wietse,
> I am not able to access...
> It is not a productive environment, there is no private information.
> I upload it to http://rapidshare.com/files/196381965/postfix.rar.html

It works fine as long as you use an FTP client.

I see no hosts 10.0.0.207 etc. in your maillog file. 

All mail is delivered to 10.0.0.14. There is a distribution of delays
that looks like this:

Number DelayTypical delays pattern
==
 1653  0-10s0.15/0.62/0/0.4
  201 10-20s
  613 20-30s
  327 30-40s
  347 40-50s0.13/42/0/2.6

What you have is that mail arrives fast, and the destination
host is slow, therefore mail accumulates in the Postfix queue.

To find out why the destination is slow, you need to find
out if the host really can handle 30 concurrent connections.

To find out why mail is delivered to 10.0.0.14 and not to the other
hosts, you need to update your description. I do not remember that
10.0.0.14 was originally mentioned in the discussion.

Wietse

Re: how to accept some addresses but relay the rest?

[Noel Jones]

Andy Spiegl wrote:

I want to configure postfix so that it accepts mails for:
 us...@example.com (domain name changed)
 us...@example.com
and delivers them locally to the users user1 and user2,
but relays any other *...@example.com to the MX of example.com.

I tried putting this into /etc/postfix/virtual :

 example.com anything
 us...@example.com   user1
 us...@example.com   user2

Now it accepts these two addresses but denies any others:

 : host x.de[10.10.10.10] said: 550 5.1.1
: Recipient address rejected: User unknown in
virtual alias table (in reply to RCPT TO command)

It this setup possible at all?

Thanks a lot,
 Andy.



This should get you started:

# main.cf
mydestination = localhost localhost.example.com
relay_domains = example.com
relay_recipient_maps = hash:/etc/postfix/relay_recipients
virtual_alias_maps = hash:/etc/postfix/virtual

# relay_recipients
... list of valid recipients at example.com ...
us...@example.com  OK
us...@example.com  OK
...

# virtual
us...@example.com  us...@localhost
us...@example.com  us...@localhost

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

--
Noel Jones

how to accept some addresses but relay the rest?

[Andy Spiegl]

I want to configure postfix so that it accepts mails for:
 us...@example.com (domain name changed)
 us...@example.com
and delivers them locally to the users user1 and user2,
but relays any other *...@example.com to the MX of example.com.

I tried putting this into /etc/postfix/virtual :

 example.com anything
 us...@example.com   user1
 us...@example.com   user2

Now it accepts these two addresses but denies any others:

 : host x.de[10.10.10.10] said: 550 5.1.1
: Recipient address rejected: User unknown in
virtual alias table (in reply to RCPT TO command)

It this setup possible at all?

Thanks a lot,
 Andy.

-- 
 BAYERISCHER RUNDFUNK  |  Programmbereich Multimedia und Jugend
 Dr. Andy Spiegl   |  mailto:andy.spi...@br-online.de
 Rundfunkplatz 1   |  Fon +49 (0)89 5900 16062
 D-80335 Muenchen  |  Fax +49 (0)89 5900 16120

A cautionary tale

[Richard A Downing]

As a hobby, I ran a mail server (Xmail) on on old machine, just for
myself and a few friends. It was very old, and the mail server was
getting slower and slower, and then the greylister broke.  So I got a
newer old machine and set it up with Postfix on Ubuntu.  Tested it on
the internal network.

Everything works well.  Easy install, easy set up.

Tell the NAT firewall to send external smtp to it, and plonk! Every
transfer times-out after connect. I check everything :-) But outgoing
mail works fine.  I spend three weeks trying different set ups.  No
luck. (I am beginning to hate Postfix, by this time).

In the end I found it, the default gateway was pointing at the machine
I'd taken the old mail server off.  All responses to smtp connects were
being routed through a blocked firewall.

The moral of this story:  It's almost always your fault.

R.

P.S.  New to Postfix, but I already like it.  Thanks Wietse.

Re: Delaying some email addresses

[João Miguel Neves]

Victor Duchovni escreveu:

On Tue, Feb 10, 2009 at 10:29:28AM +, Jo?o Miguel Neves wrote:

  

Don't "delay", if your "spamtrap" addresses are well chosen, have
never existed as valid email addresses, and are unlikely to be mistyped
accidentally by a human sender, you can just "REDIRECT" all mail for
a spamtrap address to that same spamtrap address, this drops all the
other recipients.
  
  

That's a good addition, but I already have that working.

What I'm trying is dealing with the spam sent for a single address. My
idea is the following:

1) Spammer sends emails to existing users and spamtraps;

2) Normal users email is frozen for 2 to 5 minutes;

3) Spamtraps are queued and teach spamassassin bayes filter;

4) Normal users email is unfrozen, spamassassin catches the spam, and it
doesn't reach the user mailbox

Why bother delivering the normal users if you are definitely going to
catch the junk. This is needlessly complex and pointless.
  
If I don't do the delay, what happens is that the junk goes thru 
because, in a lot of cases, spamassassin doesn't know it's junk yet.


Best regards,
João Miguel Neves

--
Intraneia
http://www.intraneia.com/

Suporte a Software Livre
Tradução/Localização de software e sítios web
Desenvolvimento de software

Ao seu serviço...

Re: Delaying some email addresses

[Victor Duchovni]

On Tue, Feb 10, 2009 at 10:29:28AM +, Jo?o Miguel Neves wrote:

> > Don't "delay", if your "spamtrap" addresses are well chosen, have
> > never existed as valid email addresses, and are unlikely to be mistyped
> > accidentally by a human sender, you can just "REDIRECT" all mail for
> > a spamtrap address to that same spamtrap address, this drops all the
> > other recipients.
> >   
> That's a good addition, but I already have that working.
> 
> What I'm trying is dealing with the spam sent for a single address. My
> idea is the following:
> 
> 1) Spammer sends emails to existing users and spamtraps;
> 
> 2) Normal users email is frozen for 2 to 5 minutes;
> 
> 3) Spamtraps are queued and teach spamassassin bayes filter;
> 
> 4) Normal users email is unfrozen, spamassassin catches the spam, and it
> doesn't reach the user mailbox.
> 

Why bother delivering the normal users if you are definitely going to
catch the junk. This is needlessly complex and pointless.

-- 
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: Problems with Postfix / Round-Robin

[Pablo Scheri]

Wietse,
I am not able to access...
It is not a productive environment, there is no private information.
I upload it to http://rapidshare.com/files/196381965/postfix.rar.html

Thanks!!

> Subject: Re: Problems with Postfix / Round-Robin
> To: postfix-users@postfix.org
> Date: Tue, 10 Feb 2009 09:25:37 -0500
> From: wie...@porcupine.org
> 
> Pablo Scheri:
> > 
> > Hi! I am not able to upload the files, I get a post error because
> > I am exceeding the 4 characters.
> 
> > How can I send you the logs? May I upload them to rapidshare or
> > something like that?
> 
> You can upload to:
> 
> ftp://ftp.porcupin.org/tmp/random/
> 
> files uploaded there cannot be "seen" or downloaded.
> 
>   Wietse

_
El doble de diversión: con Windows Live Messenger compartí fotos mientras 
charlas.
http://download.live.com/messenger

Re: Massive Double Bounce problems

[Thomas Glanzmann]

Hello Wietse,

* Wietse Venema  [090210 15:11]:
> > I still don't get why postfix sends me a soft bounce to notify me
> > that I'm running out of diskspace. 

> Have you looked at the LOGFILE?

Not yet, but now I have and I don't like what I see:

Feb 10 01:16:14 erld603x postfix/smtpd[4269]: connect from 
erld671x.erlf.siemens.de[194.138.228.10]
Feb 10 01:16:14 erld603x postfix/smtpd[4269]: 5FAD63F8C: 
client=erld671x.erlf.siemens.de[194.138.228.10]
Feb 10 01:16:14 erld603x postfix/cleanup[4135]: 5FAD63F8C: 
message-id=<20090210001614.4a70f44ba...@erld671x.erlf.siemens.de>
Feb 10 01:16:14 erld603x postfix/qmgr[23797]: 5FAD63F8C: 
from=, size=1190, nrcpt=1 (queue active)
Feb 10 01:16:14 erld603x postfix/smtpd[4269]: disconnect from 
erld671x.erlf.siemens.de[194.138.228.10]
Feb 10 01:16:14 erld603x postfix/smtp[4307]: 5FAD63F8C: 
to=, 
relay=erld671x.erlf.siemens.de[194.138.228.10], delay=0, status=deferred (host 
erld671x.erlf.siemens.
de[194.138.228.10] said: 452 Insufficient system storage (in reply to MAIL FROM 
command))
Feb 10 01:16:14 erld603x postfix/smtpd[4254]: connect from 
erld671x.erlf.siemens.de[194.138.228.10]
Feb 10 01:16:14 erld603x postfix/smtpd[4254]: 88D903F8D: 
client=erld671x.erlf.siemens.de[194.138.228.10]
Feb 10 01:16:14 erld603x postfix/cleanup[4123]: 88D903F8D: 
message-id=<20090210001614.6fa6a44ba...@erld671x.erlf.siemens.de>
Feb 10 01:16:14 erld603x postfix/qmgr[23797]: 88D903F8D: 
from=, size=1190, nrcpt=1 (queue active)
Feb 10 01:16:14 erld603x postfix/smtpd[4254]: disconnect from 
erld671x.erlf.siemens.de[194.138.228.10]
Feb 10 01:16:14 erld603x postfix/smtp[4306]: 88D903F8D: 
to=, 
relay=erld671x.erlf.siemens.de[194.138.228.10], delay=0, status=deferred (host 
erld671x.erlf.siemens.
de[194.138.228.10] said: 452 Insufficient system storage (in reply to MAIL FROM 
command))
Feb 10 01:16:14 erld603x postfix/smtpd[4269]: connect from 
erld671x.erlf.siemens.de[194.138.228.10]
Feb 10 01:16:14 erld603x postfix/smtpd[4269]: B14483FC6: 
client=erld671x.erlf.siemens.de[194.138.228.10]
Feb 10 01:16:14 erld603x postfix/cleanup[4135]: B14483FC6: 
message-id=<20090210001614.9a73344ba...@erld671x.erlf.siemens.de>
Feb 10 01:16:14 erld603x postfix/qmgr[23797]: B14483FC6: 
from=, size=1190, nrcpt=1 (queue active)
Feb 10 01:16:14 erld603x postfix/smtpd[4269]: disconnect from 
erld671x.erlf.siemens.de[194.138.228.10]
Feb 10 01:16:14 erld603x postfix/smtp[4043]: B14483FC6: 
to=, 
relay=erld671x.erlf.siemens.de[194.138.228.10], delay=0, status=deferred (host 
erld671x.erlf.siemens.
de[194.138.228.10] said: 452 Insufficient system storage (in reply to MAIL FROM 
command))

so what happened. erld671x is out of resources, it send an e-mail to
postmas...@erld671x.erlf.siemens.de but because it is horrible
misconfigured it sends that e-mail over its smart host which delivers it
back, which results in a tempfailure which again triggers an out of
resource e-mail. Thank you for staying with me on this one.

Feb 10 01:16:14 erld671x postfix/smtpd[6621]: connect from 
erld604x.erlf.siemens.de[194.138.228.204]
Feb 10 01:16:14 erld671x postfix/smtpd[6621]: NOQUEUE: reject: MAIL from 
erld604x.erlf.siemens.de[194.138.228.204]: 452 Insufficient system storage; 
proto=ESMTP helo=
Feb 10 01:16:14 erld671x postfix/smtpd[6621]: warning: not enough free space in 
mail queue: 1966080 bytes < 1.5*message size limit
Feb 10 01:16:14 erld671x postfix/cleanup[6618]: 0C1A544BAF6B: 
message-id=<20090210001614.0c1a544ba...@erld671x.erlf.siemens.de>
Feb 10 01:16:14 erld671x postfix/qmgr[10111]: 0C1A544BAF6B: 
from=, size=958, nrcpt=1 (queue active)
Feb 10 01:16:14 erld671x postfix/smtpd[6621]: disconnect from 
erld604x.erlf.siemens.de[194.138.228.204]
Feb 10 01:16:14 erld671x postfix/smtp[6620]: 0C1A544BAF6B: 
to=, orig_to=, 
relay=mailrelay.erlf.siemens.de[194.138.228.203], delay=0, status=sent (250
Ok: queued as 230253F82)
Feb 10 01:16:14 erld671x postfix/qmgr[10111]: 0C1A544BAF6B: removed
Feb 10 01:16:14 erld671x postfix/smtpd[6621]: connect from 
erld603x.erlf.siemens.de[194.138.228.203]
Feb 10 01:16:14 erld671x postfix/smtpd[6621]: NOQUEUE: reject: MAIL from 
erld603x.erlf.siemens.de[194.138.228.203]: 452 Insufficient system storage; 
proto=ESMTP helo=
Feb 10 01:16:14 erld671x postfix/smtpd[6621]: warning: not enough free space in 
mail queue: 1957888 bytes < 1.5*message size limit
Feb 10 01:16:14 erld671x postfix/cleanup[6618]: 1F41144BAF6B: 
message-id=<20090210001614.1f41144ba...@erld671x.erlf.siemens.de>
Feb 10 01:16:14 erld671x postfix/qmgr[10111]: 1F41144BAF6B: 
from=, size=958, nrcpt=1 (queue active)
Feb 10 01:16:14 erld671x postfix/smtpd[6621]: disconnect from 
erld603x.erlf.siemens.de[194.138.228.203]
Feb 10 01:16:14 erld671x postfix/smtp[6620]: 1F41144BAF6B: 
to=, orig_to=, 
relay=mailrelay.erlf.siemens.de[194.138.228.204], delay=0, status=sent (250
Ok: queued as 23756637B4)
Feb 10 01:16:14 erld671x postfix/qmgr[10111]: 1F41144BAF6B: removed
Feb 10 01:16:14 erld671x postfix/smtpd[6621]: connect from 
erld604x.e

Re: Problems with Postfix / Round-Robin

[Wietse Venema]

Pablo Scheri:
> 
> Hi! I am not able to upload the files, I get a post error because
> I am exceeding the 4 characters.

> How can I send you the logs? May I upload them to rapidshare or
> something like that?

You can upload to:

ftp://ftp.porcupin.org/tmp/random/

files uploaded there cannot be "seen" or downloaded.

Wietse

RE: Problems with Postfix / Round-Robin

[Pablo Scheri]

Hi! I am not able to upload the files, I get a post error because I am 
exceeding the 4 characters.

How can I send you the logs? May I upload them to rapidshare or something like 
that?

Thanks!!

From: pablosch...@hotmail.com
To: postfix-users@postfix.org
Subject: RE: Problems with Postfix / Round-Robin
Date: Mon, 9 Feb 2009 17:53:14 -0200








Hi! thanks for the help and sorry for the delay.
I don´t know if i am able to send attachments, I will try.

I am attaching you the maillog, master.cf and main.cf

Thanks again.

Pablo.-

> Subject: Re: Problems with Postfix / Round-Robin
> To: postfix-users@postfix.org
> Date: Fri, 6 Feb 2009 12:53:29 -0500
> From: wie...@porcupine.org
> 
> Pablo Scheri:
> > 
> > dig mx trendargentina.com.ar.
> 
> Looks good...
> 
> > postconf | grep dns
> > 
> > disable_dns_lookups = no
> > lmtp_host_lookup = dns
> > smtp_host_lookup = dns
> 
> It's using DNS
> 
> > ---
> > grep '10\.0\.0\.20..:25' /var/log/maillog | grep -v status=
> > 
> > No result.
> 
> OK so this was supposed to match
> 
>   [10.0.0.207]:25 without status=
>   [10.0.0.208]:25 without status=
> 
> (that's why there were two dots in the pattern).
> 
> If there are no such records, then the Postfix SMTP client 
> does not connect to one box after having tried the other first.
> 
> To find out why random DNS is not working, we need verbose logging
> 
> # postconf -e debug_peer_list=10.0.0.207 debug_peer_level=1
> 
>   Wietse

¡Ahora conoce el nuevo Messenger! Hotmail está totalmente renovado.
_
Disfruta los mejores contenidos en MSN Video
http://video.msn.com/?mkt=es-xl

Re: Massive Double Bounce problems

[Wietse Venema]

Thomas Glanzmann:
> I still don't get why postfix sends me a soft bounce to notify me that
> I'm running out of diskspace. 

Have you looked at the LOGFILE?

> that softbounce and so on until I'm out of resources. Shouldn't postfix
> detect that this is a tempfailure and do exactly nothing and retry a few
> hours later? Again this was with postfix version 2.1.1.

Not if you turn on postmaster notification for resource problems.

Wietse

Re: DNS lookups not working?

[jan gestre]

On Tue, Feb 10, 2009 at 9:58 PM, Wietse Venema  wrote:
> jan gestre:
>> On Tue, Feb 10, 2009 at 7:44 PM, Wietse Venema  wrote:
>> > David Cottle:
>> > [ Charset ISO-8859-1 unsupported, converting... ]
>> >> -BEGIN PGP SIGNED MESSAGE-
>> >> Hash: SHA1
>> >>
>> >> All,
>> >>
>> >> I see this a lot in my mail.log (unknown):
>> >>
>> >> Feb 10 20:38:28 server postfix/smtpd[21977]: connect from
>> >> unknown[72.4.168.106]
>> >> Feb 10 09:38:30 server postfix/smtpd[21977]: NOQUEUE: reject: RCPT
>> >> from unknown[72.4.168.106]: 554 5.7.1 Service unavailable; Client host
>> >
>> > Try: http://www.postfix.org/DEBUG_README.html#no_chroot. If it
>> > works, send a complaint to your vendor. I, the Postfix author, do
>> > not recommend that chroot is turned on except by experts.
>> >
>> >Wietse
>> >
>> > Try turning off chroot operation in master.cf
>> > =
>> >
>> > A common mistake is to turn on chroot operation in the master.cf
>> > file without going through all the necessary steps to set up a
>> > chroot environment. This causes Postfix daemon processes to fail
>> > due to all kinds of missing files.
>> >
>> > The example below shows an SMTP server that is configured with
>> > chroot turned off:
>> >
>> >/etc/postfix/master.cf:
>> ># =
>> ># service type  private unpriv  chroot  wakeup  maxproc command
>> >#   (yes)   (yes)   (yes)   (never) (100)
>> ># =
>> >smtp  inet  n   -   n   -   -   smtpd
>> >
>> > Inspect master.cf for any processes that have chroot operation not
>> > turned off. If you find any, save a copy of the master.cf file,
>> > and edit the entries in question. After executing the command
>> > "postfix reload", see if the problem has gone away.
>> >
>> > If turning off chrooted operation made the problem go away, then
>> > congratulations. Leaving Postfix running in this way is adequate
>> > for most sites. If you prefer chrooted operation, see the Postfix
>> > BASIC_CONFIGURATION_README file for information about how to prepare
>> > Postfix for chrooted operation.
>> >
>>
>> I have this same problem that I was not able to solve for almost a
>> week now. I posted too on various mailing lists including this (mail
>> from gmail and yahoo are blocked), some suggested to install a caching
>> nameserver but obviously in your case it doesn't work too. Replaced
>> OpenDNS with other DNS server to no avail, still the same result. If
>> rbl is enabled all incoming emails were blocked so I have no recourse
>> but to turn it off, caveat is I've got lots of SPAM. Also I don't have
>> Postfix in chroot environment.
>>
>> Here's my log:
>>
>> Feb 10 21:34:46 kartero postfix/smtpd[14176]: NOQUEUE: reject: RCPT
>> from wf-out-1314.google.com[209.85.200.172]: 554 5.7.1 Service
>> unavailable; Client host [209.85.200.172] blocked using
>> bl.spamcop.net; from=
>> to= proto=ESMTP helo=
>
> This thread is about CLIENT names logged as UNKNOWN,
>
> You are having a problem with a DNS server that produces bogus replies
> for non-existent hostnames. You can twiddle with Postfix configurations
> until the cows come home. It will not make an iota of difference.
>
>Wietse
>

I apologize for that, I thought it's the same.

Re: DNS lookups not working?

[Kenneth Marshall]

On Tue, Feb 10, 2009 at 09:50:26PM +0800, jan gestre wrote:
> On Tue, Feb 10, 2009 at 7:44 PM, Wietse Venema  wrote:
> > David Cottle:
> > [ Charset ISO-8859-1 unsupported, converting... ]
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >>
> >> All,
> >>
> >> I see this a lot in my mail.log (unknown):
> >>
> >> Feb 10 20:38:28 server postfix/smtpd[21977]: connect from
> >> unknown[72.4.168.106]
> >> Feb 10 09:38:30 server postfix/smtpd[21977]: NOQUEUE: reject: RCPT
> >> from unknown[72.4.168.106]: 554 5.7.1 Service unavailable; Client host
> >
> > Try: http://www.postfix.org/DEBUG_README.html#no_chroot. If it
> > works, send a complaint to your vendor. I, the Postfix author, do
> > not recommend that chroot is turned on except by experts.
> >
> >Wietse
> >
> > Try turning off chroot operation in master.cf
> > =
> >
> > A common mistake is to turn on chroot operation in the master.cf
> > file without going through all the necessary steps to set up a
> > chroot environment. This causes Postfix daemon processes to fail
> > due to all kinds of missing files.
> >
> > The example below shows an SMTP server that is configured with
> > chroot turned off:
> >
> >/etc/postfix/master.cf:
> ># =
> ># service type  private unpriv  chroot  wakeup  maxproc command
> >#   (yes)   (yes)   (yes)   (never) (100)
> ># =
> >smtp  inet  n   -   n   -   -   smtpd
> >
> > Inspect master.cf for any processes that have chroot operation not
> > turned off. If you find any, save a copy of the master.cf file,
> > and edit the entries in question. After executing the command
> > "postfix reload", see if the problem has gone away.
> >
> > If turning off chrooted operation made the problem go away, then
> > congratulations. Leaving Postfix running in this way is adequate
> > for most sites. If you prefer chrooted operation, see the Postfix
> > BASIC_CONFIGURATION_README file for information about how to prepare
> > Postfix for chrooted operation.
> >
> 
> I have this same problem that I was not able to solve for almost a
> week now. I posted too on various mailing lists including this (mail
> from gmail and yahoo are blocked), some suggested to install a caching
> nameserver but obviously in your case it doesn't work too. Replaced
> OpenDNS with other DNS server to no avail, still the same result. If
> rbl is enabled all incoming emails were blocked so I have no recourse
> but to turn it off, caveat is I've got lots of SPAM. Also I don't have
> Postfix in chroot environment.
> 
> Here's my log:
> 
> Feb 10 21:34:46 kartero postfix/smtpd[14176]: NOQUEUE: reject: RCPT
> from wf-out-1314.google.com[209.85.200.172]: 554 5.7.1 Service
> unavailable; Client host [209.85.200.172] blocked using
> bl.spamcop.net; from=
> to= proto=ESMTP helo=
> 
You may want to use something like policyd-weight to moderate the
effects of a single RBL. It can be configured to require several
RBL's or message characteristics to be valid before the message is
rejected. It also allows you to adjust the reject threshold to
minimize false-positive responses.

Cheers,
Ken

Re: Getting localhost put in my From field

[Xn Nooby]

On Tue, Feb 10, 2009 at 8:05 AM, Wietse Venema  wrote:
> Xn Nooby:
>> I have been trying to figure out how to get Postfix to not append
>> "localhost" in to the From: field. I am sending email mostly between
>> two local users, using RHEL5/Squirrelmail/Postfix/Dovecot.
>>
>> When I send an email from
>>
>>   user_...@schoolretail.local
>>
>> to
>>
>>   user_...@schoolretail.local
>>
>> it arrives from
>>
>>   user_...@localhost.schoolretail.local
>
> Why do you believe that Postfix does this? Please do not confuse
> the messenger (Postfix) with the news itself (a broken address).
>
>Wietse
>

You were correct, I had to set the "site name" in squirrelmail!

thanks!

Re: Massive Double Bounce problems

[Thomas Glanzmann]

Hello Wietse,

* Wietse Venema  [090210 14:55]:
> Thomas Glanzmann:
> >  Out: 220 erld671x.erlf.siemens.de ESMTP Postfix
> >  In:  EHLO erld603x.erlf.siemens.de
> >  Out: 250-erld671x.erlf.siemens.de
> >  Out: 250-PIPELINING
> >  Out: 250-SIZE 104857600
> >  Out: 250-VRFY
> >  Out: 250-ETRN
> >  Out: 250 8BITMIME
> >  In:  MAIL FROM: SIZE=1191
> >  Out: 452 Insufficient system storage
> >  In:  RCPT TO:
> ...
> > What I don't get here is that the postfix version on erld604x does seem
> > to ignore the tempfailure on erld671x (452 Insufficient system storage)

> See RFC 1854 (SMTP command pipelining) which was released in 1995.
> You are getting the message because of "Insufficient system storage".

I still don't get why postfix sends me a soft bounce to notify me that
I'm running out of diskspace. And after that sends me a softbounce for
that softbounce and so on until I'm out of resources. Shouldn't postfix
detect that this is a tempfailure and do exactly nothing and retry a few
hours later? Again this was with postfix version 2.1.1.

Thomas

Re: DNS lookups not working?

[Wietse Venema]

jan gestre:
> On Tue, Feb 10, 2009 at 7:44 PM, Wietse Venema  wrote:
> > David Cottle:
> > [ Charset ISO-8859-1 unsupported, converting... ]
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >>
> >> All,
> >>
> >> I see this a lot in my mail.log (unknown):
> >>
> >> Feb 10 20:38:28 server postfix/smtpd[21977]: connect from
> >> unknown[72.4.168.106]
> >> Feb 10 09:38:30 server postfix/smtpd[21977]: NOQUEUE: reject: RCPT
> >> from unknown[72.4.168.106]: 554 5.7.1 Service unavailable; Client host
> >
> > Try: http://www.postfix.org/DEBUG_README.html#no_chroot. If it
> > works, send a complaint to your vendor. I, the Postfix author, do
> > not recommend that chroot is turned on except by experts.
> >
> >Wietse
> >
> > Try turning off chroot operation in master.cf
> > =
> >
> > A common mistake is to turn on chroot operation in the master.cf
> > file without going through all the necessary steps to set up a
> > chroot environment. This causes Postfix daemon processes to fail
> > due to all kinds of missing files.
> >
> > The example below shows an SMTP server that is configured with
> > chroot turned off:
> >
> >/etc/postfix/master.cf:
> ># =
> ># service type  private unpriv  chroot  wakeup  maxproc command
> >#   (yes)   (yes)   (yes)   (never) (100)
> ># =
> >smtp  inet  n   -   n   -   -   smtpd
> >
> > Inspect master.cf for any processes that have chroot operation not
> > turned off. If you find any, save a copy of the master.cf file,
> > and edit the entries in question. After executing the command
> > "postfix reload", see if the problem has gone away.
> >
> > If turning off chrooted operation made the problem go away, then
> > congratulations. Leaving Postfix running in this way is adequate
> > for most sites. If you prefer chrooted operation, see the Postfix
> > BASIC_CONFIGURATION_README file for information about how to prepare
> > Postfix for chrooted operation.
> >
> 
> I have this same problem that I was not able to solve for almost a
> week now. I posted too on various mailing lists including this (mail
> from gmail and yahoo are blocked), some suggested to install a caching
> nameserver but obviously in your case it doesn't work too. Replaced
> OpenDNS with other DNS server to no avail, still the same result. If
> rbl is enabled all incoming emails were blocked so I have no recourse
> but to turn it off, caveat is I've got lots of SPAM. Also I don't have
> Postfix in chroot environment.
> 
> Here's my log:
> 
> Feb 10 21:34:46 kartero postfix/smtpd[14176]: NOQUEUE: reject: RCPT
> from wf-out-1314.google.com[209.85.200.172]: 554 5.7.1 Service
> unavailable; Client host [209.85.200.172] blocked using
> bl.spamcop.net; from=
> to= proto=ESMTP helo=

This thread is about CLIENT names logged as UNKNOWN,

You are having a problem with a DNS server that produces bogus replies
for non-existent hostnames. You can twiddle with Postfix configurations
until the cows come home. It will not make an iota of difference.

Wietse

Re: DNS lookups not working?

[John Peach]

On Tue, 10 Feb 2009 21:50:26 +0800
jan gestre  wrote:

[snip]
> I have this same problem that I was not able to solve for almost a
> week now. I posted too on various mailing lists including this (mail
> from gmail and yahoo are blocked), some suggested to install a caching
> nameserver but obviously in your case it doesn't work too. Replaced
> OpenDNS with other DNS server to no avail, still the same result. If
> rbl is enabled all incoming emails were blocked so I have no recourse
> but to turn it off, caveat is I've got lots of SPAM. Also I don't have
> Postfix in chroot environment.
> 
> Here's my log:
> 
> Feb 10 21:34:46 kartero postfix/smtpd[14176]: NOQUEUE: reject: RCPT
> from wf-out-1314.google.com[209.85.200.172]: 554 5.7.1 Service
> unavailable; Client host [209.85.200.172] blocked using
> bl.spamcop.net; from=
> to= proto=ESMTP helo=

It's working exactly as you configured it. If you want that mail,
remove bl.spamcop.net from your checks...

Re: Massive Double Bounce problems

[Wietse Venema]

Thomas Glanzmann:
>  Out: 220 erld671x.erlf.siemens.de ESMTP Postfix
>  In:  EHLO erld603x.erlf.siemens.de
>  Out: 250-erld671x.erlf.siemens.de
>  Out: 250-PIPELINING
>  Out: 250-SIZE 104857600
>  Out: 250-VRFY
>  Out: 250-ETRN
>  Out: 250 8BITMIME
>  In:  MAIL FROM: SIZE=1191
>  Out: 452 Insufficient system storage
>  In:  RCPT TO:
...
> What I don't get here is that the postfix version on erld604x does seem
> to ignore the tempfailure on erld671x (452 Insufficient system storage)

See RFC 1854 (SMTP command pipelining) which was released in 1995.

You are getting the message because of "Insufficient system storage".

Wietse

Re: DNS lookups not working?

[jan gestre]

On Tue, Feb 10, 2009 at 7:44 PM, Wietse Venema  wrote:
> David Cottle:
> [ Charset ISO-8859-1 unsupported, converting... ]
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> All,
>>
>> I see this a lot in my mail.log (unknown):
>>
>> Feb 10 20:38:28 server postfix/smtpd[21977]: connect from
>> unknown[72.4.168.106]
>> Feb 10 09:38:30 server postfix/smtpd[21977]: NOQUEUE: reject: RCPT
>> from unknown[72.4.168.106]: 554 5.7.1 Service unavailable; Client host
>
> Try: http://www.postfix.org/DEBUG_README.html#no_chroot. If it
> works, send a complaint to your vendor. I, the Postfix author, do
> not recommend that chroot is turned on except by experts.
>
>Wietse
>
> Try turning off chroot operation in master.cf
> =
>
> A common mistake is to turn on chroot operation in the master.cf
> file without going through all the necessary steps to set up a
> chroot environment. This causes Postfix daemon processes to fail
> due to all kinds of missing files.
>
> The example below shows an SMTP server that is configured with
> chroot turned off:
>
>/etc/postfix/master.cf:
># =
># service type  private unpriv  chroot  wakeup  maxproc command
>#   (yes)   (yes)   (yes)   (never) (100)
># =
>smtp  inet  n   -   n   -   -   smtpd
>
> Inspect master.cf for any processes that have chroot operation not
> turned off. If you find any, save a copy of the master.cf file,
> and edit the entries in question. After executing the command
> "postfix reload", see if the problem has gone away.
>
> If turning off chrooted operation made the problem go away, then
> congratulations. Leaving Postfix running in this way is adequate
> for most sites. If you prefer chrooted operation, see the Postfix
> BASIC_CONFIGURATION_README file for information about how to prepare
> Postfix for chrooted operation.
>

I have this same problem that I was not able to solve for almost a
week now. I posted too on various mailing lists including this (mail
from gmail and yahoo are blocked), some suggested to install a caching
nameserver but obviously in your case it doesn't work too. Replaced
OpenDNS with other DNS server to no avail, still the same result. If
rbl is enabled all incoming emails were blocked so I have no recourse
but to turn it off, caveat is I've got lots of SPAM. Also I don't have
Postfix in chroot environment.

Here's my log:

Feb 10 21:34:46 kartero postfix/smtpd[14176]: NOQUEUE: reject: RCPT
from wf-out-1314.google.com[209.85.200.172]: 554 5.7.1 Service
unavailable; Client host [209.85.200.172] blocked using
bl.spamcop.net; from=
to= proto=ESMTP helo=

Create additional sub-folders postfix/courier

[Gabriel Tartaglia]

Hi all

I have a mail server which is courier, postfix, amavisd, using Postgres db
and virtual mailboxes which I administer through postfixadmin.

I want to be able to add a set of default folders to all mailboxes created
such as Possible Spam and some others.

I have investigated shared folders but this is not what i want, is there a
way I can get courier/postfix to create a set of additional sub-folders when
it creates a mailbox.

All mailboxes are accessed as IMAP mailboxes.

Is this possible? if so where would I go about doing this?

Thanks

-- 
Gabriel Tartaglia Soares
Analista de Redes
Centro de Gestão do Conhecimento Organizacional - CGCO
Diretoria de Sistemas de Informação - DSI
Universidade Federal de Juiz de Fora - UFJF
Tel: +55-32-2102-3372
Fax: +55-32-2102-3371
VoIP: RNP-32-1180-8000

Massive Double Bounce problems

[Thomas Glanzmann]

Hello,
I have two postfix systems which generate a lot of double bounces. I was
able to extract such an e-mail using wireshark:

220 erld671x.erlf.siemens.de ESMTP Postfix
EHLO erld604x.erlf.siemens.de
250-erld671x.erlf.siemens.de
250-PIPELINING
250-SIZE 104857600
250-VRFY
250-ETRN
250 8BITMIME
MAIL FROM: SIZE=1191
RCPT TO:
DATA
250 Ok
250 Ok
354 End data with .
Received: from erld671x.erlf.siemens.de (erld671x.erlf.siemens.de 
[194.138.228.10])
.by erld604x.erlf.siemens.de (Postfix) with ESMTP id 9DF6A84657
.for ; Tue, 10 Feb 2009 06:32:40 +0100 
(CET)
Received: by erld671x.erlf.siemens.de (Postfix)
.id AE06C4569B11; Tue, 10 Feb 2009 06:26:44 +0100 (CET)
Date: Tue, 10 Feb 2009 06:26:44 +0100 (CET)
From: mailer-dae...@erlf.siemens.de (Mail Delivery System)
To: postmas...@erlf.siemens.de (Postmaster)
Subject: Postfix SMTP server: errors from 
erld603x.erlf.siemens.de[194.138.228.203]
Message-Id: <20090210052644.ae06c4569...@erld671x.erlf.siemens.de>

Transcript of session follows.

 Out: 220 erld671x.erlf.siemens.de ESMTP Postfix
 In:  EHLO erld603x.erlf.siemens.de
 Out: 250-erld671x.erlf.siemens.de
 Out: 250-PIPELINING
 Out: 250-SIZE 104857600
 Out: 250-VRFY
 Out: 250-ETRN
 Out: 250 8BITMIME
 In:  MAIL FROM: SIZE=1191
 Out: 452 Insufficient system storage
 In:  RCPT TO:
 Out: 503 Error: need MAIL command
 In:  DATA
 Out: 503 Error: need RCPT command
 In:  RSET
 Out: 250 Ok
 In:  QUIT
 Out: 221 Bye

.
QUIT
250 Ok: queued as BBB6B4599763
221 Bye

What I don't get here is that the postfix version on erld604x does seem
to ignore the tempfailure on erld671x (452 Insufficient system storage)
and tries to continue with the SMTP dialog. Now it gets an error (503
Error: need MAIL command) but only because it ignores the tempfailure
in the first case and generates a double bounce.

I just deleted 15 messages on each of our mail relays and 2 on
erld671x.  Can someone explain me what goes wrong here and if it is a
configuration problem or a known problem of postfix version 2.1.1?

Thomas

Re: Getting localhost put in my From field

[Wietse Venema]

Xn Nooby:
> I have been trying to figure out how to get Postfix to not append
> "localhost" in to the From: field. I am sending email mostly between
> two local users, using RHEL5/Squirrelmail/Postfix/Dovecot.
> 
> When I send an email from
> 
>   user_...@schoolretail.local
> 
> to
> 
>   user_...@schoolretail.local
> 
> it arrives from
> 
>   user_...@localhost.schoolretail.local

Why do you believe that Postfix does this? Please do not confuse
the messenger (Postfix) with the news itself (a broken address).

Wietse

Re: reject_unverified_sender vs greylisting

[Wietse Venema]

Juergen P. Meier:
> If everyone would use SAV, the ammount of SMTP traffic in the Internet
> would *double*. I bet most heavy duty mailssystems don't scale double.

Go ahead and make my day. What is the basis for this claim?

Wietse

Re: DNS lookups not working?

[Wietse Venema]

David Cottle:
[ Charset ISO-8859-1 unsupported, converting... ]
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> All,
> 
> I see this a lot in my mail.log (unknown):
> 
> Feb 10 20:38:28 server postfix/smtpd[21977]: connect from
> unknown[72.4.168.106]
> Feb 10 09:38:30 server postfix/smtpd[21977]: NOQUEUE: reject: RCPT
> from unknown[72.4.168.106]: 554 5.7.1 Service unavailable; Client host

Try: http://www.postfix.org/DEBUG_README.html#no_chroot. If it 
works, send a complaint to your vendor. I, the Postfix author, do
not recommend that chroot is turned on except by experts.

Wietse

Try turning off chroot operation in master.cf
=

A common mistake is to turn on chroot operation in the master.cf
file without going through all the necessary steps to set up a
chroot environment. This causes Postfix daemon processes to fail
due to all kinds of missing files.

The example below shows an SMTP server that is configured with
chroot turned off:

/etc/postfix/master.cf:
# =
# service type  private unpriv  chroot  wakeup  maxproc command
#   (yes)   (yes)   (yes)   (never) (100)
# =
smtp  inet  n   -   n   -   -   smtpd

Inspect master.cf for any processes that have chroot operation not
turned off. If you find any, save a copy of the master.cf file,
and edit the entries in question. After executing the command
"postfix reload", see if the problem has gone away.

If turning off chrooted operation made the problem go away, then
congratulations. Leaving Postfix running in this way is adequate
for most sites. If you prefer chrooted operation, see the Postfix
BASIC_CONFIGURATION_README file for information about how to prepare
Postfix for chrooted operation.

Re: DNS lookups not working?

[David Cottle]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Charles Marcus wrote:
> On 2/10/2009, David Cottle (webmas...@aus-city.com) wrote:
>> Feb 10 09:38:30 server postfix/smtpd[21977]: NOQUEUE: reject:
>> RCPT from unknown[72.4.168.106]: 554 5.7.1 Service unavailable;
>
> Are you usin the free zen service? If so, are you exceeding the
> limits they place on free usage?
>
Hi Charles,

Yes I am but I am not exceeding the usage.

Here are some from other servers:

Feb 10 11:38:40 server postfix/smtpd[32014]: connect from
unknown[61.90.76.4]
Feb 10 11:38:41 server postfix/smtpd[32014]: NOQUEUE: reject: RCPT
from unknown[61.90.76.4]: 554 5.7.1 Service unavailable; Client host
[61.90.76.4] blocked using zen.spamhaus.org;
http://www.spamhaus.org/query/bl?ip=61.90.76.4;
from=
to= proto=ESMTP
helo=
Feb 10 22:38:42 server spamd[3422]: spamd: got connection over
/tmp/spamd_full.sock
Feb 10 11:38:42 server postfix/smtpd[32014]: lost connection after
DATA (0 bytes) from unknown[61.90.76.4]
Feb 10 11:38:42 server postfix/smtpd[32014]: disconnect from
unknown[61.90.76.4]
Feb 10 22:38:42 server spamd[28616]: prefork: child states: II
Feb 10 11:38:47 server postfix/smtpd[32013]: connect from
unknown[86.55.226.169]
Feb 10 22:38:49 server imapd: Connection, ip=[127.0.0.1]
Feb 10 22:38:49 server imapd: IMAP connect from @ [127.0.0.1]INFO:
LOGIN, user=webmas...@aus-city.com, ip=[127.0.0.1], protocol=IMAP
Feb 10 11:38:49 server postfix/smtpd[32013]: NOQUEUE: reject: RCPT
from unknown[86.55.226.169]: 554 5.7.1 Service unavailable; Client
host [86.55.226.169] blocked using bl.spamcop.net; Blocked - see
http://www.spamcop.net/bl.shtml?86.55.226.169;
from= to=
proto=ESMTP helo=


Feb 10 11:30:14 server postfix/smtpd[31747]: NOQUEUE: reject: RCPT
from unknown[94.181.24.220]: 554 5.7.1 Service unavailable; Client
host [94.181.24.220] blocked using zen.spamhaus.org;
http://www.spamhaus.org/query/bl?ip=94.181.24.220;
from= to= proto=ESMTP
helo=
Feb 10 11:30:14 server postfix/smtpd[31747]: NOQUEUE: reject: RCPT
from unknown[94.181.24.220]: 554 5.7.1 Service unavailable; Client
host [94.181.24.220] blocked using zen.spamhaus.org;
http://www.spamhaus.org/query/bl?ip=94.181.24.220;
from= to= proto=ESMTP
helo=
Feb 10 11:30:15 server postfix/smtpd[31747]: lost connection after
DATA (0 bytes) from unknown[94.181.24.220]
Feb 10 11:30:15 server postfix/smtpd[31747]: disconnect from
unknown[94.181.24.220]
Feb 10 11:30:18 server postfix/smtpd[31747]: connect from
unknown[88.239.131.191]
Feb 10 11:30:21 server postfix/smtpd[31747]: NOQUEUE: reject: RCPT
from unknown[88.239.131.191]: 554 5.7.1 Service unavailable; Client
host [88.239.131.191] blocked using bl.spamcop.net; Blocked - see
http://www.spamcop.net/bl.shtml?88.239.131.191; from=
to= proto=SMTP helo=
Feb 10 11:30:22 server postfix/smtpd[31747]: disconnect from
unknown[88.239.131.191]
Feb 10 22:30:28 server imapd: Connection, ip=[127.0.0.1]

Thanks!
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEUEARECAAYFAkmRaHcACgkQi1lOcz5YUMgZRACXU33RVYGSn0JUiIvz8xRxckKq
QgCZAUbaiOL8gA9dWP0Ko8QaVBFc7PU=
=5s1C
-END PGP SIGNATURE-

begin:vcard
fn:David Cottle
n:Cottle;David
email;internet:webmas...@aus-city.com
title:Webmaster
version:2.1
end:vcard

How to allow mails from some other servers to pass: reject_sender_login_mismatch

[an...@iguanait.com]

Hi,

i'm trying to slow down and block backscater mails and i try to use:
reject_sender_login_mismatch and smtpd_sender_login_maps.

I have some questions about how to pass this restriction for some cases.
The situation is this:

We have some other servers where we have installed other webapplication
that send mail from there using for example i...@ourdomain.com without
authentication.
These mails are sending to our mail server, but now we filter all these
addresses to prevent using our addresses in MAIL FROM to send mails to
us.

How to allow these servers to pass the rule
reject_sender_login_mismatch?

We have this configuration for sernder restrictions:

smtpd_sender_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
check_sender_access hash:/etc/postfix/access,
#   reject_sender_login_mismatch,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
reject_unauth_pipelining,
permit

i have commented out the parameter, temporary until i find out how to
solve this problem.

I added in access file this kind of entry:
serveripaddress OK

but this does not help, i got mailer-daemon mail when other server sent
mail.

Thanks in advanced!
Regards, Ali Nebi!

Re: reject_unverified_sender vs greylisting

[João Miguel Neves]

Charles Marcus escreveu:
> On 2/10/2009, João Miguel Neves (joao.ne...@intraneia.com) wrote:
>   
>> Right now, I'm preparing my top 10 domains used in spam and enabling SAV
>> for those.
>> 
>
> Do you have their PERMISSION? If not, then DON'T... otherwise you risk
> getting BLACKLISTED. I know that *I* will blackilist you for doing this,
> and so will many, many others.
>
> Did you read the info at the link I provided?
>
> Using SAV just 'passes the buck' - please STOP passing YOUR problem on
> to other INNOCENTS.
>
> Besides, there are many other far more effective ways of minimizing spam.
>   
Just a notice: I have SAV disabled, I'm studying in detail the link you
gave me and other information and trying to teach myself about SAV
before I touch it again. I'll come back to this list with my
conclusions, as it might be useful for someone else.

Thanks,
João Miguel Neves

-- 
Intraneia
http://www.intraneia.com/

Suporte a Software Livre
Tradução/Localização de software e sítios web
Desenvolvimento de software

Ao seu serviço...

Re: reject_unverified_sender vs greylisting

[Charles Marcus]

On 2/10/2009, João Miguel Neves (joao.ne...@intraneia.com) wrote:
> Right now, I'm preparing my top 10 domains used in spam and enabling SAV
> for those.

Do you have their PERMISSION? If not, then DON'T... otherwise you risk
getting BLACKLISTED. I know that *I* will blackilist you for doing this,
and so will many, many others.

Did you read the info at the link I provided?

Using SAV just 'passes the buck' - please STOP passing YOUR problem on
to other INNOCENTS.

Besides, there are many other far more effective ways of minimizing spam.

-- 

Best regards,

Charles

Re: reject_unverified_sender vs greylisting

[João Miguel Neves]

Juergen P. Meier escreveu:
> SAV is a nice idea if run against a limited set of trusted domains (who's
> postmasters expclitly allow you to perform these Lookups), but it's not
> such a good idea in general.
> If everyone would use SAV, the ammount of SMTP traffic in the Internet
> would *double*. I bet most heavy duty mailssystems don't scale double.
>   
I've seen this argument before, so I'd just like to notice that, IF that
traffic avoids a bounce message, the number of mail on the Internet
doubles only in the worst case, staying the same IF the filtering avoids
bounce messages.

I'm still analyzing SAV and it has some serious potential issues
(potential as in, I haven't studied it thoroughly).
>  
>   
>> I'm going to reduce the target domains, but is there a known agreement
>> with MS, Google or Yahoo to use SAV against their servers?
>> 
>
> Ask their Postmasters/Admins. If they say it's ok, do it.
>   
I'll try. Maybe I'll get an answer for the first time from them.

Thanks and best regards,
João Miguel Neves

-- 
Intraneia
http://www.intraneia.com/

Suporte a Software Livre
Tradução/Localização de software e sítios web
Desenvolvimento de software

Ao seu serviço...

Re: reject_unverified_sender vs greylisting

[João Miguel Neves]

mouss escreveu:
> João Miguel Neves a écrit :
>   
>> Charles Marcus escreveu:
>> 
>>> On 2/8/2009, João Miguel Neves (joao.ne...@intraneia.com) wrote:
>>>   
>>>   
 I recently enabled reject_unverified_sender in my postfix configuration,
 but it seems like it fails when the server against which the sender is
 verified uses greylisting. I've been getting log entries like (@ were
 replaced by _AT_):
 
 
>>> You're not trying to verify ALL senders are you? This ia a really bad
>>> idea, and will get you blacklisted by a lot of providers, especially if
>>> you have high traffic .
>>>   
>>>   
>> Yes, I was. Thanks for the heads up. I don't have high traffic, but I'm
>> limiting the effect of SAV.
>> 
>
> and how do you limit it? 71.66.121.221 is listed on zen.spamhaus.org
> (via cbl) and spamcop (as well as Barracuda BRBL, SORBS, ... etc). it is
> also a residential IP as can be seen from the rDNS (.res.rr.com).
>   
Right now, I'm preparing my top 10 domains used in spam and enabling SAV
for those.
>>> You should only perform SAV against servers that YOU control, or at
>>> least have an agreement ahead of time with them.
>>>   
>>>   
>> That would mean that the most useful use of SAV is negated. Or is there
>> some prior arrangement that would allow me to do that to hotmail.com,
>> gmail.com, yahoo.com*?
>>
>> I'm going to reduce the target domains, but is there a known agreement
>> with MS, Google or Yahoo to use SAV against their servers?
>> 
>
> No, and it won't help you anyway. spammers can easily use a valid
> address. and these domains have too many users that most addresses
> you'll test are valid! (did you never see the "sorry, this account is
> not available" when trying to open an account?).
>   
Picking up some data from 4h when SAV was enabled from all users I get:

426 delivered emails
1742 rejected emails
985 rejects from sender checks from which:
302 were queued at the sender for SAV unverified results (*)
671 were queued at the sender for SAV undeliverable results

Maybe is SHOULDN'T help, but seems like a LOT of spam is still coming
from non-existing addresses (about 31% of the total email).

(*) this is the number that scares me a bit - it can be thanks to
greylisting, or possibly a loop caused by other server using SAV. I'm
checking into that.

Best regards,
João Miguel Neves

-- 
Intraneia
http://www.intraneia.com/

Suporte a Software Livre
Tradução/Localização de software e sítios web
Desenvolvimento de software

Ao seu serviço...

Re: DNS lookups not working?

[Charles Marcus]

On 2/10/2009, David Cottle (webmas...@aus-city.com) wrote:
> Feb 10 09:38:30 server postfix/smtpd[21977]: NOQUEUE: reject: RCPT
> from unknown[72.4.168.106]: 554 5.7.1 Service unavailable;

Are you usin the free zen service? If so, are you exceeding the limits
they place on free usage?

-- 

Best regards,

Charles

Re: Delaying some email addresses

[João Miguel Neves]

Victor Duchovni escreveu:
> On Mon, Feb 09, 2009 at 02:44:09PM +, Jo?o Miguel Neves wrote:
>
>   
>> Good morning,
>>
>> I'm using spamassassin thru amavisd. I also have a bunch of spamtraps
>> (addresses that were never used by persons, but that receive spam
>> regularly) feeding automatically its bayes filter. Sometimes I get some
>> spam that goes to regular addresses and to the spamtraps around the same
>> time. Is there a way or, what is the correct way of delaying some addresses?
>> 
>
> Don't "delay", if your "spamtrap" addresses are well chosen, have
> never existed as valid email addresses, and are unlikely to be mistyped
> accidentally by a human sender, you can just "REDIRECT" all mail for
> a spamtrap address to that same spamtrap address, this drops all the
> other recipients.
>   
That's a good addiction, but I already have that working.

What I'm trying is dealing with the spam sent for a single address. My
idea is the following:

1) Spammer sends emails to existing users and spamtraps;

2) Normal users email is frozen for 2 to 5 minutes;

3) Spamtraps are queued and teach spamassassin bayes filter;

4) Normal users email is unfrozen, spamassassin catches the spam, and it
doesn't reach the user mailbox.

Do a need to do a custom transport to do this?

Thanks in advance,
João Miguel Neves

-- 
Intraneia
http://www.intraneia.com/

Suporte a Software Livre
Tradução/Localização de software e sítios web
Desenvolvimento de software

Ao seu serviço...

DNS lookups not working?

[David Cottle]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

I see this a lot in my mail.log (unknown):

Feb 10 20:38:28 server postfix/smtpd[21977]: connect from
unknown[72.4.168.106]
Feb 10 09:38:30 server postfix/smtpd[21977]: NOQUEUE: reject: RCPT
from unknown[72.4.168.106]: 554 5.7.1 Service unavailable; Client host
[72.4.168.106] blocked using zen.spamhaus.org;
http://www.spamhaus.org/query/bl?ip=72.4.168.106;
from= to= proto=ESMTP
helo=
Feb 10 09:38:30 server postfix/smtpd[21977]: disconnect from
unknown[72.4.168.106]
Feb 10 09:38:40 server postfix/smtpd[21977]: connect from
unknown[80.65.83.20]
Feb 10 09:38:42 server postfix/smtpd[21977]: NOQUEUE: reject: RCPT
from unknown[80.65.83.20]: 554 5.7.1 Service unavailable; Client host
[80.65.83.20] blocked using bl.spamcop.net; Blocked - see
http://www.spamcop.net/bl.shtml?80.65.83.20;
from= to= proto=ESMTP
helo=
Feb 10 09:38:42 server postfix/smtpd[21977]: lost connection after
DATA (0 bytes) from unknown[80.65.83.20]
Feb 10 09:38:42 server postfix/smtpd[21977]: disconnect from
unknown[80.65.83.20]
Feb 10 09:38:45 server postfix/smtpd[21977]: connect from
unknown[80.65.83.20]
Feb 10 09:38:46 server postfix/smtpd[21977]: NOQUEUE: reject: RCPT
from unknown[80.65.83.20]: 554 5.7.1 Service unavailable; Client host
[80.65.83.20] blocked using bl.spamcop.net; Blocked - see
http://www.spamcop.net/bl.shtml?80.65.83.20;
from= to=
proto=ESMTP helo=
Feb 10 09:38:47 server postfix/smtpd[21977]: lost connection after
DATA (0 bytes) from unknown[80.65.83.20]
Feb 10 09:38:47 server postfix/smtpd[21977]: disconnect from
unknown[80.65.83.20]


I tried selinux off no difference (I do make my own local policy fromn
audits anyway).

postconf -n:

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases, hash:/var/spool/postfix/plesk/aliases
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
header_checks = regexp:/etc/postfix/header_checks
html_directory = no
inet_interfaces = all
inet_protocols = all
local_recipient_maps = $virtual_mailbox_maps
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 1024
mydestination = localhost.$mydomain, localhost, localhost.localdomain
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.5.6/README_FILES
sample_directory = /usr/share/doc/postfix-2.5.6/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_send_xforward_command = yes
smtp_tls_security_level = may
smtp_use_tls = no
smtpd_authorized_xforward_hosts = 127.0.0.0/8
smtpd_client_restrictions = check_client_access
hash:/etc/postfix/whitelist, check_sender_access
hash:/etc/postfix/check_backscatterer, check_sender_access
hash:/etc/postfix/check_spamcannibal, reject_rbl_client
bl.spamcop.net, reject_rbl_client zen.spamhaus.org, reject_rbl_client
b.barracudacentral.org
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated, reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sender_restrictions = check_sender_access
hash:/var/spool/postfix/plesk/blacklists, reject_non_fqdn_sender
smtpd_tls_cert_file = /etc/postfix/postfix_default.pem
smtpd_tls_key_file = $smtpd_tls_cert_file
smtpd_tls_security_level = may
smtpd_use_tls = yes
transport_maps = hash:/var/spool/postfix/plesk/transport
unknown_local_recipient_reject_code = 550
virtual_alias_maps = $virtual_maps, hash:/var/spool/postfix/plesk/virtual
virtual_gid_maps = static:31
virtual_mailbox_base = /var/qmail/mailnames
virtual_mailbox_domains = $virtual_mailbox_maps,
hash:/var/spool/postfix/plesk/virtual_domains
virtual_mailbox_maps = hash:/var/spool/postfix/plesk/vmailbox
virtual_transport = plesk_virtual
virtual_uid_maps = static:110


Here is a test showing my DNS works:

nslookup test.com > nslookup

Here is the file:

Server:10.0.10.1
Address:10.0.10.1#53

Non-authoritative answer:
Name:test.com
Address: 205.178.152.103

At first I found my resolv.conf had no nameservers in it (but the
server itself runs a DNS and nslookups were working anyway), I added
them but no difference..

Thanks!

David
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkmRTQwACgkQi1lOcz5YUMhXrQCePq58V8/j/j6axiQsa0CPUozi
PcEAn3NsQ5I3rTh6TJKvms1RILZNH4iP
=3FNf
-END PGP SIGNATURE-

begin:vcard
fn:David Cottle
n:Cottle;David
email;internet:webmas...@aus-city.com
title:Webmaster
version:2.1
end:vcard

relay through smtp and smtps

[gianlucabrt]

 Hi Sorry for my english. I have a mailserver with postfix, i am using as relay an smtp with authentication so i have installed SASL. All working fine but now for an account i have necessity that postfix send mails through an smtps relay. How can i do this?Some users use smtp with authentication and one smtps. I have read of ssl/stunnel and this work but is there a way to specify that one user use smtp and another smtps? thank you

Vuoi essere presente online? Vuoi dare voce alla tua attivita`? Acquista un dominio su domini.interfree.it.A partire da 18,59 euro

Re: Fwd: Re: TLS certificate

[Tolga]

On Fri, 6 Feb 2009 12:15:26 -0500, Victor Duchovni
 wrote:
> On Fri, Feb 06, 2009 at 07:13:17PM +0200, Tolga wrote:
> 
>> > Who can't use the certificate?
>> 
>> I, when I try with Thunderbird from another location.
> 
> Well, it is Thunderbird that needs to extend its list of trusted
> CAs not Postfix. No amount of tweaking the Postfix server will
> make Thunderbird trust your locally-minted CA.

You were right, I had to tweak Dovecot to offer the right certificate.

Regards,

/Tolga