Google rejecting IPv6 mails

[Luigi Rosa]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have started to configure IPv6 on a couple of servers, both with IPv6 rDNS
resolution on their name

Sometimes (say over about 10 messages/day), Google rejects IPv6 mails with
this error:

<{google_recipient}>: host aspmx.l.google.com[2a00:1450:4001:c02::1b] said:
550-5.7.1 [2a01:4f8:d16:2409::badd:ecaf 1] Our system has detected an
550-5.7.1 unusual rate of unsolicited mail originating from your IP
address. To 550-5.7.1 protect our users from spam, mail sent from your IP
address has been 550-5.7.1 blocked. Please visit
http://www.google.com/mail/help/bulk_mail.html 550 5.7.1 to review our Bulk
Email Senders Guidelines. h46si16725451eex.133 - gsmtp (in reply to end of
DATA command)

Needless to say, that if I use IPv4 Google accepts every mail.

Dis this happened to anyone else?


Ciao,
luigi

- --
/
+--[Luigi Rosa]--
\

An idea is not responsible for the people who believe in it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJKWJ4ACgkQ3kWu7Tfl6ZSj6wCfVsgwMziUmsSlDQBgpR2AebUJ
6zkAoJ51pd6RRlQs3PzbQsqCqViGbNWj
=++dU
-----END PGP SIGNATURE-----

[Dominik George]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

>Needless to say, that if I use IPv4 Google accepts every mail.
>
>Dis this happened to anyone else?

Yes, I also face that issue and have forced IPv4 on known Google domains. Google have been ignoring my support tickets about that for several weeks now.

I somehow consider Google not fit for anything a mail server should do, for a ton of reasons, and am thinking about blocking them in both directions (along with Yahoo!), if it weren't for quite some important users switching to Google Apps.

I am trying to get a valuable customer of Google to complain that they do not receive my mail, we will see how that works.

- -nik
- --
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.0.8-fdroid

iQFNBAEBCgA3BQJSSlwTMBxEb21pbmlrIEdlb3JnZSAobW9iaWxlIGtleSkgPG5p
a0BuYXR1cmFsbmV0LmRlPgAKCRAvLbGk0zMOJWzUB/0VsEtvWLuaR7aYFPXYVevM
s4iTirQu8lH+48FTLNP09WJv54Z0r++G3TM4pVvRst/ptJ8YOfttyZsf8odjS2Si
Dk/NmL8u8bEcGww2JBiyrdi95B4iQXk4cxiZuYjlBbnG74eR96+QnUJ8ioFLLuoM
iD09pAkLSgTS/Ltkdi+OyGUWKLHSXPPMNjzG9f7ycw1+6njoTteAO2vu5kzIfJnk
52qIRntZPT3zT4Oq7CJKfgKuFl3p7aZ6lAO0OBatORJKZvkq+EGGaIEj/zMn7inN
9KzcT3GM1fO5MB53SAJUh+0LUARDwrUgrXEBZNyJmRfFg8YT/Xgilg5fYemre+IH
=3TDF
-----END PGP SIGNATURE-----

[Luigi Rosa]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dominik George said the following on 01/10/2013 07:22:

> Yes, I also face that issue and have forced IPv4 on known Google domains.
> Google have been ignoring my support tickets about that for several weeks
> now.

Same here. At the beginning I thought it was my fault, but then I saw that the
problem was replicated on very different servers.

Ciao,
luigi

- --
/
+--[Luigi Rosa]--
\

Paul's Law: You can't fall off the floor.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJKXtQACgkQ3kWu7Tfl6ZTP1QCgzajGM3DAqWATuOf76IALf4cL
lNoAn31nyk4TB7BdBcz3MeAVUA6zdlUe
=oG2q
-----END PGP SIGNATURE-----

[Andreas Herrmann]

Hi there,

On 10/01/13 07:22, Dominik George wrote:
> Yes, I also face that issue and have forced IPv4 on known Google domains.

I also have those problems.

Is there an easy way in postfix the transport to some doamins just over
IPv4 and not IPv6?

thx in advance
-SMA

[Wijatmoko U. Prayitno]

On Mon, 07 Oct 2013 13:23:59 +0200
Andreas Herrmann <s...@physik.tu-berlin.de> wrote:

> Is there an easy way in postfix the transport to some
> doamins just over IPv4 and not IPv6?
>

http://marc.info/?l=postfix-users&m=137702158131907&w=2

--
WUP

[Manuel Bieling]

On 2013.10.07 13:23:59 +0200, Andreas Herrmann wrote:
> Hi there,
>
> On 10/01/13 07:22, Dominik George wrote:
> > Yes, I also face that issue and have forced IPv4 on known Google domains.
>
> I also have those problems.
>

> Is there an easy way in postfix the transport to some doamins just over
> IPv4 and not IPv6?

Wietse explained this a few weeks ago:

/etc/postfix/transport:
example.com smtp-ipv4-only:
example.net smtp-upv6-only:

/etc/postfix/master.cf:
smtp-ipv4-only unix - - n - - smtp
inet_protocols=ipv4
smtp-ipv6-only unix - - n - - smtp
inet_protocols=ipv6

/etc/postfix/main.cf:
transport_maps = hash:/etc/postfix/transport

Execute "postmap hash:/etc/postfix/transport" and "postfix reload"
when the transport map is changed.

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

--
Best regards,
Manuel

[Alan Munday]

Manuel Bieling wrote the following on 07/10/13 12:45:

> Wietse explained this a few weeks ago:
>
> /etc/postfix/transport:
> example.com smtp-ipv4-only:
> example.net smtp-upv6-only:
>
> /etc/postfix/master.cf:
> smtp-ipv4-only unix - - n - - smtp
> inet_protocols=ipv4
> smtp-ipv6-only unix - - n - - smtp
> inet_protocols=ipv6
>
> /etc/postfix/main.cf:
> transport_maps = hash:/etc/postfix/transport
>
> Execute "postmap hash:/etc/postfix/transport" and "postfix reload"
> when the transport map is changed.
>
> http://www.postfix.org/postconf.5.html#inet_protocols
>

For those who cut-and-pate note the minor typo:

"smtp-upv6-only" should read smtp-ipv6-only

[Dotan Cohen]

On Tue, Oct 1, 2013 at 8:22 AM, Dominik George <n...@naturalnet.de> wrote:
> I somehow consider Google not fit for anything a mail server should do, for a ton of reasons, and am thinking about blocking them in both directions (along with Yahoo!), if it weren't for quite some important users switching to Google Apps.
>

I would love to know the rest of your reasons for blocking Google. A
few months ago I moved our company's email to Gmail and users are
extremely happy. Maybe there are some things that we are ignorant of.

> I am trying to get a valuable customer of Google to complain that they do not receive my mail, we will see how that works.
>

I don't know how "valuable" we are to Google but we pay them quite a
bit monthly, for Google Apps and some other services. Tell me what's
on your mind, I'll see if I can channel it through our support
channel.

--
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com

[Viktor Dukhovni]

On Mon, Oct 07, 2013 at 01:45:06PM +0200, Manuel Bieling wrote:

> /etc/postfix/master.cf:
> smtp-ipv4-only unix - - n - - smtp
> inet_protocols=ipv4
> smtp-ipv6-only unix - - n - - smtp
> inet_protocols=ipv6

For the record, that should be "-o inet_protocols=ipv[46]", not just
"inet_protocols=ipv[46]".

--
Viktor.

[Wietse Venema]

Manuel Bieling:

> On 2013.10.07 13:23:59 +0200, Andreas Herrmann wrote:
> > Hi there,
> >
> > On 10/01/13 07:22, Dominik George wrote:
> > > Yes, I also face that issue and have forced IPv4 on known Google domains.
> >
> > I also have those problems.
> >
> > Is there an easy way in postfix the transport to some doamins just over
> > IPv4 and not IPv6?
>

> Wietse explained this a few weeks ago:

And here is the corrected example in one place. BTW it seems the
real fix is to set up one PTR record, with a matching AAAA record.

/etc/postfix/transport:
example.com smtp-ipv4-only:
example.net smtp-ipv6-only:

/etc/postfix/master.cf:
smtp-ipv4-only unix - - n - - smtp

-o inet_protocols=ipv4

smtp-ipv6-only unix - - n - - smtp

-o inet_protocols=ipv6

/etc/postfix/main.cf:
transport_maps = hash:/etc/postfix/transport

Execute "postmap hash:/etc/postfix/transport" and "postfix reload"

after changing the transport map or master.cf.

References:
http://www.postfix.org/postconf.5.html#inet_protocols
http://www.postfix.org/transport.5.html

Wietse

[Andreas Herrmann]

On 10/07/13 16:25, Wietse Venema wrote:
> And here is the corrected example in one place. BTW it seems the
> real fix is to set up one PTR record, with a matching AAAA record.

I have a correct PTR and also got the error:

<***@gmail.com>: host
gmail-smtp-in.l.google.com[2a00:1450:4001:c02::1b] said: 550-5.7.1
[2a01:4f8:d16:4114::2 1] Our system has detected an unusual rate
550-5.7.1 of unsolicited mail originating from your IP address. To
protect
our 550-5.7.1 users from spam, mail sent from your IP address has been
blocked. 550-5.7.1 Please visit
http://www.google.com/mail/help/bulk_mail.html to review 550 5.7.1
our Bulk
Email Senders Guidelines. x42si21569236eea.224 - gsmtp (in reply to
end of
DATA command)

host 2a01:4f8:d16:4114::2
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.1.1.4.6.1.d.0.8.f.4.0.1.0.a.2.ip6.arpa
domain name pointer mail.ax13.net.

mail.ax13.net. 3600 IN AAAA 2a01:4f8:d16:4114::2


Andreas

[Wietse Venema]

Andreas Herrmann:

> On 10/07/13 16:25, Wietse Venema wrote:
> > And here is the corrected example in one place. BTW it seems the
> > real fix is to set up one PTR record, with a matching AAAA record.
>
> I have a correct PTR and also got the error:
>
> <***@gmail.com>: host
> gmail-smtp-in.l.google.com[2a00:1450:4001:c02::1b] said: 550-5.7.1
> [2a01:4f8:d16:4114::2 1] Our system has detected an unusual rate
> 550-5.7.1 of unsolicited mail originating from your IP address. To

Hmm. That is a different response than the one I saw reported in
http://marc.info/?l=postfix-users&m=137702158131907&w=2

550-5.7.1 [2a01:e35:8ae7:65f0::2 16] The sender does not meet basic ipv6
550-5.7.1 sending guidelines of authentication and rdns resolution of sending
550-5.7.1 ip. Please review
550 5.7.1 https://support.google.com/mail/answer/81126for more information.

In both cases they refer to the same instructions for bulk mail senders
that suggest using RDNS, SPF, DKIM, and separation of mail streams.

It may be that their "bulk sender" threshold is lower than you expect.

Wietse

[Erwan David]

I gor it even for a single email since month...

No Google is really rejecting emails in IPv6 because of a lack of PTR...

[Jim Reid]

On 7 Oct 2013, at 18:15, Erwan David <er...@rail.eu.org> wrote:

> Google is really rejecting emails in IPv6 because of a lack of PTR...

If that's the case, good. Just do The Right Thing and arrange a valid PTR for the IPv6 address that speaks SMTP. This should be simpler and less hassle than changing the postfix config. Or adding more workaround to that when someone finds yet more mail providers who reject connections from addresses with no reverse DNS.

SMTP from an address with no reverse DNS is a fairly good indicator of a spam source. YMMV.

[DTNX Postmaster]

Make sure your ISP supports reverse DNS for IPv6, either by request or
by delegating it to you. If you cannot get this sorted yet, I would
recommend simply postponing IPv6 rollout for your MX for now, until
your ISP finally catches up.

We have had valid reverse DNS for the IPv6 address on our outgoing mail
server from the start, and we've never run into the limits described in
this thread.

That said, when we first rolled out IPv6, Google had a problem on their
side with SPF checks for IPv6 addresses, which took them a while to
resolve. Perhaps these rate limits are another example of something
that needs to be fixed or adjusted on their end.

Mvg,
Joni

[li...@rhsoft.net]

Am 07.10.2013 19:15, schrieb Erwan David:
> No Google is really rejecting emails in IPv6 because of a lack of PTR...

as virtually everbody else does for IPv4
why should someone handle IPv6 different?

if you have no PTR do not deliver emial

[Erwan David]

That's a matter of policy, if you cannot afford to loose legitimate
email, you may.<

[Benny Pedersen]

li...@rhsoft.net skrev den 2013-10-07 19:38:

> if you have no PTR do not deliver emial

PTR is unsafe, avoid it

PTR is only safe if the name is on domains dns with the same ip

will google really reject mails with spf ip6: ?

[Luigi Rosa]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Manuel Bieling said the following on 07/10/2013 13:45:

> Wietse explained this a few weeks ago:

Just remember to put the "-o" that Wietse forgot before "inet_protocols"

Works like a charm.

Ciao,
luigi

- --
/
+--[Luigi Rosa]--
\

I've already told you more than I know.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJS80EACgkQ3kWu7Tfl6ZS/hACcDIW4DlfdB7gPYSGtjvx5Kb3i
EaIAn1eKfdhiIU5//p4i6/hIu3ZBQrsp
=LzgL
-----END PGP SIGNATURE-----

[Luigi Rosa]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Wietse Venema said the following on 07/10/2013 16:25:

> And here is the corrected example in one place. BTW it seems the real fix
> is to set up one PTR record, with a matching AAAA record.

No, it doesn't work :(

My MX has both IPv6 rDNS and SPF record as requested by the page linked in the
status of Google 5xx reject [1] and GOOG kept rejecting may mails.


[1] http://www.google.com/mail/help/bulk_mail.html

Ciao,
luigi

- --
/
+--[Luigi Rosa]--
\

I didn't know it was impossible when I did it.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJS9DwACgkQ3kWu7Tfl6ZSd+gCfQoUcLbEzEx87Bex6ScDiGpFz
DI8AoM4HzmCZceQR6Y7ClMrNuQiIsUqw
=a6AK
-----END PGP SIGNATURE-----

[Luigi Rosa]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Wietse Venema said the following on 07/10/2013 18:58:

> It may be that their "bulk sender" threshold is lower than you expect.

About 5 or 10 mails per day.

Funny that the threshold is applied to IPv6 connections and not IPv4.

Ciao,
luigi

- --
/
+--[Luigi Rosa]--
\

The world is coming to an end... SAVE YOUR BUFFERS!!!

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJS9IoACgkQ3kWu7Tfl6ZQh0wCeMxf4BwkQxGIppIAqpgaeJuBf
HrsAoJ2KGzQYpy7qzO2iUVq1SdRmgErd
=HcHJ
-----END PGP SIGNATURE-----

[Dominik George]

Hi,

> > I somehow consider Google not fit for anything a mail server should
> > do, for a ton of reasons, and am thinking about blocking them in
> > both directions (along with Yahoo!), if it weren't for quite some
> > important users switching to Google Apps.
> >
>
> I would love to know the rest of your reasons for blocking Google. A
> few months ago I moved our company's email to Gmail and users are
> extremely happy. Maybe there are some things that we are ignorant of.

Just read <Pine.BSM.4.64L.13...@herc.mirbsd.org>. My mate
got it sumemd up quite well.

-nik

--
<burny> Ein Jabber-Account, sie alle zu finden; ins Dunkel zu treiben
und ewig zu binden; im NaturalNet, wo die Schatten droh'n ;)!

PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296

[li...@rhsoft.net]

Am 07.10.2013 19:42, schrieb Erwan David:
> Le 07/10/2013 19:38, li...@rhsoft.net a écrit :
>>
>> Am 07.10.2013 19:15, schrieb Erwan David:
>>> No Google is really rejecting emails in IPv6 because of a lack of PTR...
>> as virtually everbody else does for IPv4
>> why should someone handle IPv6 different?
>>

>> if you have no PTR do not deliver emial
>>

> That's a matter of policy, if you cannot afford to loose legitimate
> email, you may.

show me one legitimate mail server in 2013 without a PTR

as server-admin you need to RTFM and anybody which is connecting
a mailserver to the internet not having a PTR or coming with
the lousy excuse "my ISP doe snot support" instead switch to
a sane ISP did not RTFM and has to accept that others do not
accept messages from him - the is no "if" and no "but"

[Erwan David]

You may also completely stop accepting email, thus you will have no spam
at all. For me it is more important not to loose legitimate email.
You may have a different opinion.

But it is false to say tjat a mail server without reverse surely is a
spammer.

Spammers can afford reverse.

[li...@rhsoft.net]

it is very likely that it is a spammer or at least not any important mail

if someone has important mail to send he will learn the hard way that
all the "best practices" are there for a reason - hence he get a
clear reject message and if someone refuses to fix it's setup which
is done within seconds -> his problem

for every rejected legit mail from a badly configured server missing a
PTR you block 1000000 spam mails

i even go so far if someone complains that his messages are rejected
because a missing PTR i recommend to fire his admin and in doubt the
PTR has to match the A-record

[Erwan David]

Tat's false. The best you can hope is that one of the A (or AAAA) record
for one of the PTR of the connecting address is the connecting address
You may have several PTR per IP and several address per name.

[Patrick Lists]

On 10/07/2013 07:49 PM, Luigi Rosa wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

> Wietse Venema said the following on 07/10/2013 16:25:
>
>> And here is the corrected example in one place. BTW it seems the real fix
>> is to set up one PTR record, with a matching AAAA record.
>
> No, it doesn't work :(
>
> My MX has both IPv6 rDNS and SPF record as requested by the page linked in the
> status of Google 5xx reject [1] and GOOG kept rejecting may mails.
>
>
> [1] http://www.google.com/mail/help/bulk_mail.html

I have no issues with a postfix server sending just a dozen or so emails
per week to gmail.com email addresses via IPv6 but that postfix server
has an IPv4/IPv6 rDNS (DNS has DNSSec), SPF records, signs using
OpenDKIM with 2048 bit keys and uses OpenDMARC.

