Re: [Asrg] What are the IPs that sends mail for a domain?

Douglas Otis wrote:
> Each recipient will likely attempt to accept either none or some amount 
> of public email based upon normal profiles.  To remain on the safe size 
> typical profiling, this requires the output issued by bad actors be 
> mitigated in some fashion.  This might be done by using rate limiting 
> combined with disabling accounts faster than bad actors can 
> re-subscribe.  Funny how little anti-spam efforts concentrate on account 
> setup.  Things like Open-ID might help in this area, for example.
Hm... residential accounts with asymmetric rates already complain 
about latency. For example, I've been setting a number of extensions 
to deliver to the Sent folder, so as to allow to save sent mail by Bcc 
rather than copying, for clients that allow it, in order to save time 
in case of large attachments.
As for forcefully disabling accounts, one needs a legal authority to 
break a commercial agreement. For some reasons, they tend to move 
quicker for child porn than spammers. Last time I talked about spam to 
our postal police, the first thing he said has been "me too". Since we 
lack police resources for snatches and rapes, I felt arrogant asking 
them to go after my spammer, and gave up.
I don't follow how OpenId would help.

> > OTOH, sender identification by domain could also be a way to attribute 
> > responsibility. Strictly speaking, it is not necessary to use a domain 
> > in order to send as an SMTP client. However, in practice one needs an 
> > email address to do any legitimate use of SMTP, and hence a domain is 
> > required.
> CSV was to offer a DNS record type that explicitly declared a host as being 
> an outbound MTA.  This would not in itself prevent abuse, but would help to 
> determine which compromised systems might be sending email and resolving 
> which domain is administrating the MTA.
It didn't help retrieving the responsible domain, though. Furthermore, 
it didn't do ranges, thus making it laborious to deny sending to a 
bunch of hosts. In addition, CSA spec curiously had a "MAY" for an 
non-authorized host with a non-ignored target resulting in weight 0.
However, _client._smtp.domain-name records authorizing various targets 
would be almost equivalent to setting SPF, or MX heuristics. (I'll 
possibly add that to the next vhlo draft.)
> SPF does not work well at resolving a domain that should be held 
> accountable for a few reasons-
One reason is that it works the other way around: given the domain, 
authenticate an IP address as a mail transmitter (thus implicitly 
authorizing it to send mail).
>  a) risks high and impractical transaction overheads at attempts to 
> indirectly reference the customers of a provider.
I agree it is more complicated than the average users need. 
Presumably,  the spec is so for being usable in a wider number of 
cases. 10 lookups, however, seems reasonable to me.
>  b) may not qualify any specific IP address for a positive result.
Yes, especially if not used.

>  c) Mail From or PRA references do not resolve which domain administered 
> the MTA or actually sent the message.
AFAIK, all discussions eventually reach the conclusion that the 
receiving server does not know which domain administers the client 
MTA. FWIW the old ietf-marid-csv-csa asserts that
  The SMTP [RFC2821] [RFC0821] protocol permits a client to declare
  its affiliation, by asserting a domain name in the HELO or EHLO
  announcement.

which is wrong. EHLO only allows it to declare its identity. Declaring 
the affiliation is VHLO's raison d'être.
At any rate, forwarding -when MAIL FROM and PRA differ- requires a 
framework different from SMTP to administer legitimate use of third 
parties' email addresses. Classic mailing lists (as this one) comply 
with various privacy laws, but most direct marketing lists and users' 
.forward files don't.
>  d) holds customers of a provider accountable for the provider's 
> stewardship without any solid evidence of their involvement.
See below (at Why do you so often mention authorizing a provider?)

> Who said providers need to be criminal for naive users to be harmed by 
> SPF?  A recipient may check PRAs, where providers may check Mail-Froms.
Formally, SPF only recommends to check MAIL FROM. Any other use of the 
underlying mechanism is just heuristics.
> Once a user's domain reputation is damaged due to receiver error, how 
> can reputations be restored and then protected?
That has nothing to do with SPF. People getting mad about stopping 
spam will invent _any_ rule. I get a score 1.245 for HOST_EQ_IT in 
Fred's Header rules, even if the .it ccTLD never had an SPF record.
(Concentration camps are further down that road.)

>  When asked in the past, 
> those customers are advised to obtain their own IP address.
If responsibility were attributed correctly, this wouldn't be needed 
any more. Of course, if I had an address @spammer, I'd have to share 
their fate, but my address is my choice.
> > > [...]  Without knowing the IP address of the provider, 
> > > it would be extremely foolish to conclude any level of identification 
> > > assurance, especially "moderately strong".
> > IMHO, the domain registrants (resulting from whois records) provide an 
> > identification that is comparable in strength, but finer in granularity.
> It is wrong to hold someone accountable for authorizing a provider once 
> authorization becomes a requisite for acceptance.  Users are thereby 
> extorted into assuming risks well beyond their control.
Why do you so often mention authorizing a provider? ISP and ESP are 
two different activities, although didn't use to. If I use a vanity 
address I have to trust an ESP who provides that service and set MX 
and SPF RRs accordingly. The ESP may or may not be my connection 
provider. The risk is related with choosing the ESP correctly, so that 
trust is well put. That trust is not different for users of an 
existing domain, who don't control the domain, but have to trust its 
admins.
> Instead, providers should be held accountable by requiring CSV records 
> with a limited number of EHLO host names over time.
But the targets of those records need an address too. What's the 
difference between writing an IP number in an SPF rather than an A RR?
> This approach better defends receiving MTAs from abuse with lower 
> overhead, and better controls DNS related exploits that threaten the 
> entire Internet.
All of them rely on DNS, and some posts in that "DNS over SCTP" thread 
showed that various people think just of http when they figure out 
"typical" DNS usage... :-(
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg