There is a much bigger problem with the IETF mail servers, I’ve reported it
several times to AMS and other folks from the IAOC have been informed as I
understand, but nobody is providing any solution, and as a consequence, we are
subjected to receive SPAM, as we are accepting emails from subscribers which
are in spam black-lists.
This problem also means that if you own mail server (which many of us don’t
control), is configured to reject messages from black-listed IPs, then when you
reject emails from such folks, the IETF considers that your email address is
bouncing, and unsubscribes you. I’ve this problem every other week, in the
general area list and also in some others related to DNS (which probably means
that the black-listed servers are from people contributing mainly to DNS
exploders).
This is my view about the problem, which has been ignored up to now:
1) IETF is accepting messages from subscribers with MX which are Blacklisted.
2) IETF send those emails also with the original headers.
—> that’s why when AMS staff send the logs that I requested, it appears
like the IETF is black-listed, which is not the case, but a couple of
senders to IETF exploders.
3) Mail servers inspect the IETF and original headers looking for
black-listed servers.
4) If they are strict, bounce emails from IETF even if the IETF records
aren’t black-listed but the original sender MX is black-listed
So, we need a policy here. Either:
A) IETF doesn’t accept messages from black-listed servers.
——> if we don’t do so, we may be affecting ALL the subscribers, and even
worst, a SPAMER could subscribe to IETF and send SPAM to ALL our
subscribers. An even worst, once IETF mail es bounced because the
black-list, some antispam systems increase the IETF rating as “possible
spammer”, which is not good.
Or
B) IETF clean-up the original sender header (before sending to the mail
exploder) to avoid bounces.
Alternatively, not sure how this will work, we could just allow “bounces”
from subscribers (may be even a big number such as 40-50), instead of
disabling the membership.
We may need to retry more times sending emails to subscribers, increasing the
time between retries, and after no bouncing for “x” many days, resetting
counters for this subscriber.
When I got the logs from AMS (august 2015), the offenders where:
149.171.193.32 - Australia Sydney University Of New South Wales, black-listed
by sorbs
And
198.57.247.250 - United States New York City Unified Layer, black-listed by
spamhaus
Regards,
Jordi
-----Mensaje original-----
De: ietf <ietf-bounces(_at_)ietf(_dot_)org> en nombre de John Levine
<johnl(_at_)taugh(_dot_)com>
Responder a: <johnl(_at_)taugh(_dot_)com>
Fecha: jueves, 22 de octubre de 2015, 17:42
Para: <ietf(_at_)ietf(_dot_)org>
Asunto: DMARC stuff
Totally the wrong thread, so I'll apologize profusely now.
Subject line changed.
GMail is set to turn on DMARC reject strict by sometime early next
year [1] being one of the last big web mail providers to do so; so,
Mailman "From:" rewriting (or turning on the ability for IETF list
subscribers to toggle this for their sends) might need to be done for
IETF lists.
Members of the DMARC group have submitted two drafts
draft-andersen-arc-00 and draft-jones-arc-usage-00 which describe a
mutation of DKIM intended to let mailing lists coexist with DMARC
without having to do ugly hacks like rewriting the From: line. I have
reason to believe that several large mail systems intend to implement
this reasonably soon.
The obvious place to discuss this is the DMARC WG, not here.
R's,
John