Regards,
Patrick

[li...@rhsoft.net]

you may that, you may this....

you may have a sane setup with one IP having one A-record and one PTR
i did nowhere say i would enforce this, i said "in doubt it has to match"
or at least there must be a A-record for your PTR

but that's off-topic

on-topic is that anybody setting up a MTA without a PTR is clearly
missing the qualification to maintaina mail-system and most likely
doe snot care about other best practices which makes him dangerous

[Viktor Dukhovni]

This thread is becoming repetitive with no new insights, time to
wrap it up.

--
Viktor.

[Wietse Venema]

Viktor Dukhovni:

> This thread is becoming repetitive with no new insights, time to
> wrap it up.

In particular Reindl, you are getting close to be kicked off the list again.

Wietse

[Jim Reid]

> On 7 Oct 2013, at 19:30, Erwan David <er...@rail.eu.org> wrote:

> But it is false to say tjat a mail server without reverse surely is a spammer.

But nobody was saying that. Almost no legitimate mail comes from addresses with no reverse DNS. Sure, some spammers will have reverse DNS. Which is why this is just one defence amongst many to keep the spam at bay.

If you can't or won't set up reverse DNS for your outbound delivery agents, expect the rest of the world to treat you as a spammer even if you're not.

Sent from a wee shiny thing with no keyboard that creates typos

> On 7 Oct 2013, at 19:30, Erwan David <er...@rail.eu.org> wrote:
>
> Le 07/10/2013 20:24, li...@rhsoft.net a écrit :
>>
>> Am 07.10.2013 19:42, schrieb Erwan David:

>>> Le 07/10/2013 19:38, li...@rhsoft.net a écrit :
>>>> Am 07.10.2013 19:15, schrieb Erwan David:
>>>>> No Google is really rejecting emails in IPv6 because of a lack of PTR...
>>>> as virtually everbody else does for IPv4
>>>> why should someone handle IPv6 different?
>>>>
>>>> if you have no PTR do not deliver emial

[Stan Hoeppner]

On 10/7/2013 12:25 PM, Jim Reid wrote:
> On 7 Oct 2013, at 18:15, Erwan David <er...@rail.eu.org> wrote:
>

>> Google is really rejecting emails in IPv6 because of a lack of PTR...
>

> If that's the case, good. Just do The Right Thing and arrange a valid PTR for the IPv6 address that speaks SMTP. This should be simpler and less hassle than changing the postfix config. Or adding more workaround to that when someone finds yet more mail providers who reject connections from addresses with no reverse DNS.
>
> SMTP from an address with no reverse DNS is a fairly good indicator of a spam source. YMMV.

Agreed.

Postfix' reject_unknown_reverse_client_hostname is functionally
equivalent to what Google is doing here. And I'd guess everyone here
enables this restriction. And if not, they should. Hmm...that makes me
wonder...

Since Postscreen stops bots without checking for existence of PTR, I'm
wondering if many folks have simply eliminated this restriction in
main.cf, and thus forgotten how critical PTR is as a first level of
trust evaluation of inbound SMTP connections.

Yesterday reject_unknown_reverse_client_hostname accounted for 45% of
rejected spam attempts here. I do not use Postscreen. And neither does
Google, and their MTA is self baked.

--
Stan

[Dominik George]

> > SMTP from an address with no reverse DNS is a fairly good indicator
> > of a spam source. YMMV.
>
> Agreed.

As a matter of fact, I *do* have working PTR, SPF, and all that stuff,
for both IPv4 and IPv6, and it doesn't help. I should note that I did
have that all the time, not just after Google decided to blacklist me. I
have tested my setup against some very restrictive mail servers, to make
sure it is sane, and a friend and I have worked together closely to
create waterproof and well-functioning mail systems. I am PMed in
various chat rooms when Postfix questions come up. The reason for Google
rejecting IPv6 mail is *not* only broken client setups. Period.

Google started rejecting IPv6 mail from my n...@naturalnet.de address to
their servers, even legitimate mail to us...@jitsi.org (why an open
source project uses Google services and *then* relay mail to their own
mail server is a mystery to me), which is an address tuple that by all
means should be known to Google as being legitimate.

Jesus, I have worked around a lot of misconfigurations by other
providers to allow me and my users to send mail there, the most
prominent one being United Internet's failure to accept 8bit MIME
messages (they were advertising 8bitmime in EHLLO, then when being hit
by a real 8bit MIME message, they accepted it and cast it away in an
awful attempt to prevent backscatter because some of their internal
systems could not handle 8bit MIME). I am just tired of big companies
that sell their services not being up to the task while virtually every
little person out here in the community is.

Paying Google customers, please help us get our mails through!

Google users in general, please move away there!

-nik

--
* mirabilos is handling my post-1990 smartphone *
<mirabilos> Aaah, it vibrates! Wherefore art thou, demonic device??

[Nicolas KOWALSKI]

On Mon, Oct 07, 2013 at 07:36:48PM +0200, DTNX Postmaster wrote:
> Make sure your ISP supports reverse DNS for IPv6, either by request or
> by delegating it to you. If you cannot get this sorted yet, I would
> recommend simply postponing IPv6 rollout for your MX for now, until
> your ISP finally catches up.

I did half of this.

On my home server, I disabled IPv6 on the postfix smtp client. The smtp
server still accepts incoming IPv6 connections.

I did not see any problem since then.

--
Nicolas

[postfix]

Mail from our system wasn't accepted oftentimes by Google either.
I discovered the following solution: Our mail server has got two IPv6
addresses in the open Internet, one is specific, the other one
automatically created. The first one was in the DNS, the second one not.
I noticed that many times messages where sent using the automatically
generated IPv6 address, which were the mails Google rejected. Since I
introduced the automatically generated IPv6 address into the DNS, Google
accepts all mail from our server.

suomi

[Peter]

On 10/08/2013 11:16 PM, postfix wrote:
> Mail from our system wasn't accepted oftentimes by Google either.
> I discovered the following solution: Our mail server has got two IPv6
> addresses in the open Internet, one is specific, the other one
> automatically created. The first one was in the DNS, the second one not.
> I noticed that many times messages where sent using the automatically
> generated IPv6 address, which were the mails Google rejected.

I've had this issue before. My solution was to turn off ipv6 autoconf
in the kernel since I do not want IPs that I do not explicitly assign.

> Since I
> introduced the automatically generated IPv6 address into the DNS, Google
> accepts all mail from our server.

To me this is a bad idea, you're working around the issue instead of
fixing the real issue which is that you're getting IPs on your server
that you didn't configure for.


Peter

[Wietse Venema]

postfix:

> Mail from our system wasn't accepted oftentimes by Google either.
> I discovered the following solution: Our mail server has got two IPv6
> addresses in the open Internet, one is specific, the other one
> automatically created. The first one was in the DNS, the second one not.
> I noticed that many times messages where sent using the automatically

> generated IPv6 address, which were the mails Google rejected. Since I

> introduced the automatically generated IPv6 address into the DNS, Google
> accepts all mail from our server.

Solutions other than turning off IPv6 autoconfiguration on servers:

- Specify all Postfix IP addresses in main.cf:inet_interfaces.

/etc/postfix/main.cf:
inet_interfaces = 1.2.3.4 127.0.0.1 1:2:3:4:5:6:7:8 ::1

- Specify the Postfix IPv6 address in master.cf:

/etc/postfix/master.cf:
relay ... smtp -o smtp_bind_address6=1:2:3:4:5:6:7:8
smtp ... smtp -o smtp_bind_address6=1:2:3:4:5:6:7:8

Wietse

[John Allen]

I ran into this problem a little while ago.
I found that the problem was the Postfix binds to a port (25) for
sending, Linux links that port to an IP when needed. This means that the
address may change each time a send is initiated (This is my imperfect
understanding of things).

To make sure that postfix used a valid (Google valid) setup I added -o
smtp_bind_address and smtp_bind_address6 to the smtp entry in master.
This seemed to fix the no PTR found problem for me. The alternative is
to add a PTR record for every possible address, not very practical
particularly with IPv6.

I am not sure about the "unusual rate..." but I wonder if it is a
different manifestation of the same problem.

All I can say is that since adding the smtp_bind... I have not had any
problems.

I hope this helps.

[Wietse Venema]

Wietse Venema:

> postfix:
> > Mail from our system wasn't accepted oftentimes by Google either.
> > I discovered the following solution: Our mail server has got two IPv6
> > addresses in the open Internet, one is specific, the other one
> > automatically created. The first one was in the DNS, the second one not.
> > I noticed that many times messages where sent using the automatically
> > generated IPv6 address, which were the mails Google rejected. Since I
> > introduced the automatically generated IPv6 address into the DNS, Google
> > accepts all mail from our server.
>
> Solutions other than turning off IPv6 autoconfiguration on servers:

That remains my preferred solution, but it may not be possible if
you don't control the infrastructure.

> - Specify all Postfix IP addresses in main.cf:inet_interfaces.
>
> /etc/postfix/main.cf:
> inet_interfaces = 1.2.3.4 127.0.0.1 1:2:3:4:5:6:7:8 ::1

That example is wrong. inet_interfaces does not restrict the SMTP
client IP address when there more than one.

> - Specify the Postfix IPv6 address in master.cf:
>
> /etc/postfix/master.cf:
> relay ... smtp -o smtp_bind_address6=1:2:3:4:5:6:7:8
> smtp ... smtp -o smtp_bind_address6=1:2:3:4:5:6:7:8

That example is good. It uses master.cf instead of main.cf, to avoid
conflicts with content filters.

Wietse

[Erinn Looney-Triggs]

This sounds an awful lot like privacy extensions are enabled for the
interface. If you disable privacy extensions, even with stateless
autoconfiguration enabled, the address should be the same unless the MAC
changes on the nic. Since this is a server privacy extensions should be
disabled.

cat /proc/sys/net/ipv6/conf/eth0/use_tempaddr

use_tempaddr - INTEGER
Preference for Privacy Extensions (RFC3041).
<= 0 : disable Privacy Extensions
== 1 : enable Privacy Extensions, but prefer public
addresses over temporary addresses.
> 1 : enable Privacy Extensions and prefer temporary
addresses over public addresses.
Default: 0 (for most devices)
-1 (for point-to-point devices and loopback devices)

-Erinn

[James Cloos]

>>>>> "ln" == lists@rhsoft net <li...@rhsoft.net> writes:

ln> show me one legitimate mail server in 2013 without a PTR

Unfortunately it is not uncommon with v6.

I've had to whitelist a number of sites over the last year where the
outoing mta added a v6 address w/o a ptr.

Mostly it appeared to be due to new v6 routes and autoconfig surprising
the mta admins.

The ones I've seen have all been otherwise well run, legitimate technical
mailing lists usually hosted at a university or at commercial vps lessors.

-JimC
--
James Cloos <cl...@jhcloos.com> OpenPGP: 1024D/ED7DAEA6

[li...@rhsoft.net]

Am 09.10.2013 23:54, schrieb James Cloos:
>>>>>> "ln" == lists@rhsoft net <li...@rhsoft.net> writes:
>
> ln> show me one legitimate mail server in 2013 without a PTR
>
> Unfortunately it is not uncommon with v6.

because people change configurations in hurry to have ipv6

> I've had to whitelist a number of sites over the last year where the
> outoing mta added a v6 address w/o a ptr.

wrong way - don't whitelist them and they will fix it

> Mostly it appeared to be due to new v6 routes and autoconfig surprising
> the mta admin

autoconfig on a server?
well deserved to get rejected

never change anything on a network config without verify or
accept that you got rejected for good reasons, pretty sure
the OP has the same "problem"

[James Cloos]

>>>>> "ln" == lists@rhsoft net <li...@rhsoft.net> writes:

ln> wrong way - don't whitelist them and they will fix it

Nonsense.

Remaining subscribed to the lists in question is /vastly/ more important.

Protesting hurts me or my users, not the list admins.

The job of an MX admin is to get the legitimate mail through while
blocking the harmful crud. Not to block legitimate remotes which
are imperfect.

[Wietse Venema]

James Cloos:

> Unfortunately it is not uncommon with v6.
>

> I've had to whitelist a number of sites over the last year where the
> outoing mta added a v6 address w/o a ptr.
>

> Mostly it appeared to be due to new v6 routes and autoconfig surprising

> the mta admins.

I wonder how this could happen, as Postfix still installs with IPv6
turned off. Unless, of course, distributors have removed my temporary
safety net that disables IPv6 for the time being.

Wietse

[Patrick Lists]

Not sure if that's what you mean but a quick check of main.cf in the
postfix 2.10.2 RPM for F19 and postfix 2.6.6 RPM for CentOS 6.4 shows:

# Enable IPv4, and IPv6 if supported
inet_protocols = all

Regards,
Patrick

[Wietse Venema]

Patrick Lists:

Damned morons. They break Postfix for sites that have IPv4 only (*)
and they cause bad PTR problems for sites that turn on IPv6 as
discussed on this list.

(*) Postfix looks up a *limited* number of IP addresses, and if a site
has lots of IPv6 addresses, then Postfix may end up trying only one
IPv4 addresses.

Wietse

[Andreas Herrmann]

Hi there,

On 10/01/13 07:07, Luigi Rosa wrote:
> <{google_recipient}>: host aspmx.l.google.com[2a00:1450:4001:c02::1b] said:
> 550-5.7.1 [2a01:4f8:d16:2409::badd:ecaf 1] Our system has detected an
> 550-5.7.1 unusual rate of unsolicited mail originating from your IP
> address. To 550-5.7.1 protect our users from spam, mail sent from your IP
> address has been 550-5.7.1 blocked. Please visit
> http://www.google.com/mail/help/bulk_mail.html 550 5.7.1 to review our Bulk
> Email Senders Guidelines. h46si16725451eex.133 - gsmtp (in reply to end of
> DATA command)
>
> Needless to say, that if I use IPv4 Google accepts every mail.
>
> Dis this happened to anyone else?

as reported I have the same problem and working with the "solution" to
only send over IPv4 to Google. I have correct DNS seetings including PTR
and SPF and I'm able to send to MTAs with really strict checking over IPv6

<***@gmail.com>: host gmail-smtp-in.l.google.com[2a00:1450:4001:c02::1a]
said: 550-5.7.1 [2a01:4f8:d16:4114:feed:1bad:beef:dead 1] Our
system
has 550-5.7.1 detected an unusual rate of unsolicited mail
originating from
your IP 550-5.7.1 address [...]

Just an idea:
Google is blocking the complete 2a01:4f8::/32AS24940
(HETZNER-RZ-NBG-IPV6-BLK1) and doesn't care abut seperate subnets like
Luigi's 2a01:4f8:d16:2409::/64 or my 2a01:4f8:d16:4114::/64 :-(

Andreas

[Wietse Venema]

Andreas Herrmann:

> <***@gmail.com>: host gmail-smtp-in.l.google.com[2a00:1450:4001:c02::1a]
> said: 550-5.7.1 [2a01:4f8:d16:4114:feed:1bad:beef:dead 1] Our
> system
> has 550-5.7.1 detected an unusual rate of unsolicited mail
> originating from
> your IP 550-5.7.1 address [...]
>
> Just an idea:
> Google is blocking the complete 2a01:4f8::/32AS24940
> (HETZNER-RZ-NBG-IPV6-BLK1) and doesn't care abut seperate subnets like
> Luigi's 2a01:4f8:d16:2409::/64 or my 2a01:4f8:d16:4114::/64 :-(

http://www.google.com/safebrowsing/diagnostic?site=AS:24940

"Of the 241091 site(s) we tested on this network over the past
90 days, 5227 site(s), including, for example, mashakelso.ru/,
air-leader.ru/, viz-k.ru/, served content that resulted in
malicious software being downloaded and installed without user
consent."

So your idea looks plausible.

Wietse

[Luigi Rosa]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Wietse Venema said the following on 10/10/2013 02:24:

>> Not sure if that's what you mean but a quick check of main.cf in the
>> postfix 2.10.2 RPM for F19 and postfix 2.6.6 RPM for CentOS 6.4 shows:
>>
>> # Enable IPv4, and IPv6 if supported inet_protocols = all
>
> Damned morons. They break Postfix for sites that have IPv4 only (*) and
> they cause bad PTR problems for sites that turn on IPv6 as discussed on
> this list.

For the records: I asked the CentOS mailing list and they told me that the
configuration is in the RH^H^Hupstream vendor.

So a bug should be filed in RedHat in order to try to fix this issue.



Ciao,
luigi

- --
/
+--[Luigi Rosa]--
\

Leibowitz's Rule: When hammering a nail, you will never hit your finger
if you hold the hammer with both hands.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJWzcgACgkQ3kWu7Tfl6ZStHgCgiX3lNxRzhs/SusQocPVafwT3
LDoAmwWdNPR/L5iyzo+JSmFKEyDGXJ4f
=Wvpz
-----END PGP SIGNATURE-----

[Luigi Rosa]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Wietse Venema said the following on 10/10/2013 15:24:

>> Just an idea: Google is blocking the complete 2a01:4f8::/32AS24940
>> (HETZNER-RZ-NBG-IPV6-BLK1) and doesn't care abut seperate subnets like
>> Luigi's 2a01:4f8:d16:2409::/64 or my 2a01:4f8:d16:4114::/64 :-(
>
> http://www.google.com/safebrowsing/diagnostic?site=AS:24940
>
> "Of the 241091 site(s) we tested on this network over the past 90 days,
> 5227 site(s), including, for example, mashakelso.ru/, air-leader.ru/,
> viz-k.ru/, served content that resulted in malicious software being
> downloaded and installed without user consent."
>
> So your idea looks plausible.

I wil try to open a ticket about this on Hetzner helpdesk. Thank you for
pointing out this issue.

Ciao,
luigi

- --
/
+--[Luigi Rosa]--
\

