SPF's helo identity as a reporting target

Post by Alessandro Vesely
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?

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

Alessandro Vesely

2012-05-13 09:58:40 UTC

It would be nice if it could be made usable.
This would tend to make a large organization having all of their servers
MAAWG), and even if it wasn't specifically RFC5321-illegal, clearly
violates its intent.

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.

Post by Chris Lewis
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!!!

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?

Chris Lewis

2012-05-13 15:29:19 UTC

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.

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.

Alessandro Vesely

2012-05-13 17:21:44 UTC

Post by Chris Lewis
It would be nice if it could be made usable.
This would tend to make a large organization having all of their servers
MAAWG), and even if it wasn't specifically RFC5321-illegal, clearly
violates its intent.

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.

Uh what?
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.

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

Post by Chris Lewis
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.

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?

Chris Lewis

2012-05-13 18:03:31 UTC

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.

Uh what?
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.

This has been discussed so many times that we don't need to do it once
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

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.

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?

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.

Alessandro Vesely

2012-05-13 18:40:32 UTC

Post by Alessandro Vesely
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?

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.

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

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

Chris Lewis

2012-05-13 19:55:08 UTC

Post by Alessandro Vesely
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?

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?

It should. But it doesn't.

Post by Alessandro Vesely
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.

Right.

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

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

Which one do you mean? DNS lists like abusix get their data 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.

Post by Alessandro Vesely
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, ...

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

Alessandro Vesely

2012-05-14 09:27:54 UTC

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

Which one do you mean? DNS lists like abusix get their data from
RIRs' whois databases.

And how does it discover abuse contacts?

Post by Chris Lewis
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).

Post by Chris Lewis
I don't think Cymru's or Mynetwatchman's does.

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

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

"Proper management" of IP whois records is probably coming as unlikely
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.

Rich Kulawiec

2012-05-14 14:22:39 UTC

+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

Chris Lewis

2012-05-13 18:30:14 UTC

Post by Alessandro Vesely
No, wait. Didn't I say it has to get an SPF "pass" to get usable?
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...

Alessandro Vesely

2012-05-13 18:49:08 UTC

Post by Alessandro Vesely
No, wait. Didn't I say it has to get an SPF "pass" to get usable?
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"

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.

Chris Lewis

2012-05-13 19:56:49 UTC

Post by Alessandro Vesely
No, wait. Didn't I say it has to get an SPF "pass" to get usable?
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"

Whoops, I meant:

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

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

No. The spammer says "helo spammerdomain.com". Postmaster sends
complaint to ***@_smtp.spammerdomain.com.

Where does that go?

Alessandro Vesely

2012-05-14 09:26:05 UTC

Post by Chris Lewis
_smtp.spammerdomain.com IN MX 0 wmail.tana.it
The spammer says "helo spammerdomain.com".

More or less.

Post by Chris Lewis
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:<***@spammerdomain.com>
513 Relaying denied.
QUIT
221 Bye.

Chris Lewis

2012-05-14 14:04:23 UTC

Post by Chris Lewis
Where does that go?

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?

Post by Alessandro Vesely
220 wmail.tana.it ESMTP
HELO goofy.example
250 wmail.tana.it Ok.
MAIL FROM:<>
250 Ok.
513 Relaying denied.
QUIT
221 Bye.

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

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

Alessandro Vesely

2012-05-14 14:34:43 UTC

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?

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.

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.

Post by Chris Lewis
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?

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.

220 wmail.tana.it ESMTP

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

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

Douglas Otis

2012-05-14 17:41:12 UTC