Subject: [Asrg] SPF's helo identity as a reporting target

From: Alessandro Vesely <[email-masked]>
Date: Sat, 12 May 2012 09:59:55 +0200

This probably belongs to ASRG, not only because MARF has finished, but
also because a *Taxonomy of reporting targets* should be hosted
somewhere, and I'm unable to think of a better place than this list's
wiki.

Opinions?

-------- Original Message --------
From: [email-masked]
Date: Tue, 08 May 2012 12:56:10 +0200
To: [email-masked]
Subject: SPF's helo identity as a reporting target

Hi all,

someone on the spf-discuss list noted that the smtp.helo is often of a
different type than the domains usually branded in smtp.mailfrom,
header.from, and dkim.d.  That's because it seems to be quite common
to outsource mail relaying as well as MX services.  This situation
characterizes relaying services as third parties that might manage
complaints and/or enforce policies, much like ESPs and ISPs.

MARF-AS generically allows any "domain that has been verified by the
[relevant] authentication mechanism", as well as "Abuse addresses in
WHOIS records of the IP address".

Would it be feasible to correlate auth methods' properties to roles,
in general?  For example, ESPs normally wouldn't outsource mail
relaying, since it's their core business.  Thus, sending a complaint
to [email-masked] could be a way to target any involved ESP.

Just mumbling...

---

From: Chris Lewis <[email-masked]>
Date: Sat, 12 May 2012 13:46:55 -0400

> somewhere, and I'm unable to think of a better place than this list's

It would be nice if it could be made usable.

This would tend to make a large organization having all of their servers
helo exactly the same way, which flies in the face of industry BCP (eg:
MAAWG), and even if it wasn't specifically RFC5321-illegal, clearly
violates its intent.

Or they use wildcarded MXes.  Ick.  Makes "divisional" abuse addresses
very difficult.

Or use the registration level domain (lop off the non-registration level
FQDN qualifiers) - makes "divisional" abuse addresses impossible, and
the registration level domain chop is real hard to do with some tlds.

The absolute death of this proposal is, tho, that it puts the abuse
reporting address under the control of the spammer and becomes a DDOS
weapon.

I could just see it - it gets implemented for tana.it, and the next
day's blast of 10 billion cutwail botnet spams uses "HELO tana.it".

Kaboom!!!

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 13 May 2012 11:58:40 +0200

> MAAWG), and even if it wasn't specifically RFC5321-illegal, clearly

I see nothing wrong if an organization uses the same helo name for all
its mailouts.  A helo name does not have to be a label of any DNS
record.  However, in case it has an SPF record it could be validated.

> day's blast of 10 billion cutwail botnet spams uses "HELO tana.it".

No, wait.  Didn't I say it has to get an SPF "pass" to get usable?
I must have considered it implied... my bad.

An idea is that if you offer virtual MTA services, you may want to get
complaints.  Unless you hijack each customer's abuse@, using helo
names might be more practical than relying on RIR's whois, depending
on your network providers.  But did anyone try that?  And if anyone
did, where do they publish their experiences?  Where do postmasters
learn to target complaints effectively?

---

From: Chris Lewis <[email-masked]>
Date: Sun, 13 May 2012 11:29:19 -0400

On 12-05-13 05:58 AM, Alessandro Vesely wrote:
> record. 

Uh what?

RFC5321:

Section 4.1.1.1:

   These commands are used to identify the SMTP client to the SMTP
   server.  The argument clause contains the fully-qualified domain name
   of the SMTP client, if one is available.  In situations in which the
   SMTP client system does not have a meaningful domain name (e.g., when
   its address is dynamically allocated and no reverse mapping record is
   available), the client SHOULD send an address literal (see
   Section 4.1.3).

   ...

   The SMTP server identifies itself to the SMTP client in the
   connection greeting reply and in the response to this command.

Yeah, I suppose you could make all your outbounds have the same name (up
to whatever limit DNS imposes), but clearly this violates the intent.

And it's also very explicitly counter to industry practises/BCP.

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 13 May 2012 19:21:44 +0200

On Sun 13/May/2012 18:59:23 +0200 Chris Lewis wrote:
>    of the SMTP client, if one is available.

This has been discussed so many times that we don't need to do it once
more.  For one (John Klensin on Jan 2009):

  The 1123-imposed requirement (carried forward into Section 4.1.4
  Paragraph 6 of 5321) that messages not be rejected on the basis
  of a validation failure with the EHLO argument would presumably
  remain even if we deprecated 821 and client use of HELO.
  http://www.imc.org/ietf-smtp/mail-archive/msg05420.html