Memory is like an orgasm. It?s a lot better if you don?t have to fake it.
--Seymour Cray on virtual memory

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJWzmAACgkQ3kWu7Tfl6ZSvCgCdF2QyAgdd5t+9LOk76r4dDDOm
u1cAn0UivSWYaCmOAK4mim7CPI1jf7HT
=yL1f
-----END PGP SIGNATURE-----

[Alexander Wasmuth]

On 10.10.2013, at 14:55, Andreas Herrmann <s...@physik.tu-berlin.de> wrote:

> <***@gmail.com>: host gmail-smtp-in.l.google.com[2a00:1450:4001:c02::1a]
> said: 550-5.7.1 [2a01:4f8:d16:4114:feed:1bad:beef:dead 1] Our
> system
> has 550-5.7.1 detected an unusual rate of unsolicited mail
> originating from
> your IP 550-5.7.1 address [...]
>

> Just an idea:
> Google is blocking the complete 2a01:4f8::/32AS24940
> (HETZNER-RZ-NBG-IPV6-BLK1) and doesn't care abut seperate subnets like
> Luigi's 2a01:4f8:d16:2409::/64 or my 2a01:4f8:d16:4114::/64 :-(

I am not so sure if this is the reason, I have (and had) no problems sending to google and I am in the same network range (Hetzner):

Oct 10 19:12:46 tldr postfix/smtp[1791]: 5E0AAF0246: to=<xxx>, relay=aspmx.l.google.com
[2a00:1450:4001:c02::1b]:25, delay=2.3, delays=0.18/0.01/0.38/1.8, dsn=2.0.0, status=sent (250 2.0.0
OK 1381425166 x49si37444641een.324 - gsmtp)

-Alex

[Dotan Cohen]

On Mon, Oct 7, 2013 at 9:05 PM, Dominik George <n...@naturalnet.de> wrote:
>> I would love to know the rest of your reasons for blocking Google. A
>> few months ago I moved our company's email to Gmail and users are
>> extremely happy. Maybe there are some things that we are ignorant of.
>
> Just read <Pine.BSM.4.64L.13...@herc.mirbsd.org>. My mate
> got it sumemd up quite well.
>

Thanks, but I don't have access to you ~/.pine directory!

I'll dig through the thread, though, I'm sure that I'll find the post. Thanks!

--
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com

[Dominik George]

> > Just read <Pine.BSM.4.64L.13...@herc.mirbsd.org>. My mate
> > got it sumemd up quite well.
> >
>
> Thanks, but I don't have access to you ~/.pine directory!
>
> I'll dig through the thread, though, I'm sure that I'll find the post. Thanks!

It was posted to the list, so you will have received it, and any
reasonable MUA can search for it. Giving publlicm essage IDs is a
perfectly valid way of pointing to a message on a list.

[Wietse Venema]

Dominik George:

> > > Just read <Pine.BSM.4.64L.13...@herc.mirbsd.org>. My mate
> > > got it sumemd up quite well.
> > >
> >
> > Thanks, but I don't have access to you ~/.pine directory!
> >
> > I'll dig through the thread, though, I'm sure that I'll find the post. Thanks!
>
> It was posted to the list, so you will have received it, and any
> reasonable MUA can search for it. Giving publlicm essage IDs is a
> perfectly valid way of pointing to a message on a list.

The string 'Pine.BSM.4.64L.1310010843490.20824' does not appear in my
postfi...@postfix.org folder, nor does that string appear in
my postfi...@postfix.org bounces folder.

The only messages that contain this string are your posting, and
follow-ups / bounces of your posting.

Perhaps the message was posted to some other forum that relays
messages into postfi...@postfix.org.

Wietse

[Stan Hoeppner]

On 10/13/2013 7:43 AM, Dominik George wrote:
>>> Just read <Pine.BSM.4.64L.13...@herc.mirbsd.org>.

> It was posted to the list, so you will have received it, and any
> reasonable MUA can search for it.

Then Thunderbird is not a "reasonable MUA", even though it's the 2nd or
3rd most widely used...

> Giving publlicm essage IDs is a
> perfectly valid way of pointing to a message on a list.

You must live on another planet, or in some parallel universe, because
this is not a valid way of referencing the location of an archived list
post.

FWIW, Googling for the string

Pine.BSM.4.64L.13...@herc.mirbsd.org

turns up zero results. Hitting http://herc.mirbsd.org/ in a web browser
provides no link to search a list archive, nor even suggests it hosts a
mailing list.

--
Stan

[Dominik George]

> > It was posted to the list, so you will have received it, and any

> > reasonable MUA can search for it. Giving publlicm essage IDs is a

> > perfectly valid way of pointing to a message on a list.
>

> The string 'Pine.BSM.4.64L.1310010843490.20824' does not appear in my
> postfi...@postfix.org folder, nor does that string appear in
> my postfi...@postfix.org bounces folder.

Yes. I asked the author, and it was bounced by your mailman because the
author is not a list member. Apparently, you haven't moderated it.

-nik

--
<Natureshadow> Auf welchem Server liegt das denn jetzt…?
<mirabilos> Wenn es nicht übers Netz kommt bei Hetzner, wenn es nicht
gelesen wird bei STRATO, wenn es klappt bei manitu.

[Wietse Venema]

Stan Hoeppner:
[ Charset ISO-8859-1 unsupported, converting... ]

> On 10/13/2013 7:43 AM, Dominik George wrote:
> >>> Just read <Pine.BSM.4.64L.13...@herc.mirbsd.org>.
>

> > It was posted to the list, so you will have received it, and any
> > reasonable MUA can search for it.
>

> Then Thunderbird is not a "reasonable MUA", even though it's the 2nd or
> 3rd most widely used...
>

> > Giving publlicm essage IDs is a
> > perfectly valid way of pointing to a message on a list.
>

[Wietse Venema]

Dominik George:

> > > It was posted to the list, so you will have received it, and any

> > > reasonable MUA can search for it. Giving publlicm essage IDs is a

> > > perfectly valid way of pointing to a message on a list.
> >

