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

[Douglas Otis <[e-mail]>]

On Jun 22, 2009, at 3:58 AM, Alessandro Vesely wrote:

> 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.

This suggests poor Acceptable Use Policies.

> I don't follow how OpenId would help.

Stable identifiers might mitigate some vetting.

>> 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.

The domain administrating MTAs ARE the truly responsible Domains.  It  
would be speculation whether an entity offering authorization actually  
originated the messages.   CSV was intended to affirm the SMTP  
operation by a specific domain.   Any CSA record not expressing an  
affirmation MAY be assumed an indication of the host not being  
authorized.

> 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.)

Only the HELO mechanism of SPF comes close, but SPF itself does not  
offer a means to limit the SPF record scope.

>> 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).

Authorization does not indicate either administration or origination.   
Any need for authorization records for acceptance will be extorting  
the publication of records that might allow blame to be incorrectly  
placed.   Hardly a way to ensure providers remain accountable. :^(

>> 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.

It is actually eleven TXT SPF records that might be needed.  The SPF  
spec allows 10 mechanisms, where there might be a need for 10  
subsequent target resolutions per mechanism .  The actual limit of DNS  
transactions is at 111.

>> b) may not qualify any specific IP address for a positive result.
>
> Yes, especially if not used.

Even when used.  The record can end in +all or use some exists().  SPF  
also allows the use of macros.  These macros can be cached, and yet  
cause recipients to generate different transactions based upon  
changing local-parts or IP addresses, for example.

>> 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.

SMTP (RFC 5321) section 2.3.5 does not stipulate the resolution of the  
domain asserted by EHLO as using A,  AAAA or MX records.  It also  
allows use of address literals.  Section 4.1.4 then indicates  
resolution failure of the EHLO domains or mismatch of address literals  
MUST NOT be cause for refusing messages.  Likewise, SPF also fails to  
impose negative assertions for ELHO domain failures for Mail-From or  
PRA domains, of course.

> which is wrong. EHLO only allows it to declare its identity.  
> Declaring the affiliation is VHLO's raison d'être.

Since VHLO can be asserted by bad actors, there is no reason to trust  
the guidance offered.

> 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.

Trusting the MTA via CSV/CSA does not impact message handling, unlike  
problems created by Sender-ID and SPF.

>> 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?)

Most domains outsource email services.  This is a growing trend as  
email becomes more heavily abused.

>> 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.

The lackadaisical attitude ends abruptly when reputation is misapplied  
as a result of unverifiable assumptions of message origination when  
erroneously based upon authorizations.  This would be extending SPF  
well beyond its intended purpose.

>> 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.

Any negative assertions based upon SPF might be misapplied against  
PRAs not protected by the provider.  Misapplication of negative  
assertions might also be due to SPF when Mail-Froms are also not  
protected by the provider.  Have you ever seen a SLA that stipulates  
PRA or Mail-From exclusivity?

>> 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.

If the IP address were only associated with that of the MTAs, users  
would be able to seek services from any other provider.  When a  
provider's lack of stewardship impacts user's domains, then users are  
left without resource, while the provider remains free to seek more  
victims.

>> 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?

SPF is a scheme aimed at authorizing providers and thereby shifting  
blame.

> If I use a vanity address I have to trust an ESP who provides that  
> service and set MX and SPF RRs accordingly.

Why do you feel there is a need to publish SPF records?

> 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.

Of course, trusting an ESP to keep incoming email confidential is  
important, and is often covered in SLAs and various laws.   But why  
are users required to blindly trust that email providers will filter  
other users outbound email?  It is unlikely that this filtering is  
covered by SLAs or by various laws.

>> 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?

CSV is only about who is administrating the MTA.  It has nothing to do  
with who might be inadvertently held responsible based upon Mail-Froms  
or the PRAs.

>> 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... :-(

Unfortunately, when risks associated with SPF with respect to DNS was  
explained, SPF advocates expressed distain for DNS.

-Doug