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

From: Alessandro Vesely <[email-masked]>
Date: Wed, 01 Jul 2009 16:20:12 +0200

John Leslie wrote:
>> In facts, we don't even have a term for "the accountable party related 
>> to an IP address".
>
>    Are you sure that's a useful concept?

Not at all. However, after noting that per-user accountability in the 
pgp/smime sense cannot be used for general email, the tendency seems 
to look after the IP address of the transmitters, much like pinching 
hackers on the fly is sometimes shown on the movies.

>    The CSV paradigm is that the operator of a MTA should exercise some 
> responsibility for what is sends. The HELO string identifies the MTA 
> (though not necessarily one string exclusively by one MTA), and the 
> DNS management for that domain-name string states whether that domain 
> exercises responsibility (and by automatic return of A)ddress RRs on 
> SRV queries, what IP address(es) that MTA uses).

The link from the MTA to its operator is still missing.

>    While this perhaps comes "close", it's not designating an "accountable 
> party"; and the IP address is related to the HELO string, not the other 
> way around. It does _not_ lead to an "accountable party" -- it merely 
> associates a reference string (the domain name) that we can use as a 
> query to reputation services.

To this end, I'd prefer the use of a domain name. One reason is that 
large ESP have many MTAs that can be used interchangeably. In 
addition, the person responsible for an MTA is not always identifiable 
(in Italy, the mandate to state who are the sysadmins of an MTA is 
being procrastinated every few months, since November 2008.) By 
contrast, domain registrants often have whois records pointing to them.

>> Rfc5068
>> associates accountability after submission with traceability features 
>> of the MSA, apparently suggesting that the first relaying thereafter 
>> is from an IP which is (indirectly) accountable for the message content.
>
>    Actually,
> "
> " Relaying and delivering employ policies that occur after submission and
> " are outside the scope of this document.
>
> RFC5068 deals with the operation of Mail Submission Agents. I don't agree 
> it even "suggests" how accountability should follow the message as it 
> winds its way to the recipient.

It does. Notwithstanding the sentence you quoted, there is a 
"Submission Accountability after Submission" paragraph in section 3.1, 
saying

       For a reasonable period of time after submission, the message
       SHOULD be traceable by the MSA operator to the authenticated
       identity of the user who sent the message.

A similar norm is mandated by anti-terrorism regulations, in the EU at 
least.

That way, accountability could be theoretically traced, _if_ the first 
submission followed those guidelines. While I can be reasonably sure 
that the connecting client is not an open relay, after IP based DNSBL, 
I have no means to know that the site either enforces the submission 
protocol in general, or did so for at least the messages it is about 
to relay.

Thus, it turns out that if an MTA does mixed MSA and old fashioned 
port 25 relaying for its clients, its IP cannot convey accountability.

---

From: Dotzero <[email-masked]>
Date: Wed, 1 Jul 2009 10:42:32 -0400

On Wed, Jul 1, 2009 at 10:20 AM, Alessandro Vesely<[email-masked]> wrote:
>
> Thus, it turns out that if an MTA does mixed MSA and old fashioned port 25
> relaying for its clients, its IP cannot convey accountability.
>

The fact that it cannot (may not?) convey accountability does not mean
that it cannot or should not be held accountable for what it emits.

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 01 Jul 2009 17:28:16 +0200

> that it cannot or should not be held accountable for what it emits.

I understand the 2nd "it" as referring to the MTA, not the IP address. 
It doesn't make much difference, since both of them are objects. 
AFAICS, the point is to hold _someone_ accountable, so that it might 
be theoretically possible to claim damage, in case. It is like an 
insurance, and postmasters tend to stipulate it with IP numbers rather 
than DNS names. Why?

---

From: John Leslie <[email-masked]>
Date: Wed, 1 Jul 2009 11:43:14 -0400

> The link from the MTA to its operator is still missing.

   CSV doesn't try to enforce any particular link, but that doesn't
imply there is none.

> contrast, domain registrants often have whois records pointing to them.

   I think I'm catching on: you want to link the MTA to a _registered_
domain.

   You should, IMHO, say so in the I-D: "domain" by itself doesn't
convey the idea of "registered domain".

>       identity of the user who sent the message.

   This deals _only_ with logging practices (or whatever magic) of the
operators of the Mail Submission Agent -- it implies nothing about
MTAs that may relay the message.

> A similar norm is mandated by anti-terrorism regulations, in the EU at 

   Indeed, various jurisdictions write laws and regulations. We should
allow for them wherever practical, but we can't adopt an international
standard to every jurisdiction's laws and regulations.

> protocol in general, or did so for at least the messages it is about 

   I do not believe that you'll know any better by linking to a