> > The string 'Pine.BSM.4.64L.1310010843490.20824' does not appear in my
> > postfi...@postfix.org folder, nor does that string appear in
> > my postfi...@postfix.org bounces folder.
>
> Yes. I asked the author, and it was bounced by your mailman because the
> author is not a list member. Apparently, you haven't moderated it.

postfi...@postfix.org is not a moderated mailing list. All
non-subscriber mail goes to /dev/null.

Wietse

[Stan Hoeppner]

On 10/13/2013 8:35 AM, Dominik George wrote:
>>> It was posted to the list, so you will have received it, and any
>>> reasonable MUA can search for it. Giving publlicm essage IDs is a
>>> perfectly valid way of pointing to a message on a list.
>>
>> The string 'Pine.BSM.4.64L.1310010843490.20824' does not appear in my
>> postfi...@postfix.org folder, nor does that string appear in
>> my postfi...@postfix.org bounces folder.
>
> Yes. I asked the author, and it was bounced by your mailman because the
> author is not a list member. Apparently, you haven't moderated it.

If it has salient content, post the HTTP URL.

--
Stan

[Dominik George]

http://blog.gmane.org/gmane.os.miros.general/month=20131001

--
# apt-assassinate --help
Usage: apt-assassinate [upstream|maintainer] <package>

[Stan Hoeppner]

On 10/13/2013 1:12 PM, Dominik George wrote:
> On Sun, Oct 13, 2013 at 01:09:52PM -0500, Stan Hoeppner wrote:
>> On 10/13/2013 8:35 AM, Dominik George wrote:
>>>>> It was posted to the list, so you will have received it, and any
>>>>> reasonable MUA can search for it. Giving publlicm essage IDs is a
>>>>> perfectly valid way of pointing to a message on a list.
>>>>
>>>> The string 'Pine.BSM.4.64L.1310010843490.20824' does not appear in my
>>>> postfi...@postfix.org folder, nor does that string appear in
>>>> my postfi...@postfix.org bounces folder.
>>>
>>> Yes. I asked the author, and it was bounced by your mailman because the
>>> author is not a list member. Apparently, you haven't moderated it.
>>
>> If it has salient content, post the HTTP URL.
>
> http://blog.gmane.org/gmane.os.miros.general/month=20131001

WRT the first point in the blog post, Thorsten is incorrect. Google
does publish lists of their outbound IPs via their SPF records.

~$ dig txt _netblocks.google.com _netblocks2.google.com

You may want to pass this along.

--
Stan

[Dominik George]

> > http://blog.gmane.org/gmane.os.miros.general/month=20131001
>
> WRT the first point in the blog post, Thorsten is incorrect. Google
> does publish lists of their outbound IPs via their SPF records.
>
> ~$ dig txt _netblocks.google.com _netblocks2.google.com

Sure, but how would you reliably whitelist them? We got information
directly from a Google lackey that this list may change at any time
because of their way to deploy servers, and I have not heard of a way to
dynamically whitelist all SPF-allowed MXs in, let's say, postgrey. You
can whitelist sender, recipients or client - now, whitelisting a sender
domain is not helpful because any domain might be Google hosted. There
is, in fact, no reliable lsit of *all* mail hosts that will ever (as in,
for a long time in the future) be the sending MTAs of Google-hosted
domains.

-nik

--
<burny> Ein Jabber-Account, sie alle zu finden; ins Dunkel zu treiben
und ewig zu binden; im NaturalNet, wo die Schatten droh'n ;)!

[Dominik George]

> There is, in fact, no reliable lsit of *all* mail hosts that will ever
> (as in, for a long time in the future) be the sending MTAs of
> Google-hosted domains.

Apart from that, I am tired of implementing exceptions for each and
every big proprietary mail provider out there. If a company desires to
take part in federated e-mail communicaiton, I expect them to set up
there stuff the way others expect it. If there setup is too huge to
manage it without awkward tricks, like Google dynamically assigning
roles to servers and not even reliably using subnets, whatever, for
certain roles, then they are by definition not up to the task of
operating it, be it for conceptional or personnel limitations. If we go
ahead and teach all _other_ mail systems to fit their needs, we
effectively do the work their customers pay them for.

I am close to deciding not to opt-in to that and simply not accepting
their mail if I can't using standard configurations.

-nik

--
# apt-assassinate --help
Usage: apt-assassinate [upstream|maintainer] <package>

[/dev/rob0]

On Sun, Oct 13, 2013 at 09:26:12PM +0200, Dominik George wrote:
> > There is, in fact, no reliable lsit of *all* mail hosts that will
> > ever (as in, for a long time in the future) be the sending MTAs
> > of Google-hosted domains.
>
> Apart from that, I am tired of implementing exceptions for each and
> every big proprietary mail provider out there. If a company desires
> to take part in federated e-mail communicaiton, I expect them to
> set up there stuff the way others expect it. If there setup is too
> huge to manage it without awkward tricks, like Google dynamically
> assigning roles to servers and not even reliably using subnets,
> whatever, for certain roles, then they are by definition not up to
> the task of operating it, be it for conceptional or personnel
> limitations. If we go ahead and teach all _other_ mail systems to
> fit their needs, we effectively do the work their customers pay
> them for.
>
> I am close to deciding not to opt-in to that and simply not
> accepting their mail if I can't using standard configurations.

Amen. Along those lines, Postfix 2.11 will be the most important
minor version since the introduction of postscreen itself in 2.8. At
last we can have the benefits of postscreen zombie detection without
the pain of greylisting.

Gmail and just about every big proprietary mail provider out there
maintains lists of their hosts on dnswl.org. Postscreen with a
relatively simple DNSBL configuration, including a negative point
lookup for list.dnswl.org, will make this all very easy and low
maintenance. (Consider signing up for dnswl.org yourself; it costs
only a few minutes of your time.)

http://www.postfix.org/postconf.5.html#postscreen_dnsbl_whitelist_threshold
http://dnswl.org/

My postscreen page, not yet updated for 2.11:
http://rob0.nodns4.us/postscreen.html
--
http://rob0.nodns4.us/ -- system administration and consulting
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: