Re: A better backscatter killer?

[Paweł Leśniak]

W dniu 2009-04-14 08:06, Ralf Hildebrandt pisze:

They are retarded. mail.charite.de is listed in it.
   

You're definitely not right.
Testresult for 141.42.4.200:

This IP IS CURRENTLY NOT LISTED in our Database.

B U T, it was listed in the past !

History:
2008/05/13 08:49listed
2008/06/10 09:30expired
2008/07/08 09:38listed
2008/08/22 11:30expired
2009/03/02 17:00listed
2009/04/12 13:07expired

If they send too many bounces, or do SAV, they are listed on 
backscatterer.org. That's simple.


Further - BECAUSE they are sending too many bounces it's quite good to 
stop receiving bounces from them.


Anyways, I've found that backscatterer.org is able to stop large flows 
of backscatter if they happen. When I was getting backscatter from many 
different IPs, backscatterer.org was not helping at all. But that's when 
body_checks work perfectly. As long as I'm a small site with ~10-20k 
SMTP connections daily, I'm fine with this configuration. Also I've 
found that 2 months after starting to use body_checks, the number of 
rejects lowered dramatically from ~15-45k daily to ~10-18k daily. More 
precisely number of rejects lowered from ~850k in january to ~410k in march.


Pawel Lesniak

Re: MAILS NOT GETTING REJECTED

[Ralf Hildebrandt]

* Ashwin Muni :
> Hi
> 
> I want to reject mails those which are not specified in virtual_alias_maps
> Have tried
> 
> smtpd_recipient_restrictions =
>  permit_mynetworks,
>  reject_unlisted_recipient
>  check_relay_domains
>  reject_unknown_recipient_domain,
>  check_sender_access hash:/etc/postfix/dbs/sender_access-accept
>  check_recipient_access hash:/etc/postfix/dbs/chk_rcpt_acc,
>  reject_unauth_destination

Make that

smtpd_recipient_restrictions =
  permit_mynetworks,
  reject_unauth_destination
  reject_unlisted_recipient
  reject_unknown_recipient_domain,
  check_sender_access hash:/etc/postfix/dbs/sender_access-accept
  check_recipient_access hash:/etc/postfix/dbs/chk_rcpt_acc,

> 
> But Still i am able to receive mail those not specfied in virtual_alias_maps
> 
> [r...@localhost postfix]# telnet localhost 25

A test from localhost is not very smart, since it's in mynetworks
(usually)

-- 
Ralf Hildebrandt
Postfix - Einrichtung, Betrieb und Wartung   Tel. +49 (0)30-450 570-155
http://www.computerbeschimpfung.de
What is this "XP pro"? Does this make "XP" unprofessional?

MAILS NOT GETTING REJECTED

[Ashwin Muni]

Hi

I want to reject mails those which are not specified in virtual_alias_maps
Have tried

smtpd_recipient_restrictions =
 permit_mynetworks,
 reject_unlisted_recipient
 check_relay_domains
 reject_unknown_recipient_domain,
 check_sender_access hash:/etc/postfix/dbs/sender_access-accept
 check_recipient_access hash:/etc/postfix/dbs/chk_rcpt_acc,
 reject_unauth_destination


But Still i am able to receive mail those not specfied in virtual_alias_maps

[r...@localhost postfix]# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
220 snew.co.co.in ESMTP Postfix
mail from:ash...@ashwin.com
250 2.1.0 Ok
rcpt to:ash...@090970.com
250 2.1.5 Ok
data
354 End data with .
quit
.
250 2.0.0 Ok: queued as F15DAD5CAB
quit
221 2.0.0 Bye
Connection closed by foreign host.
--
Logs for the same

Apr 14 02:42:21 localhost postfix/qmgr[3034]: F15DAD5CAB:
from=, size=365, nrcpt=1 (queue active)
Apr 14 02:42:21 localhost postfix/smtp[3055]: F15DAD5CAB:
to=, relay=127.0.0.1[127.0.0.1]:20030, delay=19,
delays=19/0.01/0/0, dsn=2.0.0, status=sent (250 A00BF0BC0A2 queued for
delivery)
Apr 14 02:42:21 localhost postfix/qmgr[3034]: F15DAD5CAB: removed
Apr 14 02:42:23 localhost postfix/smtpd[3036]: disconnect from
unknown[127.0.0.1]

my virtual File  :

lc.in OK
lc.co.in OK
malsere.net OK

I want my postfix to accept mails for these 3 domains only.

Please let me know how to achieve that

-- 
Ashwin R.

Re: A better backscatter killer?

[Rod Whitworth]

On Tue, 14 Apr 2009 09:24:09 +0200, Pawe+‚ Le+›niak wrote:

>W dniu 2009-04-14 08:06, Ralf Hildebrandt pisze:
>> They are retarded. mail.charite.de is listed in it.
>>
>You're definitely not right.
>Testresult for 141.42.4.200:
>
>This IP IS CURRENTLY NOT LISTED in our Database.
>
>B U T, it was listed in the past !
>
>History:
>2008/05/13 08:49listed
>2008/06/10 09:30expired
>2008/07/08 09:38listed
>2008/08/22 11:30expired
>2009/03/02 17:00listed
>2009/04/12 13:07expired
>
>If they send too many bounces, or do SAV, they are listed on 
>backscatterer.org. That's simple.
>
>Further - BECAUSE they are sending too many bounces it's quite good to 
>stop receiving bounces from them.
>
>Anyways, I've found that backscatterer.org is able to stop large flows 
>of backscatter if they happen. When I was getting backscatter from many 
>different IPs, backscatterer.org was not helping at all. But that's when 
>body_checks work perfectly. As long as I'm a small site with ~10-20k 
>SMTP connections daily, I'm fine with this configuration. Also I've 
>found that 2 months after starting to use body_checks, the number of 
>rejects lowered dramatically from ~15-45k daily to ~10-18k daily. More 
>precisely number of rejects lowered from ~850k in january to ~410k in march.
>
>Pawel Lesniak
>

Oh dear, that's all really too much trouble. I have OpenBSD's spamd
running in front of my MTA. A script checks all greylisted entries for
invalid recipients with <> sender and tarpits them.

You cannot have a legitimate bounce going to an invalid sender for
bleedin' obvious reasons. So stick it to 'em.

It wastes resources on all the misconfigured bounce-instead-of-reject
dummies out there and places no load on my lovely Postfix server. Heh!

