Re: Mail Delivery Status report

[@lbutlr]

> On 31 May 2019, at 00:33, Bastian Blank 
>  wrote:
> 
> On Fri, May 31, 2019 at 12:03:37AM -0600, @lbutlr wrote:
>> I am getting mail delivery status reports for every bcc email (that is, 
>> every email, since I use a bcc map to create a backup of all the mail).
> 
> Then you missconfigured something.

Sure, but what could it be?

> Mails duplicated by bcc maps are sent with NOTIFY=NONE, so don't create any 
> DSN.

Yes, that is how it worked a couple of weeks ago. And the pm;y was O see to 
change that is to set sundial -v which is not set anywhere and isn't in 
postconf .

> See http://www.postfix.org/postconf.5.html#recipient_bcc_maps

And I posted the contents of the file referred to in recipient_bcc_maps

>> Still, I am not sure why these messages are bing generate or how to turn 
>> them off.
> 
> Show logs, read http://www.postfix.org/DEBUG_README.html#mail

There's nothing interesting in the logs, sadly. It shows the bcc message being 
created and sent to the bcc address and the the delivery status notification 
ebbing generated as well, but not why.

mail postfix/pipe[78386]: 45FZmb6nfgzdrvL: 
to=>, relay=dovecot, delay=0.03, 
delays=0.01/0.01/0/0.01, dsn=2.0.0, status=deliverable (delivers to command: 
/usr/local/libexec/dovecot/dovecot-lda)
mail postfix/pickup[14015]: 45FZmb6nfgzdrvL: uid=0 from=
mail postfix/cleanup[78054]: 45FZmb6nfgzdrvL: 
message-id=<45fzmb6nfgzd...@mail.covisp.net>
mail postfix/qmgr[65477]: 45FZmb6nfgzdrvL: from=, size=271, 
nrcpt=2 (queue active)
mail postfix/local[78415]: 45FZmb6nfgzdrvL: to=, 
orig_to=, relay=local, delay=0.03, delays=0.01/0.01/0/0.01, 
dsn=2.0.0, status=deliverable (delivers to command: /usr/local/bin/procmail -t 
-a $EXTENSION)
mail postfix/bounce[78605]: 45FZmb6nfgzdrvL: sender delivery status 
notification: 45FZmb6xXXzdrvd
mail postfix/qmgr[65477]: 45FZmb6nfgzdrvL: removed

But nothin there says why the delivery status notification is generated.



-- 
Q is for QUENTIN who sank in the mire
R is for RHODA consumed by a fire

Re: Mail Delivery Status report

[Bastian Blank]

On Fri, May 31, 2019 at 01:29:11AM -0600, @lbutlr wrote:
> mail postfix/pipe[78386]: 45FZmb6nfgzdrvL: 
> to=>, relay=dovecot, delay=0.03, 
> delays=0.01/0.01/0/0.01, dsn=2.0.0, status=deliverable (delivers to command: 
> /usr/local/libexec/dovecot/dovecot-lda)
> mail postfix/pickup[14015]: 45FZmb6nfgzdrvL: uid=0 from=
> mail postfix/cleanup[78054]: 45FZmb6nfgzdrvL: 
> message-id=<45fzmb6nfgzd...@mail.covisp.net>
> mail postfix/qmgr[65477]: 45FZmb6nfgzdrvL: from=, size=271, 
> nrcpt=2 (queue active)
> mail postfix/local[78415]: 45FZmb6nfgzdrvL: to=, 
> orig_to=, relay=local, delay=0.03, 
> delays=0.01/0.01/0/0.01, dsn=2.0.0, status=deliverable (delivers to command: 
> /usr/local/bin/procmail -t -a $EXTENSION)
> mail postfix/bounce[78605]: 45FZmb6nfgzdrvL: sender delivery status 
> notification: 45FZmb6xXXzdrvd
> mail postfix/qmgr[65477]: 45FZmb6nfgzdrvL: removed
> 
> But nothin there says why the delivery status notification is generated.

This is no real mail.  A real delivery would have "status=sent" in it.

The "status=deliverable" part describes this as a delivery check.  As
this delivery check produces a DSN, you are most likely using "sendmail
-bv" (as root on the local system!), where this is the expected and
_documented_ result.

Regards,
Bastian