> And it's also very explicitly counter to industry practises/BCP.

I'd agree that violating intents and/or practices is not a good start.
That seems to imply that it is necessary to use scripts to keep helo
names, IP addresses, and SPF in sync.  Would that be worth?

---

From: Chris Lewis <[email-masked]>
Date: Sun, 13 May 2012 14:03:31 -0400

>   http://www.imc.org/ietf-smtp/mail-archive/msg05420.html

On the one hand, we have Klensin commenting on rejecting email based
upon helo validation (despite which, helo factors very heavily into
filtering anyway), versus _explicitly_ violating the RFC in a proposed
standard.

Klensin's argument doesn't apply to this proposal.  At all.

> names, IP addresses, and SPF in sync.  Would that be worth?

The reality is going to be is that since it relies on SPF to be valid,
few people would bother implementing it on the sending side, and there
will be more than enough people ignoring the requirement to SPF verify
before trusting it, that kabooms! will still happen.

There are other ways of doing this that doesn't require ancilliary gunk
like SPF. There's at least one IP-based DNSBL that yields the same data.

---

From: Chris Lewis <[email-masked]>
Date: Sun, 13 May 2012 14:30:14 -0400

> I must have considered it implied... my bad.

It doesn't help.

spammerdomain.com IN MX 0  wmail.tana.it.
spammerdomain.com IN TXT "v=spf1 ip4:0/0 -all"

[May not be exact, but you get the idea.]

10 billion cutwail spams heloing as spammerdomain.com later...

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 13 May 2012 20:40:32 +0200

> before trusting it, that kabooms! will still happen.

So it would be an error-prone technique?  We are talking about
/postmasters/ extracting target addresses for abuse reporting, not end
users.  Shouldn't that imply some knowledge?

SPF records are going to sport a new ra= modifier, specifying an
address for reporting authentication failures, not abuse.  That may
bring further confusion, in fact.

> There are other ways of doing this that doesn't require ancillary gunk

Which one do you mean?  DNS lists like abusix get their data from
RIRs' whois databases.  In that case, virtual MTA providers would have
to restrict their choice of network providers based on proper
management of whois records, besides cost, bandwidth, uptime, support, ...

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 13 May 2012 20:49:08 +0200

> spammerdomain.com IN TXT "v=spf1 ip4:0/0 -all"

That's not quite how helo authentication works.  When they say "helo
wmail.tana.it" the server looks up wmail.tana.it.

wmail.tana.it.  IN TXT  "v=spf1 redirect=tana.it"
tana.it.        IN TXT  "v=spf1 +ip4:62.94.243.226 -all"

They won't get a "pass" unless they are using that ip4.

---

From: Chris Lewis <[email-masked]>
Date: Sun, 13 May 2012 15:55:08 -0400

> users.  Shouldn't that imply some knowledge?

It should.  But it doesn't.

> bring further confusion, in fact.

Right.

As one said "the best thing about standards is that there's so many to
choose from" ;-)

> RIRs' whois databases.

That's an implementation detail.  There's no reason that they'd _have_
to.  Mine doesn't rely on whois for responsible domain or abuse contact.
 While it does the published RIR maps for allocations and countries, it
does no whois queries.

abuse.net's doesn't use whois for anything.  I don't think Cymru's or
Mynetwatchman's does.

It's _very_ hard to get domains from whois in an even remotely "global
sense", let alone abuse addresses.

> In that case, virtual MTA providers would have

"Proper management" of IP whois records is probably coming as unlikely
as it seems, so another reason for it wouldn't hurt.

---

From: Chris Lewis <[email-masked]>
Date: Sun, 13 May 2012 15:56:49 -0400

>> spammerdomain.com IN TXT "v=spf1 ip4:0/0 -all"

Whoops, I meant:

_smtp.spammerdomain.com IN MX 0 wmail.tana.it

> wmail.tana.it" the server looks up wmail.tana.it.

No.  The spammer says "helo spammerdomain.com".  Postmaster sends
complaint to [email-masked].

Where does that go?

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 14 May 2012 11:26:05 +0200

On Mon 14/May/2012 10:34:06 +0200 Chris Lewis wrote:
> The spammer says "helo spammerdomain.com".

More or less.

> Postmaster sends complaint to [email-masked].
> 
> Where does that go?

That's plain abuse, though.  There must be loads of national laws that
the owner of that zone openly breaks.  Isn't that too much risky from
a legal POV, considering its effectiveness is probably less than other
kinds of DDoS?

   220 wmail.tana.it ESMTP
   HELO goofy.example
   250 wmail.tana.it Ok.
   MAIL FROM:<>
   250 Ok.
   RCPT TO:<[email-masked]>
   513 Relaying denied.
   QUIT
   221 Bye.

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 14 May 2012 11:27:54 +0200

> While it does the published RIR maps for allocations and countries, it

And how does it discover abuse contacts?

> abuse.net's doesn't use whois for anything.

Yes, but it's not IP-based.  It falls back to RFC 2142 role addresses,
and relies on cooperative contributions (I think).

> I don't think Cymru's or Mynetwatchman's does.

Thanks for the pointers, I'll take a look at them.

> as it seems, so another reason for it wouldn't hurt.

That would be a Good Thing.  However, it may appear a double-edged
sword, as it hides the network provider's abuse team.  One could
navigate whois records hierarchically, so if the virtual MTA operator
is a bad guy, the abuse contact at the upper level should be its
network provider.  This operation can be done recursively, but
homogeneity may obscure awareness.  That is, by climbing the tree all
the way up, one eventually gets at IANA's --which hopefully will never
be a bad guy-- but might not realize what role corresponds to each level.

---

From: Chris Lewis <[email-masked]>
Date: Mon, 14 May 2012 10:04:23 -0400

> a legal POV, considering its effectiveness is probably less than other

Who said anything about a deliberate DDOS?  Think of it as spam with
electronic countermeasures designed to confuse, confound and distract
the recipients and third parties.

Just like they already do.

"national laws ... openly breaks".  You can say that with a straight
face considering that 80-90% of all spam already does?

>    RCPT TO:<[email-masked]>

Big enough, the recipient site still loses before the 220.

Eg: think back to when AOL bounced instead of rejected for no-such-user.

---

From: Rich Kulawiec <[email-masked]>
Date: Mon, 14 May 2012 10:22:39 -0400

> Section 4.1.1.1:

+1, and let me add:

One of the many reasons to make the HELO consistent with the FQDN is that
it can be helpful in debugging.

---rsk

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 14 May 2012 16:34:43 +0200

On Mon 14/May/2012 16:19:57 +0200 Chris Lewis wrote:
>> There must be loads of national laws that the owner of that zone
>> openly breaks.  Isn't that too much risky from a legal POV,
>> considering its effectiveness is probably less than other kinds
>> of DDoS?
> 

Whatever the intent, I should get your permission before asserting
that your server serves me.  Shouldn't I?  Then, yes, I suppose some
judges still have difficulties understanding Internet protocols.

> face considering that 80-90% of all spam already does?

I don't have specific experience, but it seems to me that when
spammers leave enough evidence behind them they can be taken to court.

> Big enough, the recipient site still loses before the 220.

You're right.  Rejecting is cheap, but still bears a cost.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 14 May 2012 10:41:12 -0700

On 5/14/12 7:34 AM, Alessandro Vesely wrote:
> > Who said anything about a deliberate DDOS? Think of it as spam
> > with electronic countermeasures designed to confuse, confound and
> > distract the recipients and third parties.
>
> > "national laws ... openly breaks". You can say that with a
> > straight face considering that 80-90% of all spam already does?
>

Dear Alessandro and Chris,

Since RFC821, HELO/EHLO was defined as FQDN SMTP hostnames.  There is no 
reason additional policy assertions such as those proposed for DMARC 
could not include authenticated email EHLO/HELO acceptance with a 
hostname from their domain, whether by a forward reference to an address 
list, or an SPF resource record.  The domain validated would be 
determined by the domain of the SPF record and not by an SPF mechanism 
as Chris suggested.  The goal of DMARC is to offer a safe method to 
reject messages in a way not likely to create support calls for 
receivers.  A policy that can be extended to individual SMTP servers 
controlled by domains making compliance assertions should offer safe 
rejections having lower cost than message filtering or rejections based 
on the SMTP mail parameter.  The mistake made by DMARC was not 
considering HELO/ELHO alignment against the parent domain rather than 
the hostname.

Regards,
Douglas Otis.