registered domain, but YMMV. I will stipulate that in the absence of
a reputation service, the _explicit_ link to a registered domain
gives a bit more clout to an assumption that the domain registration
information is a "responsible party"; but neither domain registrars
nor the VHLO draft would enforce much of anything. :^(

--
John Leslie <[email-masked]>

---

From: Dotzero <[email-masked]>
Date: Wed, 1 Jul 2009 12:55:02 -0400

On Wed, Jul 1, 2009 at 11:28 AM, Alessandro Vesely<[email-masked]> wrote:
> I understand the 2nd "it" as referring to the MTA, not the IP address. It
> doesn't make much difference, since both of them are objects. AFAICS, the
> point is to hold _someone_ accountable, so that it might be theoretically
> possible to claim damage, in case. It is like an insurance, and postmasters
> tend to stipulate it with IP numbers rather than DNS names. Why?

IP Addresses are used rather than DNS names because it is
significantly easier to dump a domain name and use a new one than to
dump an IP address (range) and migrate to another unless there are
compromised hosts involved. IP Addresses tend to be more trackable and
ultimately tied to an ISP (even if that carrier is an upstream).

I tend to think less in terms of legal and claiming damage and more
along the lines of self help. Drop route (or the milder form of reject
SMTP connections) tends to have a significant impact on what one deals
with from abusive IP space. I don't necessarily recommend this as the
first response but if one does not get a response from an abuse
contact.....

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 01 Jul 2009 20:37:37 +0200

John Leslie wrote:
>> 
>> [For accountability, I'd use] a domain name. One reason is that 

Yup. However, no official registration exists for, say, us.ibm.com or 
it.ibm.com. The latter two ones happen to have different hostmaster 
addresses, therefore it would not be correct for them to share the 
same accountability token "ibm.com". I can only trust the DNS about 
the legitimacy of such subdomain delegations.

OTOH, I don't know from the DNS whether a domain is registered at a 
reputable registry.

> convey the idea of "registered domain".

Thanks, I will.

> MTAs that may relay the message.

I thought "traceable" implied there is some token, such as Message-ID, 
that is logged on both submission and relay, so that one can retrace 
the path that a message took. Or would that have been termed 
"trackable", or whatever, instead?

> registered domain, but YMMV.

Agreed. If it is neither worse, it can be used interchangeably with IP 
based info, depending on convenience.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 1 Jul 2009 14:43:40 -0700

On Jul 1, 2009, at 7:20 AM, Alessandro Vesely wrote:

>> responsibility for what is sends. The HELO string identifies the  
>> MTA (though not necessarily one string exclusively by one MTA), and  
>> the DNS management for that domain-name string states whether that  
>> domain exercises responsibility (and by automatic return of  
>> A)ddress RRs on SRV queries, what IP address(es) that MTA uses).
>

Disagree.  Based on our results, when only a few domains publish an IP  
addresses of an Outbound MTA, it is rather safe to assume the domains  
represented by verified EHLO information resolve who is administrating  
the MTA.  When there are many domains, this appears to represent  
either MTAs operating behind a NAT, or compromised systems; sometimes  
both.  It appears to be rare for legitimate Outbound MTAs to change  
domain affiliations.  From a reputation standpoint, verified EHLO  
information offers stable identifiers in which to effectively and  
efficiently manage email abuse.  This method should scale since it  
establishes management hierarchy.

> addition, the person responsible for an MTA is not always  
> identifiable (in Italy, the mandate to state who are the sysadmins  
> of an MTA is being procrastinated every few months, since November  
> 2008.) By contrast, domain registrants often have whois records  
> pointing to them.

While larger ISPs are likely to have a few hundred outbound MTAs, they  
represent a very small percentage of overall legitimate Outbound  
MTAs.  Larger ISPs likely represent less than a few hundred thousand  
Outbound MTAs, over several million other legitimate MTAs.  A  
reputation system might replace the existence of CSV records, however  
initial acceptance and tracking can be improved by the presences of  
CSV records.  Being able to identify legitimate Outbound MTAs reduces  
the vetting of hundreds of millions of domains associated with Mail  
 From or PRAs, where each domain likely covers massive address lists.   
Legitimate Outbound MTA domains will resolve to a small set of  
addresses each.

Efforts to combine the addresses used by a domain is counter  
productive when it comes to resolving problems, or when dealing with  
initial SMTP connections.  When it comes to SMTP, direct relationships  
involve less overhead which improves efficacy and efficiency to the  
point of perhaps permitting use of IPv6.

-Doug

---

From: Ian Eiloart <[email-masked]>
Date: Thu, 02 Jul 2009 13:10:29 +0100

--On 1 July 2009 17:28:16 +0200 Alessandro Vesely <[email-masked]> wrote:

> Dotzero wrote:
>>> Thus, it turns out that if an MTA does mixed MSA and old fashioned port
>>> 25 relaying for its clients, its IP cannot convey accountability.
>>
> possible to claim damage, in case. It is like an insurance, and
> postmasters tend to stipulate it with IP numbers rather than DNS names.
> Why?

Because there is currently usually no alternative. You can only know the IP 
address of the sending MTA. It's hard to connect that to a person, or 
organisation, so the usual thing is to check against a reputation service.

With some reason to trust that the domain of the return-path, or in some 
message header, is not forged, you can go a lot further. You have the email 
address of the postmaster, and quite likely of the sender. If you don't 
have the email address of the sender, then that's an issue that needs 
sorting out within the domain.

"Accountability" can be applied in many ways, including:
1) assignment of reputation - in future DNSBLs will be supplemented or even 
replaced by domain reputation services.
2) freely bouncing undeliverable messages, like we used to do.
3) complaining to the sender, their company, or their postmaster.
4) legal santions, up to and including prison sentences.