-- 
Violence in reality is quite different from theory.
-- Spock, "The Cloud Minders", stardate 5818.4

Re: re-route mails on demand during block of ip address

[Noel Jones]

On 5/31/2019 1:48 AM, Stefan Bauer wrote:

Hi,

I'm running a pair of postfix-servers in different data-centers 
(different ip networks) for outgoing-only delivery. once in a while 
my providers /22 appear on public blacklists, so mails from my nodes 
also gets rejected.


For this, i have now a third backup-instance in another data center 
that is not visible to my users and only fairly with dummy mails 
used to keep reputation up and good. Howto re-route traffic on 
demand with postfix in case, ip-networks get blocked again?


How do others handle this?

Thank you.

Stefan



Much better to send all your mail via the ISP that doesn't get their 
whole space blocked, rather than a crappy workaround.


For a crappy workaround, you can use smtp_reply_filter to turn 5xx 
rejects due to blacklists into 4xx temp failures, then use 
smtp_fallback_relay to send the temp failures to your backup server. 
 This will send other mail to the backup server, such as greylisted 
mail or mail that temp fails for unrelated reasons. Try to make your 
reply filter narrow enough that it doesn't transform rejects for 
non-rbl reasons, such as unknown recipient.


http://www.postfix.org/postconf.5.html#smtp_reply_filter
http://www.postfix.org/postconf.5.html#smtp_fallback_relay



  -- Noel Jones

Re: re-route mails on demand during block of ip address

[Stefan Bauer]

Hi Noel,

thank you for your reply. You know, in real world, ips/ranges get blocked
from time to time and i would like to be ready for this and not rely on
others :)
The workaround looks indeed crappy - i wonder how others handle this
situation in "bigger" setups? I'm currently having 7000-8000 mails / day.

Stefan

Am Fr., 31. Mai 2019 um 18:37 Uhr schrieb Noel Jones :

> On 5/31/2019 1:48 AM, Stefan Bauer wrote:
> > Hi,
> >
> > I'm running a pair of postfix-servers in different data-centers
> > (different ip networks) for outgoing-only delivery. once in a while
> > my providers /22 appear on public blacklists, so mails from my nodes
> > also gets rejected.
> >
> > For this, i have now a third backup-instance in another data center
> > that is not visible to my users and only fairly with dummy mails
> > used to keep reputation up and good. Howto re-route traffic on
> > demand with postfix in case, ip-networks get blocked again?
> >
> > How do others handle this?
> >
> > Thank you.
> >
> > Stefan
>
>
> Much better to send all your mail via the ISP that doesn't get their
> whole space blocked, rather than a crappy workaround.
>
> For a crappy workaround, you can use smtp_reply_filter to turn 5xx
> rejects due to blacklists into 4xx temp failures, then use
> smtp_fallback_relay to send the temp failures to your backup server.
>   This will send other mail to the backup server, such as greylisted
> mail or mail that temp fails for unrelated reasons. Try to make your
> reply filter narrow enough that it doesn't transform rejects for
> non-rbl reasons, such as unknown recipient.
>
> http://www.postfix.org/postconf.5.html#smtp_reply_filter
> http://www.postfix.org/postconf.5.html#smtp_fallback_relay
>
>
>
>-- Noel Jones
>

Re: re-route mails on demand during block of ip address

[Blake Hudson]

The majority of blacklists work on the individual host level (IPv4 /32 
or IPv6 /64). If your provider's entire /22 is being listed by public 
blacklists then I suspect you either have a very disreputable provider 
or the provider has indicated that the /22 is intended for use by 
residential/dynamic subscribers only (not for mail servers). Most of the 
folks with the "bigger" setups you asked about tend to use reputable 
providers, use internet connections intended for servers, or obtain 
their own IP space. If you intend to operate an email server, you might 
want to find a provider whose policies allow you to do so reliably.


Stefan Bauer wrote on 5/31/2019 12:12 PM:

Hi Noel,

thank you for your reply. You know, in real world, ips/ranges get 
blocked from time to time and i would like to be ready for this and 
not rely on others :)
The workaround looks indeed crappy - i wonder how others handle this 
situation in "bigger" setups? I'm currently having 7000-8000 mails / day.


Stefan

Am Fr., 31. Mai 2019 um 18:37 Uhr schrieb Noel Jones 
mailto:njo...@megan.vbhcs.org>>:


