headers
Alessandro Vesely | 12 May 2012 09:59
Picon
Favicon

SPF's helo identity as a reporting target

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: vesely <at> tana.it
Date: Tue, 08 May 2012 12:56:10 +0200
To: marf <at> ietf.org
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 abuse <at> _smtp.helo_ could be a way to target any involved ESP.
(Continue reading)

Permalink | Reply | 16 comments |
headers
Chris Lewis | 12 May 2012 19:46
Picon

Re: SPF's helo identity as a reporting target

On 12-05-12 03:59 AM, Alessandro Vesely wrote:
> 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!!!
(Continue reading)

Permalink | Reply | 15 comments |
headers
Alessandro Vesely | 13 May 2012 11:58
Picon
Favicon

Re: SPF's helo identity as a reporting target

On Sun 13/May/2012 11:07:45 +0200 Chris Lewis wrote:
> On 12-05-12 03:59 AM, Alessandro Vesely wrote:
>> 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.

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.

> 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?
(Continue reading)

Permalink | Reply | 14 comments |
headers
Chris Lewis | 13 May 2012 17:29
Picon

Re: SPF's helo identity as a reporting target

On 12-05-13 05:58 AM, Alessandro Vesely wrote:
> On Sun 13/May/2012 11:07:45 +0200 Chris Lewis wrote:
>> On 12-05-12 03:59 AM, Alessandro Vesely wrote:
>>> 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.
> 
> 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
(Continue reading)

Permalink | Reply | 6 comments |
headers
Alessandro Vesely | 13 May 2012 19:21
Picon
Favicon

Re: SPF's helo identity as a reporting target

On Sun 13/May/2012 18:59:23 +0200 Chris Lewis wrote:
> On 12-05-13 05:58 AM, Alessandro Vesely wrote:
>> On Sun 13/May/2012 11:07:45 +0200 Chris Lewis wrote:
>>>
>>> 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.
>> 
>> 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.

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
(Continue reading)

Permalink | Reply | 4 comments |
headers
Chris Lewis | 13 May 2012 20:03
Picon

Re: SPF's helo identity as a reporting target

On 12-05-13 01:21 PM, Alessandro Vesely wrote:
> On Sun 13/May/2012 18:59:23 +0200 Chris Lewis wrote:
>> On 12-05-13 05:58 AM, Alessandro Vesely wrote:
>>> On Sun 13/May/2012 11:07:45 +0200 Chris Lewis wrote:
>>>>
>>>> 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.
>>>
>>> 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.
> 
> 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
(Continue reading)

Permalink | Reply | 3 comments |
headers
Chris Lewis | 13 May 2012 20:30
Picon

Re: SPF's helo identity as a reporting target

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

> 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...
Permalink | Reply | 6 comments |
headers
Alessandro Vesely | 13 May 2012 20:40
Picon
Favicon

Re: SPF's helo identity as a reporting target

On Sun 13/May/2012 20:13:44 +0200 Chris Lewis wrote:
> On 12-05-13 01:21 PM, Alessandro Vesely wrote:
>> 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.

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
> 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, ...
Permalink | Reply | 2 comments |
headers
Alessandro Vesely | 13 May 2012 20:49
Picon
Favicon

Re: SPF's helo identity as a reporting target

On Sun 13/May/2012 20:44:58 +0200 Chris Lewis wrote:

> On 12-05-13 05:58 AM, Alessandro Vesely wrote:
> 
>> 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.
Permalink | Reply | 5 comments |
headers
Chris Lewis | 13 May 2012 21:55
Picon

Re: SPF's helo identity as a reporting target

On 12-05-13 02:40 PM, Alessandro Vesely wrote:
> On Sun 13/May/2012 20:13:44 +0200 Chris Lewis wrote:
>> On 12-05-13 01:21 PM, Alessandro Vesely wrote:
>>> 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.
> 
> 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.

> 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" ;-)

>> 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
(Continue reading)

Permalink | Reply | 1 comment |

Gmane