> _______________________________________________
> Asrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/asrg

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/

---

From: Ian Eiloart <[email-masked]>
Date: Thu, 02 Jul 2009 13:14:11 +0100

> ultimately tied to an ISP (even if that carrier is an upstream).

That depends on what you're using it for. For hard-core spammers, it's easy 
to do get new domain names. And, they don't seem to have problems getting 
hold of IP addresses on compromised hosts, either.

It's harder to get hold of IP addresses or domains with good reputation.

For sloppy marketing people (who also send significant quantities of spam), 
it's not so easy to do either.

---

From: Ian Eiloart <[email-masked]>
Date: Thu, 02 Jul 2009 13:17:53 +0100

--On 1 July 2009 20:37:37 +0200 Alessandro Vesely <[email-masked]> wrote:

> addresses, therefore it would not be correct for them to share the same
> accountability token "ibm.com". I can only trust the DNS about the
> legitimacy of such subdomain delegations.

ibm.com isn't an email domain. At least, it's not one they use to send 
email. They do send email from @us.ibm.com addreses.

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 02 Jul 2009 17:03:50 +0200

Douglas Otis wrote:
> the MTA.

In general an MTA provides a FQDN like mta.example.com, and we are 
unable to say whether it "is a member of" example.com. In addition, 
the MTA's administrator may be unrelated to example.com's registrant.

>  When there are many domains, this appears to represent either 
> MTAs operating behind a NAT, or compromised systems; sometimes both.

I don't understand that kind of setup. Multiple MTAs operating behind 
a NAT have no way to receive mail, so they are only sending SMTP 
clients. Is inertia the only reason why they don't use an MSA?

> It appears to be rare for legitimate Outbound MTAs to change domain 
> affiliations.  From a reputation standpoint, verified EHLO information 
> offers stable identifiers in which to effectively and efficiently manage 
> email abuse.

It seems that vanity domains don't mind if the MX record points to an 
MTA in another domain. The intricacies of having CNAMEs near MX 
settings presumably refrained also from assigning multiple names, one 
for each vanity domain, to a given MTA. However, some do it.

On an SMTP connection, a client says: "Hello mta.example.com", and 
after I accept that, it goes on with "Mail from:<[email-masked]>". 
What does that mean, in terms of accountability?

>> To this end, I'd prefer the use of a domain name.

This guy is relaying on behalf of someone else. If I had verified the 
"example.com" possibly registered domain, I would spot it more easily. 
If example.ORG is a vanity name, i.e. it has the same MX as 
example.com, I accept it. If not, I wouldn't know who is accountable 
for the message, so I reject it.

In case mta.example.com runs outbound MTA services for third parties, 
I would hold the originating third party accountable for the message. 
However, there is no way I can tell that is indeed the case, neither 
from the IP address nor from the name. I'd need, say, a CSA SRV record 
from example.ORG saying: "we authorize mta.example.com", _and_ on 
starting a new session the client shall say: "Hello on behalf of 
example.ORG: check their CSA settings". No guessing required, then.

> represent a very small percentage of overall legitimate Outbound MTAs.

However, they transmit lots of messages.

> Being able to identify legitimate Outbound MTAs reduces the vetting of 
> hundreds of millions of domains associated with Mail From or PRAs, where 
> each domain likely covers massive address lists.

Exactly. Those legitimate Outbound MTAs are probably connected to an 
MSA. When we identify them, we enjoy the advantages deriving from 
users going through their relevant MSAs, as we recommended, rather 
than relaying through whatever MTA they have at hands, or directly.

> Efforts to combine the addresses used by a domain is counter productive 
> when it comes to resolving problems, or when dealing with initial SMTP 
> connections.  When it comes to SMTP, direct relationships involve less 
> overhead which improves efficacy and efficiency to the point of perhaps 
> permitting use of IPv6.

In some cases, names can be handled better than IP numbers. After all, 
that's why they invented the DNS...

---

From: Steve Atkins <[email-masked]>
Date: Thu, 2 Jul 2009 08:39:38 -0700

On Jul 2, 2009, at 5:14 AM, Ian Eiloart wrote:

> That depends on what you're using it for. For hard-core spammers,  
> it's easy to do get new domain names. And, they don't seem to have  
> problems getting hold of IP addresses on compromised hosts, either.
>

Didn't we already point out in this thread why this isn't a problem?

Cheers,
   Steve

---

From: Douglas Otis <[email-masked]>
Date: Thu, 2 Jul 2009 12:43:53 -0700

On Jul 2, 2009, at 8:03 AM, Alessandro Vesely wrote:

>>>> The CSV paradigm is that the operator of a MTA should exercise  
>>>> some responsibility for what is sends. The HELO string identifies  
>>>> the MTA (though not necessarily one string exclusively by one  
>>>> MTA), and the DNS management for that domain-name string states  
>>>> whether that domain exercises responsibility (and by automatic  
>>>> return of A)ddress RRs on SRV queries, what IP address(es) that  
>>>> MTA uses).
>>>
>> Disagree.  Based on our results, when only a few domains publish an  
>> IP addresses of an Outbound MTA, it is rather safe to assume the  
>> domains represented by verified EHLO information resolve who is  
>> administrating the MTA.
>

When the EHLO host name references IP addresses that match the  
Outbound MTA, this verifies there is a common administration between  
the FQDN and DNS.  CSV ensures this relationship can be established,  
and also asserts the system is an outbound MTA.

>> When there are many domains, this appears to represent either MTAs  
>> operating behind a NAT, or compromised systems; sometimes both.
>
> I don't understand that kind of setup. Multiple MTAs operating  
> behind a NAT have no way to receive mail, so they are only sending  
> SMTP clients. Is inertia the only reason why they don't use an MSA?

Unfortunately, Outbound MTAs behind NATs is more common that it should  
be, especially in Poland and Brazil.  Outbound MTAs can operate behind  
NATs.  Outbound MTAs can be unrelated to where their mail is  
received.  Even so, port 25 of the NAT can be nailed to a host within  
the NAT's private address space.  Outbound MTAs behind a NAT is fairly  
common in office environments.  The presence of multiple EHLO host  
names within the NATed office environment however appears to be most  
often due to compromised systems behind the same NAT.

>> affiliations.  From a reputation standpoint, verified EHLO  
>> efficiently manage email abuse.
>
> It seems that vanity domains don't mind if the MX record points to  
> an MTA in another domain. The intricacies of having CNAMEs near MX  
> settings presumably refrained also from assigning multiple names,  
> one for each vanity domain, to a given MTA. However, some do it.

Don't confuse Outbound MTAs with that of Inbound MTAs.  This has  
nothing to do with MX records.

> What does that mean, in terms of accountability?

With EHLO mta.example.com and a history of that host name being used  
by small range of IP addresses, and conversely, the IP address  
consistently reporting the same host name, then acceptance of messages  
from this Outbound MTA is likely safe.  When the mta.example.com also  
references a CSA record, there is even further assurance the exchange  
is not emitted by a compromised system, which currently represents the  
greatest source for spam.

 From a reputation perspective, the name and IP address relationships  
that need to be tracked for Outbound MTAs represent data sets orders  
of magnitude smaller and dramatically more stable that that  
represented by MAIL commands or PRAs.  Once EHLO relationship can be  
verified, it should permit safe inclusion of IPv6 addresses.  MAIL  
commands or PRAs do not offer the needed stability nor are these  
relationships readily verified without potentially burdensome overhead  
that might be directed to innocent third-parties.

> This guy is relaying on behalf of someone else. If I had verified  
> the "example.com" possibly registered domain, I would spot it more  
> easily. If example.ORG is a vanity name, i.e. it has the same MX as  

Do not confuse Inbound MTAs with Outbound MTAs.  Even without the host  
name having been verified, the host name and IP address information  
inconsistencies can lead to safe rejections.

> In case mta.example.com runs outbound MTA services for third  
> parties, I would hold the originating third party accountable for  
> the message.

Why not hold the entity offering access to those abusing email  
accountable?

You have no assurance whether third-party domains originated the  
message, even when the domain offers authorization.  This assumes  
Outbound MTAs ensure both the PRA and MAIL commands are restricted to  
specific and verified users.  While this might be the case, this is  
not the norm.  It would also be foolish to annotate email as having  
been "authenticated" on the basis of Outbound MTA authorization for  
the same reason.  Large companies place a higher priority on their  
messages being received than ensuring authorizations do not expose  
exploits to bad actors.  In addition, a growing number of exploits now  
leverage social networks that convey who recipients trust.  Spoofed  
sources of phish are not necessarily that of large banks or financial  
institutions.

> from the IP address nor from the name. I'd need, say, a CSA SRV  
> record from example.ORG saying: "we authorize mta.example.com",  
> _and_ on starting a new session the client shall say: "Hello on  
> behalf of example.ORG: check their CSA settings". No guessing  
> required, then.

Yes, the CSA record would help, but this EHLO information still offers  
value.  Especially when considering the use of IPv6 where block lists  
are unlikely to prove effective.

>> While larger ISPs are likely to have a few hundred outbound MTAs,  
>> they represent a very small percentage of overall legitimate  
>> Outbound MTAs.
>

It is still easier to correlate EHLO host names to that of a small set  
of IP addresses.  That is not the case for MAIL commands or PRAs.

>> Being able to identify legitimate Outbound MTAs reduces the vetting  
>> of hundreds of millions of domains associated with Mail From or  
>> PRAs, where each domain likely covers massive address lists.
>

The issue is not whether there is some mapping of users to specific  
MSAs.  In fact, it is not practical to track this type of many to many  
relationships.  The issue is simpler than that.  The issue is to  
simply hold the Outbound MTA accountable for the message sources for  
whom it grants access.  DKIM offers a reliable means to verify where a  
message originated without impractical and unscalable efforts aimed at  
registering all authorized paths for MAIL commands or PRAs.  DKIM is  
not about managing spam however.

>> productive when it comes to resolving problems, or when dealing  
>> with initial SMTP connections.  When it comes to SMTP, direct  
>> relationships involve less overhead which improves efficacy and  
>> efficiency to the point of perhaps permitting use of IPv6.
>
> In some cases, names can be handled better than IP numbers. After  
> all, that's why they invented the DNS...

While true for EHLO commands, IP addresses associated with MAIL  
commands or PRAs will normally exceed DNS response limits where  
truncation will induce failure.  The resulting chaining of DNS  
transactions, along with inclusion of macros found with SPF, failed to  
properly consider the potential system impact nor what DNSSEC could  
produce.  Verifying a DNS relationship between single hosts and their  
limited IP address list remains much less problematic and far safer.

DNS CIDR notation is specified by RFC 3123.  This resource record can  
still be used to establish email white-list strategies instead of SPF  
records.   APL records exclude potentially problematic macros as  
well.  Since email CIDR records should not be obtained in response to  
SMTP connections, APL might be chained with a convention for _n._smtp  
APL, as an alternative publishing location for _smtp APL.  When _smtp  
is truncated, either TCP fallback could be used, or _[0-9]._smtp APL  
queries might be used to recover from response truncation.

-Doug

---

From: Bill Cole <[email-masked]>
Date: Fri, 03 Jul 2009 00:33:56 -0400

Alessandro Vesely wrote, On 6/30/09 3:42 AM:
> Bill Cole wrote:
>> 1. There is no working global mechanism for identifying an accountable
>> party (i.e. one who explicitly *accepts* accountability) from an IP
>> address, due largely to the political and historical variations in how
>> IP addresses have been allocated.
>
> At a first glance, this may seem a flaw in the rDNS/whois systems. Upon
> reconsideration, I realize I have no means to accept accountability for
> an IP address of mines, since SPF or CSV/CSA only convey authorization
> for using a name. In facts, we don't even have a term for "the
> accountable party related to an IP address".

See RFC1183, which defines the "Responsible Party" RR type (RP). It states 
that a RP record can be associated with any node in the DNS hierarchy, and 
of course in-addr.arpa is part of the DNS hierarchy.

RP records are rarely published, and their operational use is even rarer. In 
my experience, RFC1183 is referenced most frequently as a caution against 
expecting too much from the RFC process.

> Dave's Email Arch mentions an Originator as "accountable for the message
> content", but doesn't relate it to an IP address. Rfc5068 associates
> accountability after submission with traceability features of the MSA,
> apparently suggesting that the first relaying thereafter is from an IP
> which is (indirectly) accountable for the message content. Reasoning by
> induction on the hops, one may conclude that all relays using a
> smarthost are accountable: smarthosts require either IP/firewall
> configuration or authentication (assuming they are not open relays.)
> Accountability breaks at the MX-driven relay, often referred as "boundary".

My reason for citing the IP address is that the IP address of the immediate 
client is the only fact that a host acting as an MX can trust to any useful 
degree for every message offered to it. Absent a means of reliably and 
quickly identifying a responsible party from *any* legitimate client IP, the 
suggestion that every MUA might be its own MSA is irrelevant.

>> Funneling email through MSA systems run by providers that in principle
>> have some means of holding their users accountable and are capable of
>> at least understanding bad behavior in mail if not always keeping it
>> controlled is the best partial workaround we have, and it implies the
>> need for domain-level accountability or its equivalent.
>
> Why is it partial?

Because all it does is narrow the population of legitimate MX clients to a 
set that are more likely to have some responsible party identifiable by some 
means. Yet at the same time, the responsible party for a outbound mail 
server handling mail from many ultimate originators may well simultaneously 
reject full responsibility for spam it transports and refuse to identify the 
ultimate originator. The best examples of this for me are the big freemail 
providers, all of whom seem to have shunned the entire notion of 
accountability.

> "Domain-level accountability" is a good approximation.

Only in a relative sense. In an absolute sense, it has proven rather poor.

All it takes for domain-level accountability to fail is a big enough domain.

 > However, a
> smarthost is not necessarily within the same domain (e.g. ukisp.com is
> not even in the same 1st level domain) or the same organization. How
> does accountability degrade through indirection? That is, would you
> trust an SMTP client the same if it relays on behalf of some other party?

Of course not.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 03 Jul 2009 13:48:23 +0200

Douglas Otis wrote:
> When the EHLO host name references IP addresses that match the Outbound 
> MTA, this verifies there is a common administration between the FQDN and 
> DNS.  CSV ensures this relationship can be established [...]

That is not the case. The hostmasters at example.com can unilaterally 
delegate mta.example.com the way they wish, with no obligation 
whatsoever to run a whois service or otherwise publish data about 
their delegate's admins, if any, let alone taking accountability for 
what such admins would do.

>   Outbound MTAs can be unrelated to where their mail is received.  
> Even so, port 25 of the NAT can be nailed to a host within the NAT's 
> private address space.  Outbound MTAs behind a NAT is fairly common in 
> office environments.

Yeah, I used to suggest that setting myself, since most of (legit) 
mail traffic is intra-office. They may collect external mail running 
cron-scheduled POP clients. However, with today's connections and 
legit mail being a tiny fraction of mail traffic, I see no reason for 
keeping those servers. I regard them as historical settings, and 
recommend using SUBMIT+IMAP on secured channels.

> With EHLO mta.example.com and a history of that host name [...]
> that need to be tracked for Outbound MTAs represent data sets orders of 
> magnitude smaller and dramatically more stable that that represented by 
> MAIL commands or PRAs.

However, one year after changing the IP address of my MTA, many MX 
receivers are not yet up to date. I'll have to manually update that, 
where possible, taking into account each domain idiosyncrasies. It is 
so because those name-address relationships are still too many. If you 
consider only the right hand side (RHS) of MAIL or PRAs, you'll get 
much smaller figures.

> Why not hold the entity offering access to those abusing email accountable?

If they just offer a transport service, I see no reason I should. 
Vice-versa, if they are accountable, then _they_ are the true MTA, 
transmitting on behalf of what I called a vanity domain. (This 
distinction does not have to be static, as example.ORG may send 
directly in some cases, via example.com in others.)

> specific and verified users.  While this might be the case, this is not 
> the norm.

OTOH, if we cannot spot whether an MSA has been used, the advantages 
of clean transmission remain confined within the first hop. An MTA who 
accepted to relay on behalf of an authenticated user may be willing to 
take accountability. The point is that it has no verb to express that 
will.

>  It would also be foolish to annotate email as having been 
> "authenticated" on the basis of Outbound MTA authorization for the same 
> reason.  Large companies place a higher priority on their messages being 
> received than ensuring authorizations do not expose exploits to bad 
> actors.

If they take accountability, then it's their problem. Their vouchers 
should take that behavior into account.

> are unlikely to prove effective.

I agree EHLO information has some value. In some cases, it may be 
redundant (e.g. if there is a vouch, or in case of ideal DNS 
settings.) In most cases, it is not enough, as it doesn't lead to an 
accountable administrator's name, address, phone number, etc.

>   The issue is simpler than that.  The issue is to simply 
> hold the Outbound MTA accountable for the message sources for whom it 
> grants access.  DKIM offers a reliable means to verify where a message 
> originated without impractical and unscalable efforts aimed at 
> registering all authorized paths for MAIL commands or PRAs.

Both Outbound MTAs and DKIM offer no hint about a message's Originator 
and related accountability issues.

For counting, note that the number of DKIM signers potentially exceeds 
the number of valid RHS domain names, since each mail domain can be a 
DKIM signer, but a DKIM signer doesn't have to be a mail domain.

> records.   APL records exclude potentially problematic macros as well.  
> Since email CIDR records should not be obtained in response to SMTP 
> connections, APL might be chained with a convention for _n._smtp APL, as 
> an alternative publishing location for _smtp APL.  When _smtp is 
> truncated, either TCP fallback could be used, or _[0-9]._smtp APL 

However well designed, such scheme will thickens the ranks of mail 
transmitter authentication schemes. All of them are optional, and 
checking which one may apply requires an increasing amount of DNS 
transactions, possibly amplified by DNSSEC. That's why VHLO, besides 
taking the mail domain of the accountable organization, can also take 
the parameters indicating which authentication method applies.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 3 Jul 2009 09:52:09 -0700

On Jul 3, 2009, at 4:48 AM, Alessandro Vesely wrote:

>>> unable to say whether it "is a member of" example.com. In  
>>> addition, the MTA's administrator may be unrelated to  
>>> example.com's registrant.
>>
>> Outbound MTA, this verifies there is a common administration  
>> between the FQDN and DNS.  CSV ensures this relationship can be  
>> established [...]
>
> That is not the case. The hostmasters at example.com can  
> unilaterally delegate mta.example.com the way they wish, with no  
> obligation whatsoever to run a whois service or otherwise publish  
> data about their delegate's admins, if any, let alone taking  
> accountability for what such admins would do.