*** NOTE *** Please DO NOT CC me. I  subscribed to the list.
Mail to the sender address that does not originate at the list server is 
tarpitted. The reply-to: address is provided for those who feel compelled to 
reply off list. Thankyou.

Rod/
/earth: write failed, file system is full
cp: /earth/creatures: No space left on device

Re: A better backscatter killer?

[Rod Whitworth]

On Tue, 14 Apr 2009 12:27:55 +0200, Pawe+‚ Le+›niak wrote:

>W dniu 2009-04-14 11:56, Rod Whitworth pisze:
>> Oh dear, that's all really too much trouble. I have OpenBSD's spamd
>> running in front of my MTA. A script checks all greylisted entries for
>> invalid recipients with<>  sender and tarpits them.
>>
>If mail goes to invalid recipient it can be *rejected*. It's not really 
>dependent on sender.

Of course, but it is a low cost way of punishing the dills who don't
configure their MX properly.

>
>> You cannot have a legitimate bounce going to an invalid sender for
>> bleedin' obvious reasons. So stick it to 'em.
>>
>I hope you mean recipient not sender.

It was a forged sender (to the backscatter source) and in our case they
could not have been the true sender because they do not exist as valid
recipients of incoming mail. i.e. they are not our users.

Remember I did say that I was applying this to "null sender to
non-existing recipients" (who were purported to be the original
senders). We have about 60 spamtrap addresses. Most invented by
spammers.

> Are you sure that null sender is only used in bounces?

What else?

>
>> It wastes resources on all the misconfigured bounce-instead-of-reject
>> dummies out there and places no load on my lovely Postfix server. Heh!
>>
>Could you explain how? If you greylist those mails instead of rejecting, 
>you are getting additional SMTP connection(s). If you reject them, they 
>are discarded. What am I missing?

They are detected whilst they are in the greylist and then they are
grey-trapped (tar-pitted in other words)

>> Rod/
>> /earth: write failed, file system is full
>> cp: /earth/creatures: No space left on device
>>
>Check your storage.

Check the population of /earth for yourself ... ;-(

*** NOTE *** Please DO NOT CC me. I  subscribed to the list.
Mail to the sender address that does not originate at the list server is 
tarpitted. The reply-to: address is provided for those who feel compelled to 
reply off list. Thankyou.

Rod/
/earth: write failed, file system is full
cp: /earth/creatures: No space left on device

Re: A better backscatter killer?

[Paweł Leśniak]

W dniu 2009-04-14 11:56, Rod Whitworth pisze:

Oh dear, that's all really too much trouble. I have OpenBSD's spamd
running in front of my MTA. A script checks all greylisted entries for
invalid recipients with<>  sender and tarpits them.
   
If mail goes to invalid recipient it can be *rejected*. It's not really 
dependent on sender.



You cannot have a legitimate bounce going to an invalid sender for
bleedin' obvious reasons. So stick it to 'em.
   
I hope you mean recipient not sender. Are you sure that null sender is 
only used in bounces?



It wastes resources on all the misconfigured bounce-instead-of-reject
dummies out there and places no load on my lovely Postfix server. Heh!
   
Could you explain how? If you greylist those mails instead of rejecting, 
you are getting additional SMTP connection(s). If you reject them, they 
are discarded. What am I missing?

Rod/
/earth: write failed, file system is full
cp: /earth/creatures: No space left on device
   

Check your storage.

Pawel Lesniak

Re: A better backscatter killer?

[Paweł Leśniak]

W dniu 2009-04-14 13:54, Rod Whitworth pisze:


Remember I did say that I was applying this to "null sender to
non-existing recipients" (who were purported to be the original
senders). We have about 60 spamtrap addresses. Most invented by
spammers.
   
I'd imagine somewhat better usage of spam-traps then grey-jail. And if 
it's "system-wide" - read on.

Are you sure that null sender is only used in bounces?
 


What else?
   

- SAV
- Auto-replies   (...)Since in most cases it is not appropriate to 
respond to

   an automatic response, and the responder is not interested in
   delivery status messages, a MAIL FROM address of <> MAY be used for
   this purpose.(...)  RFC3834
- Any type of automated notifications (...)In some types of
   reporting messages for which a reply is likely to cause a mail loop
   (for example, mail delivery and nondelivery notifications), the
   reverse-path may be null (see section 3.7).(...)  RFC2821


It wastes resources on all the misconfigured bounce-instead-of-reject
dummies out there and places no load on my lovely Postfix server. Heh!

   

Could you explain how? If you greylist those mails instead of rejecting,
you are getting additional SMTP connection(s). If you reject them, they
are discarded. What am I missing?
 


They are detected whilst they are in the greylist and then they are
grey-trapped (tar-pitted in other words)
   
IMHO: You are wasting also your resources, and you are slowing down the 
network. While it's
almost sure the other side will not correct configuration, the prize is 
smaller than the price.

Rod/
/earth: write failed, file system is full
cp: /earth/creatures: No space left on device

   

Check your storage.
 


