On the inoc-dba subject

Is it really cluefull to have this paragraph?

"
Please make sure that your spam filters allow email from "pch.net"
before you sign up, since we will need to automatically verify your
email address.
"

Since we all know that whitelisting and blacklisting by in-band stated "from" email address is quite wrong-headed, from a clue standpoint.

Perhaps something like this?

"
Please make sure that your spam filters allow email sent from <ip-addresses> with a from address of pch.net before you sign up, since we will need to automatically verify your email address.
"

Where <ip-addresses> is the output of a dig command against the outgoing smtp servers sending the notifications?

In general, ML and other automated email things should have a way to display the bounce to the user, which would mean storing it for some small period of time. Otherwise it becomes rather difficult to do the right thing filtering wise.

(Google seems to do this for their notifications that get 45x/55x)

Joe

"
Please make sure that your spam filters allow email from "pch.net"
before you sign up, since we will need to automatically verify your
email address.
"

Since we all know that whitelisting and blacklisting by in-band stated
"from" email address is quite wrong-headed, from a clue standpoint.

Perhaps something like this?

"
Please make sure that your spam filters allow email sent from
<ip-addresses> with a from address of pch.net before you sign up, since
we will need to automatically verify your email address.
"

Where <ip-addresses> is the output of a dig command against the outgoing
smtp servers sending the notifications?

pch.net publishes a SPF record:
"v=spf1 ip4:204.61.210.70/32 mx mx:woodynet.net a:sprockets.gibbard.org

Besides going from soft-fail (~all) to fail (-all), they are already
giving you the tools you need to validate a MAIL FROM: claim.

Rubens

Rubens Kuhl Jr. wrote:

pch.net publishes a SPF record:
"v=spf1 ip4:204.61.210.70/32 mx mx:woodynet.net a:sprockets.gibbard.org
a:ghosthacked.net ~all"

Besides going from soft-fail (~all) to fail (-all), they are already
giving you the tools you need to validate a MAIL FROM: claim.

Rubens

Thats all very well and good, but advising people who do not validate with spf to whitelist by domain name is an over-simplification.

*koff* .forwards etc cans of worms *koff*

Woody's clear enough there - make sure your filters allow email from us.

Minor but tedious details like "how to do that" can best be left to
individual administrators. Probably get the job done without turning
on spf lookups.

So call it additional clue-boundary to entry and be done with this silly thread.

Besides, the site doesn't specify how to filter/whitelist...just to make sure you can accept mail from pch.net. A simple person might take that to mean "I better allow any @pch.net from address" but that's not what the site says.

Advising people who do not validate with spf to

    > whitelist by domain name is an over-simplification.

In fact, we don't advise them to do either one. The cautionary message is
to remind the significant (~10%) portion of people who try to sign up
using blocked email addresses why it might be that they're failing and not
seeing any error messages from us.

Believe me, we'd much prefer people found better ways of dealing with
spam.

                                -Bill