The goal is to establish stable and fair identifiers.  Once a direct  
DNS relationship with that of a host can be verified, this serves as a  
identifier controlled by _some_ administrator.  Verification of a DNS  
relationship allows negative host stewardship assessments to be fairly  
made based upon the identifier.  A fair and stable identifier is being  
sought.  Not one that represents some person.  Anonymous tokens help  
avoid claims of individual censorship.  The application of host  
stewardship assessments can allow spam to be effectively and  
efficaciously managed, and is how accountability can be established.

>> Even so, port 25 of the NAT can be nailed to a host within the  
>> NAT's private address space.  Outbound MTAs behind a NAT is fairly  
>> common in office environments.
>
> legit mail being a tiny fraction of mail traffic, I see no reason  
> for keeping those servers. I regard them as historical settings, and  

Those with a DS3 serving their office network may expect they have an  
ability to publicly send email to other domains.

>> From a reputation perspective, the name and IP address  
>> relationships that need to be tracked for Outbound MTAs represent  
>> data sets orders of magnitude smaller and dramatically more stable  
>> that that represented by MAIL commands or PRAs.
>
> where possible, taking into account each domain idiosyncrasies. It  
> is so because those name-address relationships are still too many.  
> If you consider only the right hand side (RHS) of MAIL or PRAs,  
> you'll get much smaller figures.

Dependence upon just the domain of MAIL commands or PRAs would be  
vulnerable to exploitation.  Assertions that authorizations offer  
authentication are not safe.   In addition, there are hundreds of  
millions of MAIL command or PRA domains to be tracked, white there is  
about two to three orders of magnitude fewer EHLO domains.  A mistake  
made with a MAIL command or PRA domain will create serious and  
irreconcilable problems for the domain.  A mistake made with a EHLO  
host is both less likely, and will be far less catastrophic since  
services elsewhere can be sought.  In addition to being safer, more  
accurate, EHLO assessments are more efficacious and effective.  There  
are fewer in which to deal with, and this instills a hierarchy of  
management that better confronts rampant abuse largely caused by bot- 
nets.

> directly in some cases, via example.com in others.)

Those offering the service should still be assessed upon their  
stewardship of who is allowed to send messages.  When they fail to  
remove problematic access to their Outbound MTAs, those MTA might  
become blocked, and their customers will then need to seek service  
elsewhere.    When a MAIL command or PRA domains are blocked for  
because authorization has been confused with authentication or when  
spam is spoofing the domain, those affected are left without  
recourse.  Not wanting to track dramatically fewer EHLO host names  
with that of a small number of IP addresses is poor justification for  
a potentially injurious practice making guesses about MAIL commands or  
PRA domains. :^(

>> Outbound MTAs ensure both the PRA and MAIL commands are restricted  
>> to specific and verified users.  While this might be the case, this  
>> is not the norm.
>
> of clean transmission remain confined within the first hop. An MTA  
> who accepted to relay on behalf of an authenticated user may be  
> willing to take accountability. The point is that it has no verb to  
> express that will.

IMHO, systems used within private or authenticated exchanges is of no  
concern.  It is only the Outbound MTA sending messages to different  
domains on port 25 without authentication that needs management.   
Guesses about what might have occurred ahead of the Outbound MTA can  
be injurious to otherwise innocent domains.

>> "authenticated" on the basis of Outbound MTA authorization for the  
>> same reason.  Large companies place a higher priority on their  
>> exploits to bad actors.

Vouchers?  Taking accountability?  Logically extending that concept  
should then involve significant liabilities for providers that fail to  
ensure MAIL commands or PRAs are limited to their rightful owners.   
What RFCs should these providers be following?  How does one determine  
who is the rightful owner, and have you ever seen such agreements, and  
do you know which standards need to be followed?  Is this assurance  
expressed within your SLA with your provider?  Does this agreement  
specify exclusivity for use of MAIL commands or does it also include  
PRAs?  You are describing a fantasy that may cause injury when  
believed.  We need to hold parachute manufactures liable for their  
product, and not those using parachutes.

>>> However, there is no way I can tell that is indeed the case,  
>>> neither from the IP address nor from the name. I'd need, say, a  
>>> CSA SRV record from example.ORG saying: "we authorize  
>>> mta.example.com", _and_ on starting a new session the client shall  
>>> say: "Hello on behalf of example.ORG: check their CSA settings".  
>>> No guessing required, then.
>> Yes, the CSA record would help, but this EHLO information still  
>> offers value.  Especially when considering the use of IPv6 where  
>> block lists are unlikely to prove effective.
>

It only needs to lead to an identifier that can be fairly and safely  
blocked while mitigating email abuse.

>> The issue is simpler than that.  The issue is to simply hold the  
>> Outbound MTA accountable for the message sources for whom it grants  
>> access.  DKIM offers a reliable means to verify where a message  
> Both Outbound MTAs and DKIM offer no hint about a message's  
> Originator and related accountability issues.

The task of holding individuals accountable needs to be delegated to  
the Outbound MTA providers.  After all, these providers are being  
compensated, and not their recipients.  Expecting recipients to make  
guesses about who the originators were overlooks the reality that  
Outbound MTA provider granting access are the _only_ entities able to  
make this determination.  When they haven't or can't, they should be  
blocked when abuse is being emitted.

> For counting, note that the number of DKIM signers potentially  
> exceeds the number of valid RHS domain names, since each mail domain  
> can be a DKIM signer, but a DKIM signer doesn't have to be a mail  
> domain.

DKIM is to prevent spoofing.  DKIM is not intended to serve as a means  
to mitigate email abuse.

>> DNS CIDR notation is specified by RFC 3123.  This resource record  
>> can still be used to establish email white-list strategies instead  
>> of SPF records.   APL records exclude potentially problematic  
>> macros as well.  Since email CIDR records should not be obtained in  
>> response to SMTP connections, APL might be chained with a  
>> convention for _n._smtp APL, as an alternative publishing location  
>> for _smtp APL.  When _smtp is truncated, either TCP fallback could  
>> be used, or _[0-9]._smtp APL queries might be used to recover from  
>> response truncation.
>
> taking the mail domain of the accountable organization, can also  
> take the parameters indicating which authentication method applies.

This alternative for white-listing was mentioned only to suggest safer  
methods that don't rely upon potentially hazardous scripts.

-Doug

---

From: Peter Koch <[email-masked]>
Date: Sun, 5 Jul 2009 15:56:40 +0200

Doug,

On Thu, Jul 02, 2009 at 12:43:53PM -0700, Douglas Otis wrote:

> the FQDN and DNS.

the DNS namespace is of very little help when it comes to conclusions about
"common administration".  See, for example, RFC 5507, section 4:

   DNS hierarchy neither follows nor implies administrative hierarchy.
   Because of that, it cannot be assumed that data attached to a node in
   the DNS tree is valid for the whole subtree. [...]

Since I'm sure you were already aware of this, I'm wondering in what way
I might have misread your statement.

-Peter

---

From: Douglas Otis <[email-masked]>
Date: Mon, 6 Jul 2009 12:00:24 -0700

On Jul 5, 2009, at 6:56 AM, Peter Koch wrote:

>> between the FQDN and DNS.
>
> the DNS namespace is of very little help when it comes to  
> conclusions about "common administration".  See, for example, RFC  
> 5507, section 4:
>
>  DNS hierarchy neither follows nor implies administrative  
> hierarchy.   Because of that, it cannot be assumed that data  
> attached to a node in   the DNS tree is valid for the whole subtree.  
> [...]
>
> Since I'm sure you were already aware of this, I'm wondering in what  
> way I might have misread your statement.

It would appear so.

Confirming a host name matches its published IP addresses does not  
extend either up or down the administrative name tree hierarchy.

Address records would be at a specific host name where a relationship  
with the host name and published address records is being confirmed.

The CVS/CSA records authorize _specific_ outbound SMTP servers by its  
EHLO host name and IP address .  (As a transition scheme, a parent  
domains might assert child domain use of CSA records.   Even so, CSA  
records are required for each specific host name.)

This is not whether the host name of "email.sfo.example.com" is within  
the same administrative control as that of "[email-masked]" email  
address.   Accountability is assigned to a specific outbound MTA host  
regardless of the MAIL and PRA domains issued.  Just as it would be  
wrong, based upon name alone, to extend administrative domain  
hierarchy, Outbound MTA authorization referenced from email-address  
domains will not confirm the originating domain.   As such, it would  
be wrong to assert origination or administrative accountably against  
higher level domains _or_ authorizing domains for abuse that might not  
have be within their administrative control.  Fairness and equity for  
administrative stewardship needs to be retained.  CSV/CSA retrains  
fairness when assessing administrative stewardship.

Assigning accountability based upon Outbound MTA domain SPF  
authorization referenced from either the MAIL command or the Purported  
Responsible Address (PRA) assumes the Outbound MTA has administrative  
control or that there are mechanisms in place protecting those  
offering the authorization.  There are no current standards nor common  
SLAs that protect those offering the authorization to their email  
service providers.

Basing acceptance upon Outbound MTA SPF authorization (referenced from  
MAIL commands or PRA domains) will force domains to accept  
accountability for actions likely beyond their administrative  
control.  Holding these domains accountable by way of SPF reputation  
assessments in many cases will be unfair and provide inequitable  
treatment.  Fairness requires those within administrative control are  
held accountable.

-Doug

---

From: David Nicol <[email-masked]>
Date: Mon, 6 Jul 2009 17:41:53 -0500

On Wed, Jul 1, 2009 at 9:20 AM, Alessandro Vesely<[email-masked]> wrote:

> much like pinching hackers on the fly is sometimes shown on the movies

What, and then grab their nuts and squeeze?

-- 
Gaming Edison's ratio by shunning air conditioning doesn't actually work.