Check the population of /earth for yourself ... ;-(

   

There's still some room ;-)

Pawel Lesniak

reject

[Martin Schiøtz]

Hi

I have made a spamfilter server based on Postfix and MailScanner. I
wan't postfix to reject emails to email-addresses that does not exist
on our exchange server. I use a nice perl script that collects the
email-addresses from Exchange AD with LDAP.

main.cf:
--
transport_maps = hash:/etc/postfix/transport
relay_domains = example.com

smtpd_recipient_restrictions = check_recipient_access
hash:/etc/postfix/recipient_access
 reject
---

Everything works fine and mails are rejected as they are supposed to with:

554 554 5.7.1 : Recipient address rejected:
Access denied (state 14).

My question is - Can I also send a reason about why the email was
rejected. Something like 'User does not exist'?

-- 
Best regards
Martin Schiøtz

Re: reject

[Ralf Hildebrandt]

* Martin Schiøtz :
> Hi
> 
> I have made a spamfilter server based on Postfix and MailScanner. I
> wan't postfix to reject emails to email-addresses that does not exist
> on our exchange server. I use a nice perl script that collects the
> email-addresses from Exchange AD with LDAP.
> 
> main.cf:
> --
> transport_maps = hash:/etc/postfix/transport
> relay_domains = example.com
> 
> smtpd_recipient_restrictions = check_recipient_access
> hash:/etc/postfix/recipient_access
>  reject

No, use relay_recipient_maps

-- 
Ralf Hildebrandt
Postfix - Einrichtung, Betrieb und Wartung   Tel. +49 (0)30-450 570-155
http://www.computerbeschimpfung.de
I wish you'd tell me what kind of systems they're using instead,
because HP can't be doing much worse than Sun "would you like the
compiler or internet options with that" Microsystems, or Silicon "hey
be glad the support-contract number isn't a 1-900" Graphics. Then
there's Digital "It sucks in 64 bits, you can't suck in 64 bits
anywhere else" Equipment Corp (Did we mention it's 64 bits?). 

Re: Newbie configuration/installation question

[Tashfeen Ekram]

I installed it with apt-get install postfix and then choose "Internet Site" 
during the configuration. 
i have configured rails to use smtp.
config.action_mailer.smtp_settings = {
  :address    => 'localhost',
  :port   => 25,
  :domain => 'www.example.com',
}



- Original Message 
From: J Sloan 
To: postfix-users@postfix.org
Sent: Monday, April 13, 2009 5:45:40 PM
Subject: Re: Newbie configuration/installation question

Tashfeen Ekram wrote:
> I have installed Postfix on Ubuntu to use to only send emails for my
> rails application. My rails application is not able to connect to it.
> Could this be because sendmail is listeneing at port 20?
> also, what configuration would suit me best if I only want to send
> emails ant not receive. This is onyl for testing purposes on my own
> laptop.


Just to eliminate a lot of guesswork: when you say you "installed
postfix" did you do something like "apt-get install postfix" or click on
postfix to install via synaptic, or did you download a tarball from the
internet and build it yourself?

How is rails configured to send the mail - with the sendmail command, or
via an smtp connection to the local host?

Joe



 

concurrency smtp control

[Alexandre Carlim]

Hello,

I have a question, is there a way that i can control the number of
connection that is open whith another ISP from my relay ? For example. what
i'd like  to do is :

Delevery messages to gmail : open max 200 connections from my relay to gmail
Delivery messages to yahoo: open max 100 connections from my relay to yahoo
, etc ...

I don't like to set the same settings for all , Is it possible ?

Thanks
Alexandre Carlim

Re: concurrency smtp control

[Victor Duchovni]

On Tue, Apr 14, 2009 at 03:01:07PM -0300, Alexandre Carlim wrote:

> Hello,
> 
> I have a question, is there a way that i can control the number of
> connection that is open whith another ISP from my relay ? For example. what
> i'd like  to do is :
> 
> Delevery messages to gmail : open max 200 connections from my relay to gmail
> Delivery messages to yahoo: open max 100 connections from my relay to yahoo
> , etc ...
> 
> I don't like to set the same settings for all , Is it possible ?

Destination concurrency controlls are transport-wide not per-domain. To
specify a different concurrency limit, configure an additional transport.
Generally, the default limit of 20 is sufficient even for high volume
destinations. If you do routinely open 100 parallel connections to Yahoo,
or 200 to Google, they may not be amused.

-- 
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: Sender with invalid domain

[mouss]

Paweł Leśniak a écrit :
> W dniu 2009-04-13 22:46, mouss pisze:
>> does reject_unknown_sender_domain really reject that many spam (that is
>> not rejected by zen among other things)?
>>
> According to RFC1912:
> (...)
> 2.1 Inconsistent, Missing, or Bad Data
> Every Internet-reachable host *should* have a name.  The consequences of
> this are becoming more and more obvious.  Many services available on the
> Internet will not talk to you if you aren't correctly registered in the
> DNS.
> Make sure your PTR and A records match.  For every IP address, there
> should be a matching PTR record in the in-addr.arpa domain.
> (...)
> 
> Assuming that spam is a global problem, and above RFC is something to
> obey with, it's not really important how many spams we'll block with
> reject_unknown_sender_domain.

I disagree:
- I prefer to avoid dns checks if they don't bring me much
- My focus is on stopping spam, not on enforcing RFC conformance. I do
get legitimate mail from non conformant sites, and I do accept it.
- the sender DNS server may be under DoS attack, and I prefer not to add
to the trouble
- the sender may be forged, so I prefer not to knock the sender domain
DNS server unless it brings a reasonable value.


> If message is blocked with
> reject_unknown_sender_domain, it means sender's server has some problem
> with DNS configuration. It's of no cost to configure DNS records for
> mailserver, and it makes lots less questions to zen. If mailserver's
> admin doesn't care about DNS entries I don't feel any need to care about
> emails coming from this mailserver. 

possible, but most recipients don't care about DNS: they want legitimate
mail in. not so long ago, I have seen financial mail failing this check.
 this was due to a web app upgrade when the guy who did the upgrade
configured the (local) hostname, not realizing that it was used as the
sender domain. sure, they did something bad. but am I here to watch what
others are doing? certainly not...


> Fortunately all large public
> mailservers we're getting emails from have DNS records set up correctly.

and spammers seem to forge valid addresses, so the check looks useless
to me.

> On one of my mailservers I've got:
> 1859 x Client host rejected: cannot find your hostname
> 1861 x Client host rejected: cannot find your reverse hostname

these also reject legitimate mail. YMMV.

> 2466 x blocked using zen.spamhaus.org
> As given above I need less than half of questions to zen RBL. Of course
> these numbers can be quite different depending on configuration and type
> of email traffic.
> 
> In my opinion, *if* one can afford loosing some legitimate mails from
> hosts without correct DNS entries, reject_unknown_* rules are worth
> using. Still if mail gets rejected, sender has possibility to ask
> his/her mailserver's admin to solve the problem.
> 

it really depends on your situation. for my own mail, I can do whatever
I want (although I consider myself as my own customer, so I would fire
myself if my-other-self rejects a legitimate mail ;-). but for other
people's mail, a balance is needed: you may want to reject fully
conformant mail (because user doesn't want it, even if it is not spam!)
and you may want to accept mail from "weakly configured" sites.

Re: A better backscatter killer?

[mouss]

Ralf Hildebrandt a écrit :
> * MacShane, Tracy :
> 
>> Then you won't receive some genuine messages, both bounce and
>> non-bounce.
>>
>> Try the ips.backscatterer.org RBL; it works well for us.
>>
>> http://www.mailinglistarchive.com/postfix-users@postfix.org/msg57402.html
> 
> They are retarded. mail.charite.de is listed in it.
> 

and I guess postfix members would be bothered to block:
camomile.cloud9.net[168.100.1.3]
english-breakfast.cloud9.net[168.100.1.7]

$ host 3.1.100.168.ips.backscatterer.org
3.1.100.168.ips.backscatterer.org has address 127.0.0.2
$ host 7.1.100.168.ips.backscatterer.org
7.1.100.168.ips.backscatterer.org has address 127.0.0.2

so if one uses this list, then
- use a whitelist (dnswl and possibly local WL)
- use it in smtpd_data_restrictions to avoid blocking SAV sources. while
you may hate SAV, it's different than backscatter.

Re: A better backscatter killer?

[mouss]

Noel Jones a écrit :
> Dennis Carr wrote:
>> Looking at options here for eliminating backscatter. 
>> I've reviewed the Howto for this, but it only seems to be effective
>> against backscatter where one's home domain is forged - not too useful,
>> IMNSHO, because spammers aren't always going to forge the home domain.  
> 
> and how do you receive it otherwise?
> 

I guess he meant they don't forge the Received header.

>[snip]

Re: Sender with invalid domain

[Paweł Leśniak]

W dniu 2009-04-14 23:00, mouss pisze:

Paweł Leśniak a écrit :
   

W dniu 2009-04-13 22:46, mouss pisze:
 

does reject_unknown_sender_domain really reject that many spam (that is
not rejected by zen among other things)?

   

According to RFC1912:
(...)
2.1 Inconsistent, Missing, or Bad Data
Every Internet-reachable host *should* have a name.  The consequences of
this are becoming more and more obvious.  Many services available on the
Internet will not talk to you if you aren't correctly registered in the
DNS.
Make sure your PTR and A records match.  For every IP address, there
should be a matching PTR record in the in-addr.arpa domain.
(...)

Assuming that spam is a global problem, and above RFC is something to
obey with, it's not really important how many spams we'll block with
reject_unknown_sender_domain.
 


I disagree:
- I prefer to avoid dns checks if they don't bring me much
   

Look at numbers below. I think they bring a lot.

- My focus is on stopping spam, not on enforcing RFC conformance. I do
get legitimate mail from non conformant sites, and I do accept it.
   
Well. it depends on type of service. If I were an ISP, I think I'd take 
more care to avoid getting "false positives". As long as these are not 
RFC conformant, I won't call them legitimate emails.

- the sender DNS server may be under DoS attack, and I prefer not to add
to the trouble
   
Well, I do not agree with that. It's just one more DNS query from my 
host. It's far less offensive then sending single email to this site.

- the sender may be forged, so I prefer not to knock the sender domain
DNS server unless it brings a reasonable value.
   
You can't cure all sites your server is talking to. So you have to 
choose what you believe is best for you.

If message is blocked with
reject_unknown_sender_domain, it means sender's server has some problem
with DNS configuration. It's of no cost to configure DNS records for
mailserver, and it makes lots less questions to zen. If mailserver's
admin doesn't care about DNS entries I don't feel any need to care about
emails coming from this mailserver.
 


possible, but most recipients don't care about DNS: they want legitimate
mail in. not so long ago, I have seen financial mail failing this check.
  this was due to a web app upgrade when the guy who did the upgrade
configured the (local) hostname, not realizing that it was used as the
sender domain. sure, they did something bad. but am I here to watch what
others are doing? certainly not...
   
But these recipients care about amount of spam they get. If my server 
rejects some mails, the other side has to choose if they want me to get 
their mail or not. If there are not enough rules to stop spam, we have 
to obey with what we have (RFCs).



Fortunately all large public
mailservers we're getting emails from have DNS records set up correctly.
 


and spammers seem to forge valid addresses, so the check looks useless
to me.
   

How do they forge a client DNS A records consistent with PTR records?

On one of my mailservers I've got:
1859 x Client host rejected: cannot find your hostname
1861 x Client host rejected: cannot find your reverse hostname
 


these also reject legitimate mail. YMMV.
   
I'd call those "legitimate mail". Server *should* have DNS records. If 
client address has no DNS enrtries, it's RFC-ignorant.

In my opinion, *if* one can afford loosing some legitimate mails from
hosts without correct DNS entries, reject_unknown_* rules are worth
using. Still if mail gets rejected, sender has possibility to ask
his/her mailserver's admin to solve the problem.
 


it really depends on your situation. for my own mail, I can do whatever
I want (although I consider myself as my own customer, so I would fire
myself if my-other-self rejects a legitimate mail ;-). but for other
people's mail, a balance is needed: you may want to reject fully
conformant mail (because user doesn't want it, even if it is not spam!)
and you may want to accept mail from "weakly configured" sites.
   

I do agree with your last sentences in 100%.

Pawel Lesniak

Re: A better backscatter killer?

[Paweł Leśniak]

W dniu 2009-04-14 23:11, mouss pisze:

Ralf Hildebrandt a écrit :
   

* MacShane, Tracy:

 

Then you won't receive some genuine messages, both bounce and
non-bounce.

Try the ips.backscatterer.org RBL; it works well for us.

http://www.mailinglistarchive.com/postfix-users@postfix.org/msg57402.html
   

They are retarded. mail.charite.de is listed in it.

 


and I guess postfix members would be bothered to block:
camomile.cloud9.net[168.100.1.3]
english-breakfast.cloud9.net[168.100.1.7]

$ host 3.1.100.168.ips.backscatterer.org
3.1.100.168.ips.backscatterer.org has address 127.0.0.2
$ host 7.1.100.168.ips.backscatterer.org
7.1.100.168.ips.backscatterer.org has address 127.0.0.2

so if one uses this list, then
- use a whitelist (dnswl and possibly local WL)
- use it in smtpd_data_restrictions to avoid blocking SAV sources. while
you may hate SAV, it's different than backscatter.
   

I think that you're missing something.
I'm getting emails from this list as:
 -> 
Where's the place where emails would be rejected? Is this list doing SAV?
I'd even ask - is ANY list doing SAV? It's hard for me to imagine 
sending thousands of emails to users who had already confirmed email 
address during "registration".


Pawel Lesniak

Re: Sender with invalid domain

[mouss]

Paweł Leśniak a écrit :
> W dniu 2009-04-14 23:00, mouss pisze:
>> [snip]
>> and spammers seem to forge valid addresses, so the check looks useless
>> to me.
>>   
> How do they forge a client DNS A records consistent with PTR records?

I meant they use forged sender addresses where the domain is valid. for
example, you may get spam with the sender set to .

>[snip]

Re: A better backscatter killer?

[mouss]

Paweł Leśniak a écrit :
> W dniu 2009-04-14 23:11, mouss pisze:
>> Ralf Hildebrandt a écrit :
>>   
>>> * MacShane, Tracy :
>>>
>>> 
 Then you won't receive some genuine messages, both bounce and
 non-bounce.

 Try the ips.backscatterer.org RBL; it works well for us.

 http://www.mailinglistarchive.com/postfix-users@postfix.org/msg57402.html
   
>>> They are retarded. mail.charite.de is listed in it.
>>>
>>> 
>>
>> and I guess postfix members would be bothered to block:
>>  camomile.cloud9.net[168.100.1.3]
>>  english-breakfast.cloud9.net[168.100.1.7]
>>
>> $ host 3.1.100.168.ips.backscatterer.org
>> 3.1.100.168.ips.backscatterer.org has address 127.0.0.2
>> $ host 7.1.100.168.ips.backscatterer.org
>> 7.1.100.168.ips.backscatterer.org has address 127.0.0.2
>>
>> so if one uses this list, then
>> - use a whitelist (dnswl and possibly local WL)
>> - use it in smtpd_data_restrictions to avoid blocking SAV sources. while
>> you may hate SAV, it's different than backscatter.
>>   
> I think that you're missing something.
> I'm getting emails from this list as:
>  -> 

it doesn't matter. if you block bounces from the server, you'll block
all bounces, be them legitimate or backscatter.

the problem with backscatterer.org is that we have no idea why IPs are
listed. mixing SAV and backscatter sources is a bad idea. I am not a fan
of SAV, but this is a different problem than backscatter. anyway, let's
not discuss this here as it is off topic. feel free to contact me
offlist if you want.

> Where's the place where emails would be rejected? Is this list doing SAV?
> I'd even ask - is ANY list doing SAV? It's hard for me to imagine
> sending thousands of emails to users who had already confirmed email
> address during "registration".

unfortunately, there are a few issues:
- membership validation is done by the list manager software, at
delivery time, long after the "first" relay has accepted the message.
- most list managers use the From: header to validate membership

sure, the list of valid members may be exported to be used by the relay,
but it's not how things are done, and MLMs don't make it easy (the only
free one I know of that makes this easy is "sympa").

Re: Sender with invalid domain

[Paweł Leśniak]

W dniu 2009-04-14 23:47, mouss pisze:

Paweł Leśniak a écrit :
   

W dniu 2009-04-14 23:00, mouss pisze:
 

[snip]
and spammers seem to forge valid addresses, so the check looks useless
to me.

   

How do they forge a client DNS A records consistent with PTR records?
 


I meant they use forged sender addresses where the domain is valid. for
example, you may get spam with the sender set to.

   
Sure. If this will be sent from host without correct DNS entries it 
could be blocked with reject_unknown_*.

Anyways - question was about sender with *invalid* domain.

Pawel Lesniak

Re: A better backscatter killer?

[Noel Jones]

Paweł Leśniak wrote:
I'd even ask - is ANY list doing SAV? It's hard for me to imagine 
sending thousands of emails to users who had already confirmed email 
address during "registration".


Some lists accept posts from un sub scribed senders.  Some of
those lists do SAV.   Some of the sourceforge lists fall in
this category.  And yes, they probe registered senders too.
If you want to play with them, you need to accept their probes.

  -- Noel Jones

virtual alias problem

[Miles Fidelman]

Hi Folks,

I've been rebuilding a server that was working fine, but then crashed.  
In the process I've installed a newer (current) version of Postfix, and 
suddenly I'm seeing an aliasing problem that I've never seen before.  
Maybe somebody can help figure this out.


This has to do with the interactions between Postfix and my mailing list 
manager (sympa):


Key piece of information, messages from the outside, addressed to 
mfidel...@fidelman.net are properly delivered to my local mailbox:
mfidel...@fidelman.net is a virtual address that's mapped by 
virtual_alias_maps mfidelman

mfidelman, in turn is an alias (/etc/aliases) to my local mailbox
- mail, from outside, to mfidel...@fidelman.net - is delivered just fine

Here's what's NOT working:  a message addressed to 
blsparents-requ...@lists.neighborhoods.net SHOULD end up in my local 
mailbox, and it is, but it's ending up there as a BOUNCE.


The basic flow of events:


Incoming processing:
- received by postfix (for blsparents-requ...@lists.neighborhood.net - 
virtual address)

- passed to amavisd-new, clamav, spamassin
- returned marked clean
- postfix then delivers the message to sympa (reports: delivered to 
command:  /home/sympa/bin/queue blsparents-requ...@lists.neighborhood.net)

- this is corrent
- postfix deques the message


Sympa does it's thing - in this case looking up the email name 
associated with blsparents-requ...@lists.neighborhood.net
- in this case, sympa looks up the request address in its database, and 
generates a message to mfidel...@fidelman.net

- sympa passes this back to postfix via /usr/bin/sendmail
- here's where things get funny:

Apr 14 16:45:17 server1 postfix/pickup[6631]: A044638C281: uid=114 
from=
Apr 14 16:45:17 server1 postfix/cleanup[10504]: A044638C281: 
message-id=<49e4f58d.8030...@meetinghouse.net>
Apr 14 16:45:17 server1 postfix/qmgr[3990]: A044638C281: 
from=, size=1678, nrcpt=1 (queue 
active)
Apr 14 16:45:17 server1 postfix/error[10574]: A044638C281: 
to=, relay=none, delay=0.35, 
delays=0.34/0/0/0.01, dsn=5.0.0, status=bounced (User unknown in virtual 
alias table)


notice the "user unknown in virtual alias table" - even though, under 
other circumstances postfix processes this properly


Apr 14 16:45:17 server1 postfix/bounce[10544]: A044638C281: sender 
non-delivery notification: A6EAC38C289

Apr 14 16:45:17 server1 postfix/qmgr[3990]: A044638C281: removed

I ultimately receive a bounce message as follows (unimportant pieces 
removed):


From: mailer-dae...@server1.neighborhoods.net (Mail Delivery System)
X-Original-To: sympa-requ...@lists.neighborhood.net
Delivered-To: sympa-requ...@server1.neighborhoods.net

to postmaster which in turn aliases to my local mailbox>


Subject: Undelivered Mail Returned to Sender
To: sympa-requ...@lists.neighborhood.net
Auto-Submitted: auto-replied

This is the mail system at host server1.neighborhoods.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

  The mail system

: User unknown in virtual alias table


--
so... obviously something is messed up, but what

- under some circumstances mfidel...@fidelman.net is properly handled
- under other circumstances it's not recognized

any ideas what might be wrong, or tests to run to narrow things down?


Thanks very much,

Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: virtual alias problem

[Miles Fidelman]

missing piece of information (inserted below)

Miles Fidelman wrote:

Hi Folks,

I've been rebuilding a server that was working fine, but then 
crashed.  In the process I've installed a newer (current) version of 
Postfix, and suddenly I'm seeing an aliasing problem that I've never 
seen before.  Maybe somebody can help figure this out.


This has to do with the interactions between Postfix and my mailing 
list manager (sympa):


Key piece of information, messages from the outside, addressed to 
mfidel...@fidelman.net are properly delivered to my local mailbox:
mfidel...@fidelman.net is a virtual address that's mapped by 
virtual_alias_maps mfidelman

mfidelman, in turn is an alias (/etc/aliases) to my local mailbox
- mail, from outside, to mfidel...@fidelman.net - is delivered just fine

Here's what's NOT working:  a message addressed to 
blsparents-requ...@lists.neighborhoods.net SHOULD end up in my local 
mailbox, and it is, but it's ending up there as a BOUNCE.


The basic flow of events:


Incoming processing:
- received by postfix (for blsparents-requ...@lists.neighborhood.net - 
virtual address)

- passed to amavisd-new, clamav, spamassin
- returned marked clean
- postfix then delivers the message to sympa (reports: delivered to 
command:  /home/sympa/bin/queue 
blsparents-requ...@lists.neighborhood.net)

- this is corrent
- postfix deques the message


Sympa does it's thing - in this case looking up the email name 
associated with blsparents-requ...@lists.neighborhood.net
- in this case, sympa looks up the request address in its database, 
and generates a message to mfidel...@fidelman.net

- sympa passes this back to postfix via /usr/bin/sendmail
- here's where things get funny:

Apr 14 16:45:17 server1 postfix/pickup[6631]: A044638C281: uid=114 
from=
Apr 14 16:45:17 server1 postfix/cleanup[10504]: A044638C281: 
message-id=<49e4f58d.8030...@meetinghouse.net>
Apr 14 16:45:17 server1 postfix/qmgr[3990]: A044638C281: 
from=, size=1678, nrcpt=1 (queue 
active)
Apr 14 16:45:17 server1 postfix/error[10574]: A044638C281: 
to=, relay=none, delay=0.35, 
delays=0.34/0/0/0.01, dsn=5.0.0, status=bounced (User unknown in 
virtual alias table)


notice the "user unknown in virtual alias table" - even though, under 
other circumstances postfix processes this properly


Apr 14 16:45:17 server1 postfix/bounce[10544]: A044638C281: sender 
non-delivery notification: A6EAC38C289

Apr 14 16:45:17 server1 postfix/qmgr[3990]: A044638C281: removed

I ultimately receive a bounce message as follows (unimportant pieces 
removed):


From: mailer-dae...@server1.neighborhoods.net (Mail Delivery System)
X-Original-To: sympa-requ...@lists.neighborhood.net
Delivered-To: sympa-requ...@server1.neighborhoods.net

maps to postmaster which in turn aliases to my local mailbox>


Subject: Undelivered Mail Returned to Sender
To: sympa-requ...@lists.neighborhood.net
Auto-Submitted: auto-replied

This is the mail system at host server1.neighborhoods.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

  The mail system

: User unknown in virtual alias table



  The mail system

: User unknown in virtual alias table

Reporting-MTA: dns; server1.neighborhoods.net
X-Postfix-Queue-ID: A9CFB38C273
X-Postfix-Sender: rfc822; sympa-requ...@lists.neighborhood.net
Arrival-Date: Tue, 14 Apr 2009 18:10:17 -0400 (EDT)

Final-Recipient: rfc822; mfidel...@fidelman.net
Action: failed
Status: 5.0.0
Diagnostic-Code: X-Postfix; User unknown in virtual alias table







--
so... obviously something is messed up, but what

- under some circumstances mfidel...@fidelman.net is properly handled
- under other circumstances it's not recognized

any ideas what might be wrong, or tests to run to narrow things down?


Thanks very much,

Miles Fidelman




--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: virtual alias problem

[Wietse Venema]

Why don't you simply restore the Postfix configuration from backups,
and execute "postfix upgrade-configuration" to upgrade to the newer
Postfix?

A great deal of effort is put into keeping features compatible, so
that people like you don't have to play detective after an upgrade.

Let the system work for you, instead of you repeating the work.

Wietse

Re: virtual alias problem

[Miles Fidelman]

Wietse Venema wrote:

Why don't you simply restore the Postfix configuration from backups,
and execute "postfix upgrade-configuration" to upgrade to the newer
Postfix?

A great deal of effort is put into keeping features compatible, so
that people like you don't have to play detective after an upgrade.

Let the system work for you, instead of you repeating the work.

Wietse
  

well, partly because it was a VERY old configuration,

partly because I also upgraded amavisd-new, spamassassin and such - 
which require different "wiring" in master.cf


and partly because I didn't realize I could (I believe the technical 
term is "Doh" - accompanied by the sound of my hand hitting my forhead) 
-- sort of what happens after a string of sleepless nights, rebuilding a 
machine, after what was supposed to be a RAID array died and took my o/s 
with it (luckily data was ok)


sigh

Miles

--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: Sender with invalid domain

[LuKreme]

On Apr 13, 2009, at 14:46, mouss  wrote:

does reject_unknown_sender_domain really reject that many spam (that  
is



not rejected by zen among other things)?


Yes. Especially before IPs get listed in zen.

RE: A better backscatter killer?

[MacShane, Tracy]

 

> -Original Message-
> From: owner-postfix-us...@postfix.org 
> [mailto:owner-postfix-us...@postfix.org] On Behalf Of mouss
> Sent: Wednesday, 15 April 2009 7:11 AM
> To: postfix-users@postfix.org
> Subject: Re: A better backscatter killer?
> 
> Ralf Hildebrandt a écrit :
> > * MacShane, Tracy :
> > 
> >> Then you won't receive some genuine messages, both bounce and 
> >> non-bounce.
> >>
> >> Try the ips.backscatterer.org RBL; it works well for us.
> >>
> >> 
> http://www.mailinglistarchive.com/postfix-users@postfix.org/msg57402.
> >> html
> > 
> > They are retarded. mail.charite.de is listed in it.
> > 
> 
> and I guess postfix members would be bothered to block:
>   camomile.cloud9.net[168.100.1.3]
>   english-breakfast.cloud9.net[168.100.1.7]
> 
> $ host 3.1.100.168.ips.backscatterer.org 
> 3.1.100.168.ips.backscatterer.org has address 127.0.0.2 $ 
> host 7.1.100.168.ips.backscatterer.org 
> 7.1.100.168.ips.backscatterer.org has address 127.0.0.2
> 
> so if one uses this list, then
> - use a whitelist (dnswl and possibly local WL)
> - use it in smtpd_data_restrictions to avoid blocking SAV 
> sources. while you may hate SAV, it's different than backscatter.
> 
> 

I do whitelist one of our backscatterers, since it's our Defence department. As 
it happens, it seems all of the backscatter I've trapped from them *is* 
backscatter, because they're bounces to non-existent addresses or evident spam 
messages. But I accept it all from them just in case. And yes, my restriction 
is in smtpd_data_restrictions, as shown in the original message I linked to.

Frankly, I'm not that fussed about blocking potential bounces from list mail. 
Also, if I were running an ISP rather than a corporate email system, I probably 
wouldn't use this RBL. I do wish there were a slightly less problematic one - 
ie. one that would respond promptly to requests for removal without gouging 50 
euro, and which didn't care so much about SAV - but I don't think it's *that* 
problematic. 

Our main source of spam that was getting through our header checks was from 
backscatter, and since I've instituted the RBL, it has entirely gone. Only a 
couple of hundred or so messages a day currently, but it makes a difference to 
our end-users, some of whom were disproportionally affected by the problem (we 
have a tag-and-forward content scanner, and some of these individuals were 
having to review and discard hundreds of messages a week).

Re: qmgr core dumps for "non-zero recipient count"

[Wietse Venema]

I noticed this perhaps unrelated problem in the log:

Apr 14 14:00:51 mailscan postfix/smtp[73427]: fatal: shared lock 
active/29E97222038E_9DE187AF: Resource temporarily unavailable

Let's ignore the non-Postfix queue filename for a moment.

The above error message means that the queue manager has opened a
queue file while some delivery request for that file is still in
progress.

This was not supposed to happen when I originally released Postfix.

To avoid duplicate deliveries after "postfix reload", delivery
agents shared-lock a queue file while processing a delivery request
from the queue manager. The queue manager will not read recipients
from a queue file when it can't get an exclusive lock on that file.

However, both old and new qmgr have code that will proactively read
more recipients from queue file before all in-memory recipients
have been processed. As CPUs get faster, races become more likely,
and the above error will become more likely.

I'll guard the above fatal error so it happens only when
the problem is persistent.

Wietse

Re: virtual alias problem

[Miles Fidelman]

Wietse,

So... other than my mistake in not running postfix upgrade-configuration 
(which, when I run it now, seems to do nothing) - any thoughts on why a 
virtual address resolves just fine when received from outside, but not 
when submitted by a program invoking /usr/bin/sendmail?


Thanks,

Miles

Miles Fidelman wrote:

missing piece of information (inserted below)

Miles Fidelman wrote:

Hi Folks,

I've been rebuilding a server that was working fine, but then 
crashed.  In the process I've installed a newer (current) version of 
Postfix, and suddenly I'm seeing an aliasing problem that I've never 
seen before.  Maybe somebody can help figure this out.


This has to do with the interactions between Postfix and my mailing 
list manager (sympa):


Key piece of information, messages from the outside, addressed to 
mfidel...@fidelman.net are properly delivered to my local mailbox:
mfidel...@fidelman.net is a virtual address that's mapped by 
virtual_alias_maps mfidelman

mfidelman, in turn is an alias (/etc/aliases) to my local mailbox
- mail, from outside, to mfidel...@fidelman.net - is delivered just fine

Here's what's NOT working:  a message addressed to 
blsparents-requ...@lists.neighborhoods.net SHOULD end up in my local 
mailbox, and it is, but it's ending up there as a BOUNCE.


The basic flow of events:


Incoming processing:
- received by postfix (for blsparents-requ...@lists.neighborhood.net 
- virtual address)

- passed to amavisd-new, clamav, spamassin
- returned marked clean
- postfix then delivers the message to sympa (reports: delivered to 
command:  /home/sympa/bin/queue 
blsparents-requ...@lists.neighborhood.net)

- this is corrent
- postfix deques the message


Sympa does it's thing - in this case looking up the email name 
associated with blsparents-requ...@lists.neighborhood.net
- in this case, sympa looks up the request address in its database, 
and generates a message to mfidel...@fidelman.net

- sympa passes this back to postfix via /usr/bin/sendmail
- here's where things get funny:

Apr 14 16:45:17 server1 postfix/pickup[6631]: A044638C281: uid=114 
from=
Apr 14 16:45:17 server1 postfix/cleanup[10504]: A044638C281: 
message-id=<49e4f58d.8030...@meetinghouse.net>
Apr 14 16:45:17 server1 postfix/qmgr[3990]: A044638C281: 
from=, size=1678, nrcpt=1 
(queue active)
Apr 14 16:45:17 server1 postfix/error[10574]: A044638C281: 
to=, relay=none, delay=0.35, 
delays=0.34/0/0/0.01, dsn=5.0.0, status=bounced (User unknown in 
virtual alias table)


notice the "user unknown in virtual alias table" - even though, under 
other circumstances postfix processes this properly


Apr 14 16:45:17 server1 postfix/bounce[10544]: A044638C281: sender 
non-delivery notification: A6EAC38C289

Apr 14 16:45:17 server1 postfix/qmgr[3990]: A044638C281: removed

I ultimately receive a bounce message as follows (unimportant pieces 
removed):


From: mailer-dae...@server1.neighborhoods.net (Mail Delivery System)
X-Original-To: sympa-requ...@lists.neighborhood.net
Delivered-To: sympa-requ...@server1.neighborhoods.net

maps to postmaster which in turn aliases to my local mailbox>


Subject: Undelivered Mail Returned to Sender
To: sympa-requ...@lists.neighborhood.net
Auto-Submitted: auto-replied

This is the mail system at host server1.neighborhoods.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

  The mail system

: User unknown in virtual alias table



  The mail system

: User unknown in virtual alias table

Reporting-MTA: dns; server1.neighborhoods.net
X-Postfix-Queue-ID: A9CFB38C273
X-Postfix-Sender: rfc822; sympa-requ...@lists.neighborhood.net
Arrival-Date: Tue, 14 Apr 2009 18:10:17 -0400 (EDT)

Final-Recipient: rfc822; mfidel...@fidelman.net
Action: failed
Status: 5.0.0
Diagnostic-Code: X-Postfix; User unknown in virtual alias table







--
so... obviously something is messed up, but what

- under some circumstances mfidel...@fidelman.net is properly handled
- under other circumstances it's not recognized

any ideas what might be wrong, or tests to run to narrow things down?


Thanks very much,

Miles Fidelman







--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: virtual alias problem

[Wietse Venema]

Miles Fidelman:
> Wietse,
> 
> So... other than my mistake in not running postfix upgrade-configuration 
> (which, when I run it now, seems to do nothing) - any thoughts on why a 
> virtual address resolves just fine when received from outside, but not 
> when submitted by a program invoking /usr/bin/sendmail?

You are supposed to use "postfix upgrade-configuration" on the
configuration that WORKED.  Why don't you save everyone a lot
of time and simply restore the old working file from backup?

I really have no time for a lengthy step-by-step interview but
I will give you one hint:

You get "user unknown in virtual alias table" because the recipient's
domain matches $virtual_alias_domains, AND your virtual_alias_maps
FAILS to replace the recipient's domain.

Perhaps your screw-up is that $virtual_alias_domains does not
specify a domain at all, and that your $myorigin setting matches
$virtual_alias_domains.

Or it could be something else. I don't have time for this.

Wietse

Re: virtual alias problem

[Victor Duchovni]

On Tue, Apr 14, 2009 at 08:14:17PM -0400, Miles Fidelman wrote:

> Wietse,
>
> So... other than my mistake in not running postfix upgrade-configuration 
> (which, when I run it now, seems to do nothing) - any thoughts on why a 
> virtual address resolves just fine when received from outside, but not when 
> submitted by a program invoking /usr/bin/sendmail?
>

Perhaps you have misconfigured "receive_override_options" in pickup
or have conflicting requirements for pickup.

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

Now OT. Terminating thread (was Re: A better backscatter killer?)

[Rod Whitworth]

--Original Message Text---
From: Pawe+‚ Le+›niak
Date: Tue, 14 Apr 2009 14:50:57 +0200
8>< snip-
I don't like top-posting but..
Due to your message formatting it is not possible for someone to easily
see who said what in your reply. So simply for the benefit of others
who may have had a passing interest, I'll make closing comments.

All talk about RFCs in your message is irrelevant because messages from
the null sender addressed to a fictitious recipient will NEVER be
delivered anyway. RFC3834 is NOT a standard BTW, and we should hope it
never is as it contemplates things like sending virus notifications.
Echhhk!

So we trapit <> to invalid addresses and reading the logs shows that
the probability of those messages being bounces from servers configured
by amateurs is something like .77.

You have no idea how little load this places on our firewall. It is not
even measurable when there is a spambot storm in progress. It does not
consume any Postfix resources. It also seems that the tarpitting we do
on other spammy senders is noticed by some of them as the  number of
trapped IPs at any instant is now about a quarter of what it was a year
ago.

We don't slow down our network by tarpitting. The sender gets 1 char/ 4
seconds and typically gives up after about 1500 seconds with the
settings I use.

For more info see
http://www.openbsd.org/cgi-bin/man.cgi?query=spamd&apropos=0&sektion=0&m
anpath=OpenBSD+Current&arch=i386&format=html

And that's all folks! Back to lurking for me.
-


W dniu 2009-04-14 13:54, Rod Whitworth pisze:

Remember I did say that I was applying this to "null sender to
non-existing recipients" (who were purported to be the original
senders). We have about 60 spamtrap addresses. Most invented by
spammers.

I'd imagine somewhat better usage of spam-traps then grey-jail. And if
it's "system-wide" - read on.
Are you sure that null sender is only used in bounces?

What else?

- SAV
- Auto-replies- -  (...)Since in most cases it is not appropriate to
respond to
- -  an automatic response, and the responder is not interested in
- -  delivery status messages, a MAIL FROM address of <> MAY be used
for
- -  this purpose.(...)-  RFC3834
- Any type of automated notifications (...)In some types of
- -  reporting messages for which a reply is likely to cause a mail
loop
- -  (for example, mail delivery and nondelivery notifications), the
- -  reverse-path may be null (see section 3.7).(...)-  RFC2821

It wastes resources on all the misconfigured bounce-instead-of-reject
dummies out there and places no load on my lovely Postfix server. Heh!

Could you explain how? If you greylist those mails instead of
rejecting, 
you are getting additional SMTP connection(s). If you reject them, they

are discarded. What am I missing?

They are detected whilst they are in the greylist and then they are
grey-trapped (tar-pitted in other words)

IMHO: You are wasting also your resources, and you are slowing down the
network. While it's almost sure the other side will not correct
configuration, the prize is smaller than the price.
Rod/
/earth: write failed, file system is full
cp: /earth/creatures: No space left on device


Check your storage.


Check the population of /earth for yourself ... ;-(


There's still some room ;-)
Not enough for all the irresponsible breeders.

Pawel Lesniak



*** NOTE *** Please DO NOT CC me. I  subscribed to the list.
Mail to the sender address that does not originate at the list server is 
tarpitted. The reply-to: address is provided for those who feel compelled to 
reply off list. Thankyou.

Rod/
/earth: write failed, file system is full
cp: /earth/creatures: No space left on device

Re: virtual alias problem

[Miles Fidelman]

Wietse Venema wrote:

Miles Fidelman:
  

Wietse,

So... other than my mistake in not running postfix upgrade-configuration 
(which, when I run it now, seems to do nothing) - any thoughts on why a 
virtual address resolves just fine when received from outside, but not 
when submitted by a program invoking /usr/bin/sendmail?



You are supposed to use "postfix upgrade-configuration" on the
configuration that WORKED.  Why don't you save everyone a lot
of time and simply restore the old working file from backup?

  
I hate to say it... it worked.  Had to play with the TLS and SASL stuff 
a bit, but everything else worked as upgraded.


Thanks.

Miles

--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra