Ah, yeah, I've been using it for a while. It often replies something like:
[email protected] (default, no info)
In this case, I can use a verifysmtp command[*] like so:
~:tmp# verifysmtp [email protected]
<[email protected]>: verification failed
>>> mail.genonop.cf [89.40.114.11]:
>>> RCPT TO:<[email protected]>
450 4.1.1 <[email protected]>: Recipient address rejected: User unknown in
virtual mailbox table
That command is more expensive than a lookup. This example domain is
particularly bad, since it would get a bounce only after the retry period has
elapsed.
The question is whether I should shoot on sight when I see messages
authenticated by genonop.cf. And, if yes, how and when should I make such
decision?
There used to be a DKIM Authenticated Blocklist[†], which I always had
difficulty to understand. Why on earth, one would wonder, would genonop.cf add
a DKIM-Signature to the messages it mails out if that's how recipient will
immediately discard them. Whitelisting would seem to make more sense for cases
where detection is based on sender's voluntary actions. However, logic doesn't
apply to domains managed by dunces, does it?
Best
Ale
--
[*] https://www.courier-mta.org/verifyfilter.html
[†]
https://web.archive.org/web/20110726001244/http://www.dkim-reputation.org/usage/
On Wed 19/Feb/2020 15:54:49 +0100 Al Iverson via mailop wrote:
> There's a domain-based abuse contact registration system already that
> is relatively commonly used. Perhaps it is a bit US-centric. It is the
> Network Abuse Clearinghouse run by John Levine and you can find it at
> www.abuse.net.
>
> Cheers,
> Al Iverson
>
> On Wed, Feb 19, 2020 at 3:44 AM Alessandro Vesely via mailop
> <[email protected]> wrote:
>>
>> Hi all,
>>
>> Whenever an abusive message lands in our inboxes, some of us report it to the
>> relevant abuse team. Large mailbox providers deploy <spam> buttons or
>> folders
>> to automate such reporting. Smaller ones often don't have such equipment,
>> and
>> send reports manually, if at all.
>>
>> Besides feedback loops, RFC 6650 provides for sending unsolicited abuse
>> reports. The problem of where to send them is tackled like so:
>>
>> Deciding where to send an unsolicited report will typically rely on
>> heuristics. Abuse addresses in WHOIS [RFC3912] records of the IP
>> address relaying the subject message and/or of the domain name found
>> in the results of a PTR ("reverse lookup") query on that address are
>> likely reasonable candidates, as is the abuse@domain role address
>> (see [RFC2142]) of related domains. Unsolicited reports SHOULD NOT
>> be sent to email addresses that are not clearly intended to handle
>> abuse reports. Legitimate candidates include those found in WHOIS
>> records or on a web site that either are explicitly described as an
>> abuse contact or are of the form "abuse@domain".
>> https://www.rfc-editor.org/rfc/rfc6650.html#section-5.3
>>
>> Nowadays, abuse mailboxes by IP number can be automatically retrieved via
>> RDAP,
>> and in most cases they work.
>>
>> By-domain abuse mailboxes are more difficult. Of course, it is inadvisable
>> to
>> send complaints to abuse@domain if domain is not SPF- or DKIM- (or DNSWL-)
>> authenticated. Then, there are (authenticated) domains who miss an abuse@
>> mailbox.
>>
>> Since sending DMARC aggregate reports already implies saving some domain
>> information, it may make sense to also store whether an abuse mailbox for a
>> given domain exists. So I'd put a few questions:
>>
>>
>> Is it a more or less common practice to store sending domain information?
>>
>> If yes, is the existence of abuse@ part of that information? Are domains
>> without such feature considered less trustworthy in general? (I note that
>> providing fur an abuse@domain mailbox is not part of Hans-Martin' Ideas for
>> possible content for FAQ: "Best Practices for running a mail server".)
>>
>> If yes, when is that datum determined:
>> At domain insertion, via callout verification?
>> On receiving a bounce from an attempt to send a complaint?
>> Other?
>>
>>
>> Best
>> Ale
>> --
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> mailop mailing list
>> [email protected]
>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
>
_______________________________________________
mailop mailing list
[email protected]
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