On 5/31/2019 1:48 AM, Stefan Bauer wrote:
> Hi,
>
> I'm running a pair of postfix-servers in different data-centers
> (different ip networks) for outgoing-only delivery. once in a while
> my providers /22 appear on public blacklists, so mails from my
nodes
> also gets rejected.
>
> For this, i have now a third backup-instance in another data center
> that is not visible to my users and only fairly with dummy mails
> used to keep reputation up and good. Howto re-route traffic on
> demand with postfix in case, ip-networks get blocked again?
>
> How do others handle this?
>
> Thank you.
>
> Stefan

Re: OT: Postscreen and scoring/blocking by ISP

[Charles Sprickman]

> On May 30, 2019, at 5:38 PM, Allen Coates  wrote:
> 
> 
> On 30/05/2019 22:21, Allen Coates wrote:
>> Currently, I am using a CIDR access-control-list to block (in PostScreen) 
>> hosts
>> from certain "nuisance" countries.  A weekly script derives the netblocks 
>> from
>> the zone lists published by http://www.ipdeny.com
> 
> A similar script could derive a DNS zone file - with varying levels of 
> "badness"
> - if you wanted to run your own RBL…

I see the Cymru guys have an IP to ASN DNS lookup:

https://www.team-cymru.com/IP-ASN-mapping.html#dns 


That’s part way there. I can easily find the ASNs I care to penalize.  But 
still have to figure out how to do something with that in postscreen…

Charles

> 
> Allen C

Re: re-route mails on demand during block of ip address

[@lbutlr]

On 31 May 2019, at 11:12, Stefan Bauer  wrote:
> thank you for your reply. You know, in real world, ips/ranges get blocked 
> from time to time 

Not be legitimate RBLs they don't unless you are actually sending spam. If more 
IPs than just you mail server are getting blocked, then you probably need to 
get a new NSP that doesn't tolerate spammers.

If you want to send mail to others you pretty much need to meet these criteria.

Fixed IP with valid rDNS
NSP that does not allow spammers
A valid secure configuration on your server (no open relay)
Not be sending spam yourself

If you can't meet all of those, then you need to rely on someone else who does 
meet those minimums to send mail on your behalf.

I've been through several IP changes over the years and the only RBL that haas 
ever listed me was barracuda, which was coincidently after I replied to one of 
their marketing emails 
with "fuck off" but even that was more than a decade ago.


-- 
'Detectoring is like gambling,' said Vimes, putting down the clove. 'The
secret is to know the winner in advance.'

Re: OT: Postscreen and scoring/blocking by ISP

[Wietse Venema]

Charles Sprickman:
> https://www.team-cymru.com/IP-ASN-mapping.html#dns 
> 
>
> That?s part way there. I can easily find the ASNs I care to penalize.  But 
> still have to figure out how to do something with that in postscreen?

There is no need to do everything in postscreen, especially considering
that the purpose is to block spambots, which is not the same thing
as blocking all spam operators.

For the latter, I have used check_{client,helo,sender}_{ns,mx}_access
to trap mail from different 'domains' that share infrastructure.

Wietse

Re: OT: Postscreen and scoring/blocking by ISP

[Charles Sprickman]

> On May 31, 2019, at 7:45 PM, Wietse Venema  wrote:
> 
> Charles Sprickman:
>> https://www.team-cymru.com/IP-ASN-mapping.html#dns 
>> 
>> 
>> That?s part way there. I can easily find the ASNs I care to penalize.  But 
>> still have to figure out how to do something with that in postscreen?
> 
> There is no need to do everything in postscreen, especially considering
> that the purpose is to block spambots, which is not the same thing
> as blocking all spam operators.

I really want to weight against some sources, not block them entirely though...

> 
> For the latter, I have used check_{client,helo,sender}_{ns,mx}_access
> to trap mail from different 'domains' that share infrastructure.
> 
>   Wietse

Re: OT: Postscreen and scoring/blocking by ISP

[Bill Cole]

On 31 May 2019, at 22:03 (-0400), Charles Sprickman wrote:

I really want to weight against some sources, not block them entirely 
though...


Then the ideal tool is SpamAssassin, not postscreen. It's easy to add 
and set the scoring of any DNSBLs you find useful and if you want more 
complex logic, that's available as well.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Available For Hire