Re: [Q] I got one message from Mailer-Daemon

Byung-Hee HWANG (황병희, 黃炳熙) posted on Sat, 07 Oct 2017 21:00:03 
+0900 as
excerpted:

> Hellow! Days ago i did followup via gmane.os.freebsd.questions. And
> then, someday, i got one message [1].
> 
> Is that my fault? Or FreeBSD MX server is bad guy? And i believe that
> always Gmane system is perfact!!!
> 
> [1] https://raw.githubusercontent.com/soyeomul/Gnus/MaGnus/ss/36

I don't claim to be an authority on tracing email headers by a long shot, 
but as best I can make out from the error message and the headers of that 
message, compared with the headers as reported by gmane for the question 
message I just quoted above...

1) The freebsd listserv is configured to do a reverse-name-lookup on IP 
addresses attempting to connect to them to send mail.  This would be an 
anti-spam measure.

2) The IP address that apparently connected to them to relay that message 
was 195.159.176.226.

3) This IP address has not been registered with the reverse-name-lookup 
database, so there's no official domain name that corresponds directly to 
that address.  (By contrast, there may well be one or more domain names 
that resolve to 195.159.176.226, but there's no entry for the reverse 
resolution of IP address to domain name.)

I verified this here with a (reverse) host lookup.  No reverse lookup 
available for that IP address.  This is the actual problem as reported by 
the notification you got.


OK, so what /do/ we know about 195.159.176.226?  In particular, is that 
you, or gmane, or someone else, and is the policy leading to that 
rejection by the fbsd listserv "reasonable" or "common" as an anti-spam 
measure or not?

4) Doing a tcp-traceroute for 195.159.176.226 results in the following 
(last few hops, note that I just used the default tcp-traceroute port 80, 
http/web, I could try mail instead but it shouldn't matter):

 9  nyk-bb4-link.telia.net (213.155.134.254)  70.840 ms  71.399 ms  
70.757 ms
10  kbn-bb4-link.telia.net (80.91.254.90)  166.271 ms  166.603 ms  
168.264 ms
11  oso-b4-link.telia.net (62.115.135.165)  178.793 ms  172.622 ms  
175.366 ms
12  broadnet-ic-305679-oso-b4.c.telia.net (213.248.84.234)  174.005 ms  
174.290 ms  175.781 ms
13  static210.banetele-cust.com (213.52.81.210)  179.562 ms  179.959 ms  
178.193 ms
14  s07i01.no.powertech.net (195.159.88.7)  178.858 ms  178.483 ms  
179.826 ms
15  wb.dsl.newmedia.no (212.71.75.118)  177.087 ms  175.219 ms  174.677 ms
16  195.159.176.226 [open]  176.263 ms  198.954 ms  176.044 ms


Hop 9 is obviously telia-newyork, telia being the backbone provider.  Hop 
10 is still telia; I don't know what kbn is, but given the hop time it's 
quite some distance from newyork, so likely across the ocean, likely the 
atlantic given newyork.

I'd guess oso in hops 11 and 12 to be oslo (norway).  Hop 13 jumps off 
the telia trans-atlantic backbone to a local/regional provider, banetele 
(which could be googled if necessary but it's not).

Hops 14 and 15 "no" seems to confirm my norway/oslo guess above.  15 
indicates dsl, which is interesting, and hints we're toward the end-point.

16 is our target 195.159.176.226, no reverse name resolution, but the 
port 80/http/web I traced is open.

5) Given that gmane is (or was, and appears to be still, at least partly, 
based on this) Norway-based, and you appear to be Korean based (from the 
X-Gnus-Location header in the link-quoted message), that strongly points 
to the gmane mail relay that direct-connected as 195.159.176.226 to the 
bsd listserv.

6) Meanwhile, doing a whois lookup on 195.159.176.226 yields (among less 
interesting information):

inetnum:        195.159.176.224 - 195.159.176.255
country:        NO
mnt-by:         POWERTECH-MNT
created:        2010-02-16T21:12:11Z
last-modified:  2010-02-16T21:12:11Z

address:        PowerTech Information Systems AS
address:        N-0104 Oslo
address:        Norway
created:        1970-01-01T00:00:00Z
last-modified:  2005-05-04T13:17:01Z

address:        Rolf Ottesen Grafisk Produksjon 
address:        1290 Oslo
address:        NORWAY
mnt-by:         NO-NEXTGENTEL-MNT
created:        2005-08-01T10:01:19Z
last-modified:  2005-08-01T10:01:19Z

% Information related to '195.159.0.0/16AS2116'

route:          195.159.0.0/16
mnt-by:         POWERTECH-MNT
created:        2017-09-30T06:58:11Z
last-modified:  2017-09-30T06:58:11Z

% Information related to '195.159.0.0/16AS5381'

route:          195.159.0.0/16
descr:          NO-POWERTECH
mnt-by:         POWERTECH-MNT
created:        1970-01-01T00:00:00Z
last-modified:  2001-09-22T09:33:10Z


So definitely Norway.  Records from 2001 to the present, with one just 
created/updated Sept 30.  (That 1970 record is the Unix epoc, indicating 
an unset time.)

Confirming the conclusion in #5, that this is gmane.

OK, so it's gmane's mail server that connected to the FBSD listserv that 
has the 195.159.176.226 address without a reverse-dns record, that the 
listserv was complaining about.

But is that a reasonable complaint, and the FBSD listserv antispam policy 
itself reasonable, placing the fault on gmane for not having its reverse-
dns records in order as can be reasonably expected, or not, placing the 
fault on the listserv policy for being unreasonable?

I'm not a mailserv/listserv admin, and I really don't know whether it's a 
reasonable policy or not, but my personal opinion is that something's 
wrong if there's no reverse-lookup record at all.  There really /should/ 
be such a record, and I'd consider it a lax admin to allow a host on the 
net, particularly in a role where trust is an issue as it is for mail 
servers /due/ to spam, without such a reverse lookup record.

More importantly, if I'm not mistaken, such lookups form part of the 
authorization chain for recent anti-spam measures such as domain-
authorized sender-permitted-from, etc, and without such records it 
becomes much harder to tell if a domain owner is authorizing legitimate 
email connections from a particular host, or not, making it a rogue spam 
server.

So my own most definitely not particularly qualified opinion is that the 
fault here is gmane's, due to them operating a mail server to relay our 
messages as posted to gmane, back to the various listservs, without a 
reverse-dns record, thus triggering message refusals in listservs such as 
the FBSD server here with strict anti-spam policies, because from the 
listserv perspective, gmane's mail server looks like a rogue spam server.


Of course if you get a more authoritative answer from gmane admins that 
contradict this, go with that, but sometimes they take awhile (could be 
months) to respond, and in the mean time, it does look like a gmane fault 
to me.


One possible workaround for lists such as the FBSD list that you know 
reject messages sent via gmane, would be to mail your replies directly to 
the list address, bypassing gmane, instead of posting them to gmane via 
nntp, for gmane to attempt to relay, since you know that fails.

To do that you will of course need the list's email address, but that's 
in the bounce message you linked:

<[email protected]>

Mail your replies there directly, instead of trying to post them to gmane, 
and hopefully you'll have better luck, with the post then showing up on 
gmane after the listserv posts it, just as gmane would handle other 
messages that didn't involve sending thru gmane in the first place.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


_______________________________________________
Gmane-discuss mailing list
[email protected]
http://hawk.netfonds.no/cgi-bin/mailman/listinfo/gmane-discuss