Subject: Re: [Asrg] Adding a spam button to MUAs

From: Ian Eiloart <[email-masked]>
Date: Mon, 01 Feb 2010 10:57:22 +0000

--On 29 January 2010 19:45:29 +0100 Alessandro Vesely <[email-masked]> 
wrote:

>
> IMHO it is more important to focus on _how_ and _where_, the answers
> being, respectively, ARF and abuse@<authserv-id>, where the latter is
> defined in http://tools.ietf.org/html/rfc5451#section-2.3 Note that users
> have to configure their clients specifying which authserv-id they trust
> for each account. This stone can kill both birds.

Except that that isn't, I presume, the way these buttons currently work - 
except when somebody is subscribed to a feedback loop. It seems 
over-complicated and inefficient (even with BURL) to send an ARF to your 
own system admin, and rather more simple to just set a flag or annotation 
on the IMAP server.

Apart from that, a standard way of telling the server side spam filter that 
it's made a mistake would be useful.

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

---

From: John Levine <[email-masked]>
Date: 1 Feb 2010 14:59:03 -0000

>Except that that isn't, I presume, the way these buttons currently
>work - except when somebody is subscribed to a feedback loop. It
>seems over-complicated and inefficient (even with BURL) to send an
>ARF to your own system admin, and rather more simple to just set a
>flag or annotation on the IMAP server.

You're right, for the minority of us who run IMAP.  For everyone else
who uses POP, mailing an ARF report back to the POP server may be the
best we can do.  The authserv-id from RFC 5451 isn't ideal to use as
the mailing address since the RFC says quite clearly that it has to
look like a FQDN but it doesn't actually have to be an FQDN.

If we go down this route, we could probably add a flag to 5451 to
say it's OK to send ARF reports.

R's,
John

---

From: Steve Atkins <[email-masked]>
Date: Mon, 1 Feb 2010 08:00:53 -0800

> say it's OK to send ARF reports.

... or put it in the the message, where there's one standard format
to deal with, rather than tying it to just one of the various ways people 
retrieve messages. Most everyone already stashes an assortment
of metadata in the headers anyway.

Cheers,
  Steve

---

From: "Chris Lewis" <[email-masked]>
Date: Mon, 1 Feb 2010 11:20:45 -0500

> of metadata in the headers anyway.

Which gives you the opportunity to do more complicated things, like if 
the IMAP/POP servers aren't the place to send the notification.  In our 
case, they're not.

A X- header that has machine-readable instructions on what the reader 
should do if you hit the TiS button.

I'd envisage emailing ARF or plain forwards or site-chosen identifiers 
to a specified place.  Plus something non-SMTP.

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 01 Feb 2010 16:57:49 +0000

--On 1 February 2010 14:59:03 +0000 John Levine <[email-masked]> wrote:

> best we can do.

So, are we looking at an IMAP/ANNOTATE extension for IMAP users and an 
RFC5451 modification for SMTP users? The IMAP/ANNOTATE is much more 
efficient than sending an abuse report, and less susceptible to outside 
interference.

Does ARF allow richer expression than ANNOTATE?

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 01 Feb 2010 18:09:10 +0100

>>>> flag or annotation on the IMAP server.

However, it's not trivial to timely interpret changes in the IMAP folders.

>>> say it's OK to send ARF reports.

I'd guess that hosts who don't support getting abuse reports can 
choose an authserv-id which is not a mail domain. At any rate, they 
will have to instruct their users on how to enable processing of that 
header field.

>> to deal with, rather than tying it to just one of the various ways
>> people retrieve messages. Most everyone already stashes an assortment

Uh? The authserv-id from RFC 5451 is right there already...

> the IMAP/POP servers aren't the place to send the notification. In our

If using ARF, more complicated behavior might be noted in specific 
fields. In several cases --e.g. unsubscribe, FBL-- some kind of 
forwarding is required anyway. Changes will be easier to manage if the 
software is centralized at a few abuse@ handlers, than if complicated 
behavior is carried out by each client.

> should do if you hit the TiS button.

A savvy client should seek user's consent anyway.

> to a specified place. Plus something non-SMTP.

Sticking to ARF seems smoother, from the server handler POV.

---

From: Steve Atkins <[email-masked]>
Date: Mon, 1 Feb 2010 09:11:15 -0800

On Feb 1, 2010, at 8:57 AM, Ian Eiloart wrote:

> So, are we looking at an IMAP/ANNOTATE extension for IMAP users and an RFC5451 modification for SMTP users? The IMAP/ANNOTATE is much more efficient than sending an abuse report, and less susceptible to outside interference.
> 

Probably - it's basically a container format.

More importantly, perhaps, it would be easy to roll out on existing installations with a trivial configuration change, rather than requiring functionality in the mailstore that may not be there.

It also doesn't require anything more of the MUA other than the ability to construct and send a basic MIME email, and works identically for mail retrieved via IMAP, POP, SQL, HTTP, mbox, maildir or any of the other obscure ways people access their mail stores.

As for efficiency, I was picturing two variants of the header - one which sends a copy of the entire email, and so doesn't require any shared state between client and mailstore, and one which sends back just the contents of the header (which could include a message-id, an IMAP UID or some system specific primary key).

Cheers,
  Steve

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 01 Feb 2010 17:13:33 +0000

--On 1 February 2010 16:57:49 +0000 Ian Eiloart <[email-masked]> wrote:

> RFC5451 modification for SMTP users?

Er, I mean "POP3 users"

> The IMAP/ANNOTATE is much more

---

From: Bart Schaefer <[email-masked]>
Date: Mon, 01 Feb 2010 09:23:25 -0800

On Feb 1,  9:11am, Steve Atkins wrote:
}
} On Feb 1, 2010, at 8:57 AM, Ian Eiloart wrote:
} 
} > Does ARF allow richer expression than ANNOTATE?
} 
} Probably - it's basically a container format.
} 
} More importantly, perhaps, it would be easy to roll out on existing
} installations with a trivial configuration change, rather than
} requiring functionality in the mailstore that may not be there.

Anything that's going to be added as metadata to the message header
needs to be carefully specified so that a client that understands the
format can reside behind a server that does not.  E.g., depending on
where this metadata is added, one option might be to require a DKIM
signature to cover it.

Precisely because this would be rolled out on existing installations,
it's not sufficient to treat it like a Return-Path field and expect
the final delivery server to clean up any values that were improperly
inserted earlier in transit.

--

---

From: "Chris Lewis" <[email-masked]>
Date: Mon, 1 Feb 2010 23:44:50 -0500

> where this metadata is added, one option might be to require a DKIM

Consider the following off-the-cuff implementation possibility:

A header that has:

Name of server (or administrative unit (domain)) inserting the header.
What to send in report:
	ARF copy, or forward or selected header[s] or?
How to send report:
         email (including address), or some other protocol and
         destination.

Are we asking that these could be inserted at source (eg: on AOL 
outbounds)?  Or, receiving-end implementation?  Or both?

If receiver only, the receiver simply discards any previous ones and 
inserts their own.

As long as the client "knows" whether its front ends support this 
functionality (might be config value of administrative domain), and 
ignores them if it isn't, the security issues are fairly limited.

Still need DKIM?

If the sender is "permitted" to insert them, for them to mean much, you 
get into the same issues as end-to-end DKIM on email has.  You know that 
the signature verifies or not, but you still don't know whether you want 
to trust the information.

I think of this as more of a "receiver sets policy".  If we allow 
senders to insert them, we have to have a way for the receiver to assert 
overriding policy.  Eg: "everything but stuff I can tell is from AOL 
comes to me, and the AOL stuff can be sent as they request").  Either by 
inspecting and possibly altering/replacing the header in flight, or 
being able to get instructions on what to respect to the clients.  The 
latter might get rather nasty.

In any event, such things have to be thought out well in advance so that 
the clients do have a solid spec to work against, and the receivers know 
what they have to do too.

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 02 Feb 2010 12:57:46 +0100

> ignores them if it isn't, the security issues are fairly limited.

An ARF received at a domain's "abuse@" mailbox may arrive from an 
authenticated client, and it won't be DKIM-signed in that case. 
However, the abusive message being reported may have signatures.

Or it may arrive from a third party. A third party presumably rewrites 
both the boilerplate and the machine-readable parts, and I would 
expect it DKIM-signs them. An MTA should only receive reports where 
the Reported-Domain field indicates its own domain. Generic operators 
may also receive reports that they are supposed to "forward" 
--possibly rewriting and signing the first two parts in turn.

> to trust the information.

Perhaps an MTA should verify on its own that an AR is correct. For 
authenticated clients, it may check its receive log. For reports 
routed by third parties, it may also verify its own signatures.

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 2 Feb 2010 13:01:42 -0500

> --possibly rewriting and signing the first two parts in turn.

I was referring on the _client_ trusting the header its front end would 
have inserted to indicate where/how to send a report.  If we only add 
these headers at the receiving end, the receiving end zaps all prior 
instances of the TiS header and inserts its own, and the client knows 
that the receiving end inserts this header, then there's only the issue 
of the client roaming somewhere else and getting a forward.

Your above appears to be on the abuse@ mailbox (or whatever) deciding to 
trust the report it got from the client.  That's a different affair.

> routed by third parties, it may also verify its own signatures.

That might be an option, but that ties the abuse@ rather more intimately 
and automatically to the MTAs (and their logs etc) than you'd like.

I wouldn't necessarily want the MTA to handle abuse@ reports.  Eg: you 
have multiple MTAs.  You want a central report point, and let _it_ know 
how to propagate the choices it's going to make, and don't insist that 
it necessarily has logs (or logs timely enough) to do real-time 
verifies.  Best not to design it with that much close-coupling _not_ 
required.

---

From: ram <[email-masked]>
Date: Tue, 02 Feb 2010 11:31:08 +0530

>          email (including address), or some other protocol and

I think thinking of a non-mail protocol to send abuse reports is an
excellent idea. 
Sending ARF's via email need not be the only option.  Why not use the
header 

eg X-Abuse-to: <http://mailserver.isp.com/cgi-bin/fbl>
<mailto:[email-masked]>
Obvioulsy the MUA must verify if the mail is authenticated , DKIM seems
a good way to do this. 

Sending abuse reports via http (POST?) should be standardized. 
If http is not available ( possibly some corporates block http access )
then you can fallback to email. 
The MUA must also have proper time outs so as to cut-off malicious fbl
urls

---

From: Al Iverson <[email-masked]>
Date: Tue, 2 Feb 2010 18:29:45 -0600

On Tue, Feb 2, 2010 at 12:01 AM, ram <[email-masked]> wrote:

> The MUA must also have proper time outs so as to cut-off malicious fbl urls

And any sort of FBL-via-MUA process should be opt-in, as well.
Checking only for a signature means bad guys signing mail can direct
where the feedback goes when you hit "this is spam." That data could
be misused to confirm email addresses, telling a spammer "we got a
live one" and making the email address worth selling.

Come to think of it, I don't think this should be core MUA
functionality. Even though I work for an ESP and would want the
feedback, I see too much opportunity for abuse. I'd rather see
third-party "report spam" plugins wherein that third party can make
the determination on where and whether or not to route a report. If
that third party doesn't trust or know about the sender, a report
would hopefully not be sent.

Regards,
Al Iverson

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 03 Feb 2010 10:54:50 +0100

> of the client roaming somewhere else and getting a forward.

The receiving end does not /have/ to zap prior instances of the same 
field. It filters off any maliciously forged Authentication-Results 
bearing its own authserv-id, but they wouldn't have provided a 
different target anyway. Users who receive considerable traffic 
through a forwarding MTA may wish to enable its authserv-id as well. 
When reporting such a message as spam, a MUA may send multiple copies. 
Semantically, that's fine. However, the last MX should avoid to route 
a second AR to the forwarder, in this case. (See picture in 
http://wiki.asrg.sp.am/wiki/Abuse_Reporting)

> trust the report it got from the client. That's a different affair.

In general, a (trusted) report from a client should reach the 
originating domain, whose operators can make the best use of it, 
assuming they're honest. It seems advisable that clients delegate such 
routing decisions to their servers. The servers, in turn, delegate 
that to some other trusted operator, unless they have specific 
arrangements with the reported domain. I tend to consider this 
indirection a consequence of the MSA/MX design.

> verifies. Best not to design it with that much close-coupling _not_

I agree we must not specify how to do verifications. It may be a 
custom local filter, as it supposedly knows where to find the logs or 
whatever it needs. It may even be possible to filter ARF messages in 
transit through an MSA, such as at the last MX case above: the trust 
that the user has conferred can be acknowledged by filling, say, the 
Reporting-MTA field.

As for tying an MTA to abuse reports handling, I think it is the most 
convenient choice. The kind of spam that we may be able to control by 
properly routing ARs does not require the immediateness of HTTP.

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 03 Feb 2010 13:09:41 +0000

> would hopefully not be sent.

This is one reason to support an IMAP extension. If the communication is 
between the authenticated user and the IMAP server, then there doesn't seem 
to be room for abuse of the abuse reporting mechanism.

Granted, if the client machine is compromised then all bets are off.

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 3 Feb 2010 11:25:34 -0500

Ian Eiloart wrote:

> This is one reason to support an IMAP extension.

There's no reason not to.  The important thing to realize at this stage 
is the basic principles an implementation of a "standard spam button" 
thing should support: multiple reporting mechanisms, specifiable 
destinations, and a couple flavours of content.

Discussions over whether there should be IMAP, POP, SMTP, NTP, DNS, 
HTTP, NNTP, or whatever mechanisms is largely irrelevant at this stage. 
  A recognition that there should be provision for more than one is the 
useful bit.  The important bit right now is the signalling and things 
like, who can specify, whether one can override, whether multiple 
destinations is desired.

 > If the communication is between the authenticated user and the
 > IMAP server, then there doesn't seem to be room for abuse of the
 > abuse reporting mechanism.

Given the rise of AUTH hijacking in current use for spamming, you have 
to pay attention even here, and I'm sure the miscreants will come up 
with something.  Senders would like to be able to specify.  Meaning that 
the local report destination has to be able to handle that forwarding. 
Meaning there are potential vulnerabilities.

Eg: scum spammer inserting instructions to forward complaints as a DOS 
to an innocent third party.

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 3 Feb 2010 11:45:35 -0500

> field.

No, it doesn't technically have to, but it _will_ have to give the 
client a hand in making sure the client doesn't trust bogus/malicious 
ones or ones outside of the receiving site's policies.

Removing the ones it doesn't want the client to respect and/or rewriting 
the ones it does want the client to respect, or simply replacing them 
all with its own is the best way of doing that.

> It filters off any maliciously forged Authentication-Results 
> different target anyway.

Why not?  Why wouldn't a scammer attempt to divert the recipient's TiS 
buttons to /dev/null, DDOS someone else, or divert complaints away from 
their provider who might zap them?

> assuming they're honest.

And assuming that meets the recipient server's policies.  As a 
corporate, for example, we must have the final word on what reporting 
our users do and to where.  That will often _not_ be where the sender or 
forwarder is trying to tell the client.

For simplicity, you may well want to have the core specification require 
that the receiving MTA makes all the choices at transit time, and 
removes all forwarding instructions that it doesn't agree with.

That means that the client, assuming that the client knows that the 
receiver is doing all the work, doesn't have to do any cryptographic 
verification, and the receiver may not need to either.

> It seems advisable that clients delegate such 

The indirection may well be desirable, but you have to ensure that it is 
convenient to do so (in other words, make sure that the client's 
provider's AR handling _know_ what routing decisions they're being asked 
to assess and implement).

> properly routing ARs does not require the immediateness of HTTP.

The MTA is only essential to abuse report handling insofar as the abuse 
reports may adjust the filters.  It'll be convenient to do the AR 
handling on the MTA in some instances, but in many it will be not a good 
choice.  An specificiationd esign that makes AR handling independent of 
the MTA is a better one.  You can run it co-resident if you wish.  But 
you don't have to.  Making the spec require too much of the MTA function 
would be a mistake in that regard.

---

From: Steve Atkins <[email-masked]>
Date: Wed, 3 Feb 2010 08:52:51 -0800

On Feb 3, 2010, at 8:25 AM, Chris Lewis wrote:

> There's no reason not to.  The important thing to realize at this stage is the basic principles an implementation of a "standard spam button" thing should support: multiple reporting mechanisms, specifiable destinations, and a couple flavours of content.

That's all a bit "why go for a simple approach, when a complex one will work?", though.

> Discussions over whether there should be IMAP, POP, SMTP, NTP, DNS, HTTP, NNTP, or whatever mechanisms is largely irrelevant at this stage.  A recognition that there should be provision for more than one is the useful bit.  The important bit right now is the signalling and things like, who can specify, whether one can override, whether multiple destinations is desired.

Anything that's done via the mailbox retrieval protocol is going to need to support at least POP3 andIMAP4, possibly others. That's already doubling the complexity. While IMAP could be handled via some "standard" mailbox naming, POP3 is going to require an out-of-band communication channel from MUA to mailbox provider, unless you're already doing something horrible like XTND XMIT. If the communication from mailbox provider to MUA needs to be in-band (as opposed to implicit or sent as part of the message payload) then that would probably require rewrites of the imap or pop3 server to support it. That's a whole lot of development effort.

It's also likely to require extensions to the protocol handler in the MUA. That means it most likely couldn't be implemented as a plugin, rather it would require changes to the MUA core code.

The original question was something like "how might an MUA notify the mailbox provider when the user hits the TiS button". This is, pretty much, a solved problem in specific cases, so the interesting question is how to do it such that most any client MUA can communicate with most any mailbox provider, while minimizing the amount o development work needed.

That suggests a lowest common denominator approach, rather than anything fancy. And there are just two thing every modern MUA has in common - that's the ability to submit mail via SMTP, and the ability to read and write 822+mime format messages.

(This all is predicated on supporting POP3, as there's lots of ways to do this via IMAP, but I think that's a given.)

Cheers,
  Steve

---

From: Michael Thomas <[email-masked]>
Date: Wed, 03 Feb 2010 09:15:47 -0800

> (This all is predicated on supporting POP3, as there's lots of ways to do this via IMAP, but I think that's a given.)

Would it really be such a sin to just pretend that POP3 doesn't exist/matter? It
is a pretty primitive mechanism, after all. Not everything needs to be a 100% solution
to be useful.

Mike

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 3 Feb 2010 17:30:37 -0500

> That's all a bit "why go for a simple approach, when a complex one will work?", though.

True to an extent, on the other hand, the alternative is an 
un-upgradeable spec that may be obsolete before it's ever used. There's 
no need to necessarily specify how each of the variations work nor even 
which ones are necessarily valid, just specify how the statements (of 
what, where, how) are made.  Then each of the "what, where, hows" can be 
independently specified as companion specs when people think they need 'em.

Kinda like the return codes of EHLO in ESMTP ;-)

At this point we need to be technology agnostic as much as possible, and 
specify what the thing actually does and how to express it header-wise 
(or whatever) in keeping with security, usefulness and flexibility.

---

From: John Levine <[email-masked]>
Date: 4 Feb 2010 04:39:58 -0000

>Would it really be such a sin to just pretend that POP3 doesn't
>exist/matter? It is a pretty primitive mechanism, after all. Not
>everything needs to be a 100% solution to be useful.

Well, heck, we could just tell everyone to switch to web mail and we'd
already be done.

There are a whole lot of people picking up their mail using POP from a
whole lot of mail systems.  Disks are cheap but they are not free, and
many ISPs do not want to host the permanent mailstore for their users.
I agree we don't need a 100% solution, but we really need at least a
50% solution.

R's,
John

---

From: Ian Eiloart <[email-masked]>
Date: Thu, 04 Feb 2010 11:16:05 +0000

--On 3 February 2010 08:52:51 -0800 Steve Atkins <[email-masked]> wrote:

> While IMAP could be handled via some "standard" mailbox naming,

No, really it should not. There are hundreds of languages out there, and 
people should be able to choose their own mailbox names. The communication 
should be via a flag or label attached to either a mailbox, or to 
individual messages.

---

From: Ian Eiloart <[email-masked]>
Date: Thu, 04 Feb 2010 11:17:39 +0000

--On 3 February 2010 09:15:47 -0800 Michael Thomas <[email-masked]> wrote:

>> (This all is predicated on supporting POP3, as there's lots of ways to
>> do this via IMAP, but I think that's a given.)
>
everything needs to be a
> 100% solution to be useful.

That works for me! I have only two POP3 users, and 15k IMAP users. The POP3 
users can email me their spam reports, if they like!

---

From: Ian Eiloart <[email-masked]>
Date: Thu, 04 Feb 2010 11:25:23 +0000

> I agree we don't need a 100% solution, but we really need at least a

It's simple to come up with a 100% solution for IMAP users, based on 
current mechanisms (flags, ANNOTATE or METADATA).

There may be a 100% solution for POP3 users, but I think it's not going to 
be as good as an IMAP solution, and won't be as simple to define the 
standard, or to implement it.

So, let's not ignore POP3 users. After all, their data will be useful in 
identifying spammers, and there are a lot of them. But, equally, let's not 
try to solve two different problems with the same solution. And, let's not 
delay an IMAP solution while examining the POP3 problem.

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

---

From: John Levine <[email-masked]>
Date: 4 Feb 2010 17:44:21 -0000

>So, let's not ignore POP3 users. After all, their data will be useful
>in identifying spammers, and there are a lot of them. But, equally,
>let's not try to solve two different problems with the same
>solution. And, let's not delay an IMAP solution while examining the
>POP3 problem.

Putting on my standards hat, a standard that mandates one process that
everyone can use is much more likely to be useful than one that has a
bunch of options that need separate implementations.

On the other hand, if you want something that IMAP users can use right
now, move messages to the Spam folder.  After all, one of the largest
mail systems in the world (AOL) implements it right now.  If you were
about to say no, that's too ugly, you've just confirmed my point.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Thu, 04 Feb 2010 10:09:29 -0800

> I agree we don't need a 100% solution, but we really need at least a

50%? ::snort::

In any case it hardly matters because POP3 and IMAP are completely different
protocols with different constituencies. You'd never have a standards effort
that lumps them together in a million years, and even if you did you'd do
nothing more than needlessly confuse the programmers of their respective
code bases.

So IMAP could be done really fast and simply, while POP3 -- assuming there's
any constituency at all to push for it -- could lumber along at its own pace.

Mike

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 04 Feb 2010 20:34:04 +0100

On 03/Feb/10 17:45, Chris Lewis wrote:
>> [Authentication-Results] field.
>

An ADMD may keep a database of known bogus authserv-id's (OpenDKIM 
apparently supports this). It may prevent gullible users from trusting 
questionable servers. However, it shouldn't be needed unless MUAs 
repeatedly ask users to trust any authserv-id just because they found 
it in some messages' headers.

> all with its own is the best way of doing that.

Like removal of "Received" traces, this shouldn't be done frivolously.

>> It filters off any maliciously forged Authentication-Results bearing
>> its own authserv-id, but they wouldn't have provided a different
>> target anyway.
>

That's not possible: the authserv-id is just a naked token. Actually, 
it doesn't even have to be an existing mail domain. Overloading RFC 
5451 in order to derive a destination for ARs is just a convenience 
for MUAs. Otherwise, users could just spell out a list of ARF 
recipients. The problem with that approach is how to avoid that MUAs 
have to resort to heuristics when a user has multiple accounts or 
forwarders. Since the Authentication-Results header conveys exactly 
the same meaning --the party responsible for receiving a message-- the 
overload is correct, IMHO.

However, Authentication-Results contains no further meta-info, 
command, or indication that would be used for sending ARs. Just the 
authserv-id token itself.

> And assuming that meets the recipient server's policies. As a corporate,
> for example, we must have the final word on what reporting our users do
> and to where. That will often _not_ be where the sender or forwarder is
> trying to tell the client.
>

Hmm... I like the idea that an MTA may acknowledge ARF reports in 
transit, as it allows users to communicate to their ISPs that they 
have enabled some other authserv-id. However, there may be better ways 
to achieve the same effect without specifying SMTP behavior that would 
be unique to ARF handling.

Slight alterations of messages that give corporate acknowledgments are 
quite usual, e.g. footers and DKIM signatures. However, changing a 
message's destination is not common, AFAIK.

> verification, and the receiver may not need to either.

The client can rely on the fact that all messages in a given mailbox 
have been received by the relevant server. However, a server doesn't 
know that an ARF contains a message that it had previously delivered 
to the reporter. This is different from webmail.

> to assess and implement).

Well stated. Policies and experience are essential here, but it would 
be desirable to have a set of easy rules that a newcomer may/ should 
follow in order to behave correctly. Perhaps, presentation of new mail 
domains and reputation tracking will eventually be specified.

> reports may adjust the filters.

Not only that. User IDs and authentication methods may be specific for 
mail apps. We should follow ease of development and deployment.

> It'll be convenient to do the AR
> choice. A specification design that makes AR handling independent of
> the MTA is a better one. You can run it co-resident if you wish. But you
> don't have to. Making the spec require too much of the MTA function

Some task may deserve a different tool, of course. However, making the 
spec too general, e.g. reporting spam using different transports, may 
become cumbersome.

Do you have a specific case in mind?

---

From: "Chris Lewis" <[email-masked]>
Date: Thu, 4 Feb 2010 16:46:26 -0500

> Like removal of "Received" traces, this shouldn't be done frivolously.

It's never stopped Microsoft :-E

I'm envisaging a situation where the email as received by the UA has one 
or more sets of instructions of how to send a TiS report, and where. 
_Most_ of the time it _may_ be the MUA communicating back to its MTA 
(perhaps by IMAP).  The MTA can simply insert those as per site policy. 
  But the MTA may choose to allow upstream instructions through as well 
(if it chooses to trust them).

> That's not possible: the authserv-id is just a naked token.

It can if the instructions contain where and how to report.

> transit,

I'm specifically referring to the MTA indicating _which_ TiS 
"instructions" the MUA is permitted to follow (perhaps simply by 
removing whatever instructions it elects not to permit).  Not 
necessarily that the MTA send the ARF reports.  In fact (as below), it 
wouldn't be the MTAs that send an ARF report in my infrastructure.

> message's destination is not common, AFAIK.

I'm not talking about altering destination of the message.  I'm talking 
about altering/replacing the destination of an abuse report.

Besides, spam filters change destinations all the time.

> to the reporter. This is different from webmail.

Doesn't necessarily need to, especially if it's told/allowed the MUA to 
send the report directly.

> domains and reputation tracking will eventually be specified.

I don't think we want the user to be involved at all, aside from pushign 
the TiS button.

> mail apps. We should follow ease of development and deployment.

As long as you don't force it.

> spec too general, e.g. reporting spam using different transports, may 

This has nothing to do with transports, but everything to do with 
destinations.

> Do you have a specific case in mind?

Yes, mine.  As many as 11 dumb front end SMTP filtering engines in DMZes 
firewalled off like crazy.  Internal infrastructure a mixture of O/S and 
MTA technology run by a different group. and has dozens of mailbox 
servers (mixture of IMAP, POP and Microsoft stuff).

Filtering engines managed by centralized filter control server, which 
manages quarantine, abuse complaints, logging, FP mitigation, and all 
filter adjustment.

Bad idea to put much intelligence on the DMZes of any kind. These things 
really are dumb - SMTP in, SMTP to infrastructure, control & log 
exchange with control server.  No mailboxes, IMAP, POP or anything. No 
persistent message data of any kind - no spool, even logs are highly 
transient.

[If one of these blows up, I reinstall the software on bare machine, hit 
"go" and it's back in operation.  Truly appliances.]

Have zero access to internal infrastructure.  Would have to replicate 
and manage TiS extensions on them all.

We treat abuse management/spam as an independent overlay on top of the 
internal infrastructure.  I don't bug them, they don't bug me ;-)  It's 
  entirely internal infrastructure/technology independent.

[The filtering infrastructure is designed that way, originally as a 
potential product, without having to alter the customer's internal 
machines.  That's not going to happen now.]

The logical place to implement abuse reporting mechanisms is on the 
control server, and I've already dabbled in that.  They don't even have 
to be user-initiated.  Have a filter say "this message came from a BOT", 
automatically the control server sends a notification.

Our TiS button consists, in the main, getting a filter-generated 
message-id (not RFC2822 Message-ID) back to the control server, and it 
can identify everything it needs to know about the email from that. 
Today, it's by simple forwarding of the message to an alias on the 
control server, and the ID is scraped from that.  A simpler mechanism 
using existing tools would be a simple HTTP GET with a ID parameter, but 
tying that to a UA button is hard (unless it gets standardized).  If it 
were standardized, could use a entirely different protocol.  Even a 
single short UDP packet would do the trick.

The filters could have rules on how to add/adjust inbound abuse 
reporting instructions.  I'd like nothing more than to accept/implement 
"forward to X" instructions from sites I trust.  Whether the MUA or the 
control server actually executes the instructions I don't care that much.

---

From: John Levine <[email-masked]>
Date: 4 Feb 2010 23:20:46 -0000

>nothing more than needlessly confuse the programmers of their respective

Actually, we've seen a reasonable suggestion a few messages back that
would work equally well with POP and IMAP: extract a reporting address
from the message and send it an ARF report.  It has the admirable
characteristic of being completely agnostic about how the mail is
delivered, since there are plenty of delivery techniques other than
POP and IMAP, such as WebDAV, uucp (still handy for intermittent
connections), fetchmail, and just reading the local mailstore.

R's,
John

PS: If you're going to make disparaging remarks, could you at least
try and make well informed ones?

---

From: "Chris Lewis" <[email-masked]>
Date: Thu, 4 Feb 2010 18:59:52 -0500

> connections), fetchmail, and just reading the local mailstore.

If we want to sidestep the issue of how to deal with senders wanting 
their FBLs, the very simplest method of all is to have the TiS button 
send an ARF to a specific address, and let that address figure out 
everything else.

I could live with that even in my odd-ball architecture (which probably 
resembles other very large infrastructures).  I already do that (without 
the ARF format), and the recipient address has to be manually configured 
in the MUA.

I'd only add that I'd prefer _not_ to have to have the user configure 
the MUA where to send the ARFs to.  The receiving mail server inserts 
it.  Meaning that the MUA has to be able to determine it's valid.

I think this is important because many MUAs receive email from multiple 
infrastructures, each potentially with their own policies.

If we only support emailed ARFs, the only parameter you need is the address.

This has the advantage of being able to work correctly if the MUA 
receives email from several different infrastructures, even if some 
don't support reporting.

Even has the ability to work if the receiving mail system can't handle 
the ARFs at all, just forward em off to a trusted 3rd party.

---

From: Steve Atkins <[email-masked]>
Date: Thu, 4 Feb 2010 16:18:27 -0800

On Feb 4, 2010, at 3:59 PM, Chris Lewis wrote:

> If we want to sidestep the issue of how to deal with senders wanting their FBLs, the very simplest method of all is to have the TiS button send an ARF to a specific address, and let that address figure out everything else.
> 
> I could live with that even in my odd-ball architecture (which probably resembles other very large infrastructures).  I already do that (without the ARF format), and the recipient address has to be manually configured in the MUA.
> 
> I'd only add that I'd prefer _not_ to have to have the user configure the MUA where to send the ARFs to.  The receiving mail server inserts it.  Meaning that the MUA has to be able to determine it's valid.
> 
> I think this is important because many MUAs receive email from multiple infrastructures, each potentially with their own policies.
> 
> This has the advantage of being able to work correctly if the MUA receives email from several different infrastructures, even if some don't support reporting.
> 
> Even has the ability to work if the receiving mail system can't handle the ARFs at all, just forward em off to a trusted 3rd party.

+1. This is exactly what I suggested way, way upthread.

All you need to be able to do at the MX level is add a (possibly constant) header to each inbound email.

There's a subtle implication, which is that if you're stashing the ARF consumer address in a header, and your MX isn't overwriting (or stripping) that header, then it's possible that spam reports could be sent to the preferred reporting address of someone further up the delivery chain. I see this as an advantage, but it needs to be mentioned.

Cheers,
  Steve

---

From: Bart Schaefer <[email-masked]>
Date: Thu, 04 Feb 2010 18:58:34 -0800

On Feb 4,  4:18pm, Steve Atkins wrote:
}
} There's a subtle implication, which is that if you're stashing the
} ARF consumer address in a header, and your MX isn't overwriting (or
} stripping) that header, then it's possible that spam reports could
} be sent to the preferred reporting address of someone further up
} the delivery chain. I see this as an advantage, but it needs to be
} mentioned.

This is exactly the point I was making, over at the head of another
sub-thread.  If a reporting address can come in from somewhere up the
chain, then it can come in *forged*, and whatever software is going
to interpret the address needs a defense against that.

Numerous proposals for dealing with this (and arguments about why it
isn't necessary, or in Rich's case, why it's irrelevant) have already
been bandied about.

---

From: "Chris Lewis" <[email-masked]>
Date: Thu, 4 Feb 2010 22:57:21 -0500

> isn't necessary, or in Rich's case, why it's irrelevant) have already

It happens ;-)

The basic thing is that either the MUA knows how to handle ARFs without 
relying on anything the mail stream (user config of where to send ARFs), 
or has to know that the message path supports abuse reporting (user 
configuration boolean switch), it can trust ARF directive[s] in the 
headers AND that the message stream HAS to take steps to destroy any ARF 
directives it doesn't want its downstream users to execute.

If either the above are true, you don't need to go to extremes to, say, 
cryptographically secure ARF directives and put all sorts of 
trust-evaluation gunk into the MUA.  Putting the latter in MUAs would be 
a big istake.

But if you do inband ARF directives, if the originator sets ARF strings, 
it needs to not DKIM that header ;-)

I'd rather not burden the user with any configuration at all, and if you 
have to have the user do something, the lesser the better.  That isn't a 
big deal in environments where the users are running site-preconfigured 
MUAs (like us), but becomes an issue elsewhere, and you have to tell the 
user what to set it to.

The advantage of MUA-only configuration is that you don't have to touch 
the MTAs at all to make it work.  Indeed, if you want to outsource your 
ARF handling, or the user wants to do them anyway, you only have to make 
your MUA TiS capable, no other changes required.  That may outweigh all 
other considerations.

---

From: Steve Atkins <[email-masked]>
Date: Thu, 4 Feb 2010 20:12:01 -0800

On Feb 4, 2010, at 7:57 PM, Chris Lewis wrote:

> The basic thing is that either the MUA knows how to handle ARFs without relying on anything the mail stream (user config of where to send ARFs), or has to know that the message path supports abuse reporting (user configuration boolean switch), it can trust ARF directive[s] in the headers AND that the message stream HAS to take steps to destroy any ARF directives it doesn't want its downstream users to execute.
> 
> If either the above are true, you don't need to go to extremes to, say, cryptographically secure ARF directives and put all sorts of trust-evaluation gunk into the MUA.  Putting the latter in MUAs would be a big istake.
> 
> But if you do inband ARF directives, if the originator sets ARF strings, it needs to not DKIM that header ;-)
> 
> I'd rather not burden the user with any configuration at all, and if you have to have the user do something, the lesser the better.  That isn't a big deal in environments where the users are running site-preconfigured MUAs (like us), but becomes an issue elsewhere, and you have to tell the user what to set it to.
> 
> The advantage of MUA-only configuration is that you don't have to touch the MTAs at all to make it work.  Indeed, if you want to outsource your ARF handling, or the user wants to do them anyway, you only have to make your MUA TiS capable, no other changes required.  That may outweigh all other considerations.

Also, if the failure mode is that the original sender of the email can cause feedback loop reports to be sent to any email address they like there aren't many real concerns.

First, confidential data. The only data that might be considered confidential is the contents of the original email (that's all there is in an ARF report other than a little metadata). The sender already has access to that, so it's pretty much a non-issue. (Most anyone can sign up for a feedback loop with consumer ISPs today, and there's not any obvious abuse of the data possible).

Second, use of the FBL for harassment. It's not a great channel for that, as even theoretically it can cause at most one email for each original email sent out. More realistically it's more like 1:100 or so, as pitching an email such that it'll get through someones spam filters to a recipient, but still be objectionable enough for them to hit the TiS button is tricky enough, and any mail sent to any ISP that was aware of this protocol (to the extent of overwriting or deleting the relevant header) wouldn't count. Less of an issue than return path or reply-to.

And that's about it. There's not really any need to "defend" against "forgery" at all.

Cheers,
  Steve

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 05 Feb 2010 10:38:37 +0000

> bunch of options that need separate implementations.

Well "two" implementations; we already have IMAP and POP3 protocols for 
accessing mail stores. And, we're talking about how we communicate with the 
mail store administrator, right? It seems pretty obvious to me that that's 
going to be different for a POP3 user than an IMAP user.

I don't know POP3 well, but would it not be possible to say something like 
"the nth message from my last download was spam"?

> about to say no, that's too ugly, you've just confirmed my point.

It's not just ugly, it's exactly the reverse of what spam folders are 
usually used for. They're usually used by ESPs to put suspected junk in. An 
email's presence in the spam folder means "the server side filter thought 
this was spam". And, there's no standard name for that folder. And, nor 
should there be.

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 05 Feb 2010 10:40:29 +0000

--On 4 February 2010 23:20:46 +0000 John Levine <[email-masked]> wrote:

> from the message and send it an ARF report.

Which is certainly not at all simpler than setting an IMAP flag on a 
message. And (if it's what the user desires) moving it out of the INBOX.

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 05 Feb 2010 10:44:38 +0000

--On 4 February 2010 23:20:46 +0000 John Levine <[email-masked]> wrote:

>  extract a reporting address

Which means that the email service provider has to decide what to do with 
messages that arrive carrying such a reporting address. I don't see what 
you can do except remove it - given that we're talking about junk email 
here.

Then it has to insert its own header into every message.

Then the client has to try to figure out whether the reporting address was 
inserted by the spammer, or by their email service provider.

Given that a "This is spam" button should only be reporting to the 
mailstore administrator, it's completely over the top to insert the address 
into every message. The address is a property of the mailstore, not the 
message.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 05 Feb 2010 12:16:36 +0100

On 05/Feb/10 11:44, Ian Eiloart wrote:
> mailstore administrator, it's completely over the top to insert the
> address into every message. The address is a property of the mailstore,
> not the message.

The mailstore where a message resides is not exactly the same thing as 
the MTA responsible for receiving a message, although most of the 
times they coincide.

In addition, there is the sidestepped issue of sending reports where 
the relevant administrative actions can be made. Most of the times 
this is not the mailstore administrator.

---

From: Daniel Feenberg <[email-masked]>
Date: Fri, 5 Feb 2010 07:09:05 -0500 (EST)

On Thu, 4 Feb 2010, Chris Lewis wrote:

> If we want to sidestep the issue of how to deal with senders wanting their 
> FBLs, the very simplest method of all is to have the TiS button send an ARF 
> to a specific address, and let that address figure out everything else.
>
> resembles other very large infrastructures).  I already do that (without the 
> ARF format), and the recipient address has to be manually configured in the 
> MUA.
>
> I'd only add that I'd prefer _not_ to have to have the user configure the MUA 
> where to send the ARFs to.  The receiving mail server inserts it.  Meaning 
> that the MUA has to be able to determine it's valid.
>

I haven't been following this thread very closely, but why not just 
establish a standard role account on the MUAs designated POP or IMAP 
server? Such as [email-masked]? It effectively "preconfigures" the 
MUA since "arf" is standard and "example.com" is already known to the MUA. 
The less configuration the better, I think.

I reject arguments that "arf" is English, and that non-english speakers 
need an address consistent with their native tongue - partly because users 
won't need to do the configuration themselves, partly because "arf" isn't 
English, and partly because the argument is just too silly anyway. People 
learn a few words of Italian if they want to play music, and a few words 
of French if they want to cook, they can learn a few words of English if 
they want to compute. I note that the French language standard for 
Fortran-66 was not widespread, even in France.

If someone already has the userid "arf", that is too bad.

> infrastructures, each potentially with their own policies.

The MUA could keep track of the ARF server associated with the current 
POP/IMAP server.

> This has the advantage of being able to work correctly if the MUA receives 
> email from several different infrastructures, even if some don't support 
> reporting.
>
> Even has the ability to work if the receiving mail system can't handle the 
> ARFs at all, just forward em off to a trusted 3rd party.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 05 Feb 2010 13:27:59 +0100

>>  But if you do inband ARF directives, if the originator sets ARF strings, it needs to not DKIM that header ;-)

Agreed, but for originators only. Re-signing forwarders may well want 
to do that.

>>  I'd rather not burden the user with any configuration at all, and if you have to have the user do something, the lesser the better.  That isn't a big deal in environments where the users are runn…

It should be easy to specify how automatic configuration can determine 
that the principal mail domain can be trusted. Additional domains will 
have to be enabled manually, but that wouldn't be needed if forwarding 
were set up savvily.

>>  The advantage of MUA-only configuration is that you don't have to touch the MTAs at all to make it work.  Indeed, if you want to outsource your ARF handling, or the user wants to do them anyway,…

+1

> And that's about it. There's not really any need to "defend" against "forgery" at all.

The second statement is not strictly true, as multiple fields may be 
added at each hop.

Reports concerning bot-generated stuff should only be routed to the 
relevant connection provider. While some of them are apparently 
tackling the sanitization of their user bases, other LIR registrants 
may consider it a harassment to receive a stream of ARs, possibly at a 
random mailbox address of theirs, even if the data is good. They may 
want to opt out. A site policy may or may not allow that, but it 
shouldn't be an end-user decision.

IMHO the above is a rationale for letting MUAs send ARFs /only/ to the 
last (topmost) enabled authserv-id, unless explicitly overridden by 
user's configuration.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 05 Feb 2010 16:01:45 +0100

> (if it chooses to trust them).

Isn't that unnecessarily complicated?

>>> Why wouldn't a scammer attempt to divert the recipient's TiS

That's one complication resulting from having instructions.

> removing whatever instructions it elects not to permit). Not necessarily
> that the MTA send the ARF reports. In fact (as below), it wouldn't be
> the MTAs that send an ARF report in my infrastructure.

Ok, it doesn't have to be the MTA proper. It can be done by any 
machine on the server side. However, if clients dumbly send ARs to the 
authserv-id, some handler on the server side has to take care of 
routing them appropriately.

> send the report directly.

It becomes intricate to first filter incoming messages in order to zap 
any ARF destination which is rejected by policy, and then filter 
outgoing reports to check that the MUA accomplished. It seems more 
straightforward to just do what is appropriate.

> This has nothing to do with transports, but everything to do with

It shouldn't be difficult, on the server side, to redirect traffic 
destined to abuse@ to the most convenient machine for processing it.

If I got your point correctly, you don't want that machine to 
necessarily host an SMTP server. I agree. A message can be transferred 
to its destination by any means. However, it may be convenient to make 
some discrimination earlier. E.g. whether a message is from an 
authenticated user reporting abuse, rather than from a third party 
routing reports to the Reported-Domain. In addition, the result of 
processing may involve sending an ARF message out. In some cases, 
however, reporting is only accepted via HTTP (e.g. 
http://www.dnswl.org/abuse/)

> control server actually executes the instructions I don't care that much.

The "forward to X" instructions might consist of 
Authentication-Results and VBR-Info fields. The handler should check 
that the MUA hasn't already included any of them, to avoid duplication.

"Trust" in this case would really mean "know", just to avoid noise and 
bounces. ARs about messages with no valid authentication don't deserve 
being forwarded, except possibly to the connection provider. INCH may 
be a better notification protocol, in case the handler can determine 
that a botnet is involved.

---

From: John Levine <[email-masked]>
Date: 5 Feb 2010 15:10:49 -0000

>The less configuration the better, I think.

Sorry, wouldn't work.  The name of the POP or IMAP server need not
bear any relationship to any email address.  For example, on my
system, the server is named imap.iecc.com (yes, even for POP, it
deters the clueless) but there are not imap.iecc.com addresses at all.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 05 Feb 2010 16:15:08 +0100

On 05/Feb/10 13:09, Daniel Feenberg wrote:
> MUA since "arf" is standard and "example.com" is already known to the
> MUA. The less configuration the better, I think.

"Abuse", which is what the "a" in ARF stands for, has the advantage of 
being already set aside for this purpose by RFC 2142. The "pop." part 
is more of an hindrance in this case.

> need an address consistent with their native tongue - partly because
> users won't need to do the configuration themselves, partly because
> "arf" isn't English, and partly because the argument is just too silly
> anyway. People learn a few words of Italian if they want to play music,
> and a few words of French if they want to cook, they can learn a few
> words of English if they want to compute. I note that the French
> language standard for Fortran-66 was not widespread, even in France.

+1! As a side note, also standard IMAP folders names should be in 
English (possibly translated on the fly) otherwise an IMAP client's 
behavior would be incompatible with that of its translations.

>> I think this is important because many MUAs receive email from
>> multiple infrastructures, each potentially with their own policies.
>

It requires more development on MUA, and wouldn't work for a local 
server fed via fetchmail, that various Linux laptops sport.

However, a correct implementation of the Authentication-Results 
proposal should refuse to report as spam a message that had been 
manually moved from one account's mailbox to another, unless the user 
had thoughtlessly enabled the relevant authserv-id for the wrong mailbox.

---

From: Daniel Feenberg <[email-masked]>
Date: Fri, 5 Feb 2010 10:15:23 -0500 (EST)

> deters the clueless) but there are not imap.iecc.com addresses at all.

I don't understand why this is relevant. If the MTA operator doesn't want 
to support this feature, he doesn't have to. But if he does wish to 
support the feature he needs to supply an MX record or accept mail on the 
POP or IMAP server. Is that such a great burden? Compared to the other 
suggestions here?

I you are going to ask both MUA and MTA software to both be modified 
before the protocol will work, then that is an insuperable obstacle that 
will surely prevent any implementation from occurring. Only MS can act 
with such total disregard for implementation incentives.

Daniel Feenberg

---

From: John Levine <[email-masked]>
Date: 5 Feb 2010 15:20:46 -0000

>message. And (if it's what the user desires) moving it out of the INBOX.

Can I ask people to stop making the newbie mistake of assuming that
all mail systems are, or should be, just like the mail system they
happen to use?  

I think IMAP is swell, I've used it for years, I've encouraged my
users to switch to it, but many of them won't.  They're not just being
stubborn--they prefer to have their archive of mail in a place that
they control, or they're connected intermittently and it's faster to
download and delete with POP than do the equivalent in IMAP.  The
tradeoffs in running a mail system for the students and staff at a
university, or for the employees of an equipment manufacturer, are not
the same as the ones at a consumer ISP or other kind of organization.
The world is not going to switch to 100% IMAP and it is just wasting
our time to pretend that it is.

R's,
John

---

From: John Levine <[email-masked]>
Date: 5 Feb 2010 15:46:55 -0000

>POP or IMAP server. Is that such a great burden? Compared to the other 

Honestly, none of us knows.  The name of the POP or IMAP server has
never been intended as part of an e-mail address, so it's hard to
predict what might break.  Overloading names tends to lead to
surprising failures.  For example, my POP/IMAP server is also my
SUBMIT server, and although it doesn't have an MX record, it does have
an A record.  That means that with your proposal, if I did nothing and
one of my users happened to have an MUA with a spam button, when he
pressed it, it would connect to my SUBMIT server and send a message to
the undeliverable address [email-masked], causing a baffling
bounce.

I share your concern about demanding upgrades to large amounts of mail
software which is why I'm not thrilled about changes to IMAP and POP
protocols.  I also think it's pretty important that the reporting
process has to be opt-in.  That's why an extra field in the
Authentication-Results header is attractive, it's something that
delivering MTAs are somewhat likely to add as part of the spam
filtering process anyway, and doesn't require and changes to the
downstream POP or IMAP or whatever.

R's,
John

---

From: Daniel Feenberg <[email-masked]>
Date: Fri, 5 Feb 2010 10:52:51 -0500 (EST)

> the undeliverable address [email-masked], causing a baffling

This is just a general argument against all role accounts, including 
postmaster, abuse, webmaster, etc. It doesn't balance the costs and 
benefits, just notes a possible cost as though that was sufficient to 
dismiss it.

I take the concern is that over at AOL or GMAIL, they might want to have 
the ARF server different from the POP server, but not want to use an MX 
record to do so, perhaps because the POP server was also meant to receive 
other (non-arf) mail. It seems like a very thin reed for a protocol that 
is optional anyway.

Daniel Feenberg

---

From: Steve Atkins <[email-masked]>
Date: Fri, 5 Feb 2010 08:58:13 -0800

On Feb 5, 2010, at 4:09 AM, Daniel Feenberg wrote:

> I haven't been following this thread very closely, but why not just establish a standard role account on the MUAs designated POP or IMAP server? Such as [email-masked]? It effectively "preconfigures" the MUA since "arf" is standard and "example.com" is already known to the MUA. The less configuration the better, I think.

POP and IMAP servers don't receive email. If you're planning on mandating that all POP or IMAP servers listen on port 587, that's a fairly big requirement. 

Or are you suggesting something MXish or SRVish (which isn't implausible, though it's got the usual namespace pollution problems to dodge)?

Cheers,
  Steve

---

From: "Chris Lewis" <[email-masked]>
Date: Fri, 5 Feb 2010 12:18:41 -0500

> Also, if the failure mode is that the original sender of the email can cause feedback loop reports to be sent to any email address they like there aren't many real concerns.

You're assuming that only the UA would generate ARFs.  I can envisage a 
situation where BOTs caught at the front end MTAs could be sent.  MTAs 
doing it would be instant death on a forged target, even if the MTAs 
hard rate limited (think backscatter bomb).  It could also be instant 
death on a non-forged target, but they're more likely to be able to 
handle it.

Then there's Joe Jobs.  Not necessarily so much with source IPs, but 
with, say, web site payloads getting falsely accused.

---

From: "Peter J. Holzer" <[email-masked]>
Date: Fri, 5 Feb 2010 18:31:58 +0100

On 2010-02-05 08:58:13 -0800, Steve Atkins wrote:
> > server? Such as [email-masked]? It effectively "preconfigures"
> > the MUA since "arf" is standard and "example.com" is already known
> > to the MUA. The less configuration the better, I think.
> 
> POP and IMAP servers don't receive email. If you're planning on
> mandating that all POP or IMAP servers listen on port 587, that's a
> fairly big requirement. 
> 
> Or are you suggesting something MXish or SRVish (which isn't
> implausible, though it's got the usual namespace pollution problems to
> dodge)?

Why "MXish"? Just MX. If pop.example.com doesn't listen on port 25 (if
you want to send Mail to [email-masked], you need something
listening on port 25, not 587), add an RR
    pop.example.com. MX 10 mx.example.com.
mx.example.com needs to be configured to accept mail for
[email-masked], of course. 

And, as John noted, if there is no such MX record, the mail will most
likely sit a queue for a few days until it is returned.

	hp

-- 
   _  | Peter J. Holzer    | Openmoko has already embedded
|_|_) | Sysadmin WSR       | voting system.
| |   | [email-masked]         | Named "If you want it -- write it"
__/   | http://www.hjp.at/ |  -- Ilja O. on [email-masked]

---

From: Steve Atkins <[email-masked]>
Date: Fri, 5 Feb 2010 09:33:41 -0800

On Feb 5, 2010, at 9:18 AM, Chris Lewis wrote:

> You're assuming that only the UA would generate ARFs.

No.

I'm assuming that only the MUA would generate human triggered reports. (And please don't refer to them as "ARFs" as that's... unhelpful.)

>  I can envisage a situation where BOTs caught at the front end MTAs could be sent.

No.

If it's caught at the MTA, then the MTA operator will decide where to send the reports.

>  MTAs doing it would be instant death on a forged target, even if the MTAs hard rate limited (think backscatter bomb).  It could also be instant death on a non-forged target, but they're more likely to be able to handle it.

No, that cannot happen.

> 
> Then there's Joe Jobs.  Not necessarily so much with source IPs, but with, say, web site payloads getting falsely accused.

No. At worst that's exactly the same as the status quo.

In the approach I'm suggesting, the only time a report will be sent to the email address embedded in the headers of the original email by the sender is when

  1. Neither the mailbox provider, nor any forwarder (e.g. acm.org) choose to be aware of the protocol

  and

  2. The mail is delivered to the end recipients inbox

  and

  3. The recipients MUA is aware of the protocol

  and

  4. The end recipient manually marks the message as spam

If any of those four requirements is not fulfilled, then no report will be sent to any email address embedded in the original message by the sender. If you're going to argue about how this will cause problems, you need to do so in that context.

Cheers,
  Steve

---

From: Daniel Feenberg <[email-masked]>
Date: Fri, 5 Feb 2010 12:59:44 -0500 (EST)

> mandating that all POP or IMAP servers listen on port 587, that's a 

Mail to [email-masked] may go to the host named example.com, or it may 
go to a host of any other name given in the MX statement for example.com. 
There is no requirement that pop.example.com host an MTA at all. Am I 
missing something or are you teasing me?

Furthermore, there can be no expectation that all email domains will 
support this protocol - so my expectation is that all email domains that 
wish to support this protocol for users receiving mail from pop or 
[email-masked] must have an MTA somewhere that can accept mail for 
arf@[pop|imap}.example.com. If there is a domain somewhere that wishes to 
support the protocol, but does not wish to use the naming convention, then 
they would be left out in the cold. I don't see that as a very big 
concern.

The desire to eliminate all naming conventions strikes me as pointless - 
they are widespread and quite helpful in my experience. From localhost to 
127.0.0.1, to postmaster and abuse what is the downside? Someone may wish 
to use "localhost" as a hostname? Did they miss the IETF meeting? Then 
they are out of luck. In any case, at somepoint there has to be a 
convention, all the protocol can do is add levels of indirection.

Daniel Feenberg

---

From: Daniel Feenberg <[email-masked]>
Date: Fri, 5 Feb 2010 13:02:53 -0500 (EST)

On Fri, 5 Feb 2010, Daniel Feenberg wrote:

>>>> I'd only add that I'd prefer _not_ to have to have the user configure the 
>>>> MUA where to send the ARFs to.  The receiving mail server inserts it. 
>>>> Meaning that the MUA has to be able to determine it's valid.
>>>> 
>>> 
>> POP and IMAP servers don't receive email. If you're planning on mandating 
>> that all POP or IMAP servers listen on port 587, that's a fairly big 
>> requirement.
>
> Mail to [email-masked] may go to the host named example.com, or it may go

Sorry, I meant "the host named pop.example.com".

Daniel Feenberg

---

From: "Chris Lewis" <[email-masked]>
Date: Fri, 5 Feb 2010 13:33:00 -0500

> deters the clueless) but there are not imap.iecc.com addresses at all.

Perhaps more to the direct point, what if you host a bazillion domains, 
you have to publish a bazillion <standard>.<domain> DNS records, which 
may all point at the same place.  A bit awkward, but perhaps doable.

But, picking "imap" for "<standard>" would be a mistake.  It should be 
independent of the delivery technology.  You could well run into severe 
trouble trying to dissassociate them.

---

From: "Chris Lewis" <[email-masked]>
Date: Fri, 5 Feb 2010 13:36:44 -0500

> POP or IMAP server. Is that such a great burden? Compared to the other 

Yes.  Why tie the ARF path to the mailboxes by naming convention?  Don't 
need to.

Use [email-masked].  If they're the same machine, fine, make 
arf.domain.com alias to imap.domain.com.  If they're not, you don't have 
to rename your mail infrastructure or screw around with forwarding on 
the imap machine that you may have no control over.

---

From: Steve Atkins <[email-masked]>
Date: Fri, 5 Feb 2010 10:38:52 -0800

On Feb 5, 2010, at 9:59 AM, Daniel Feenberg wrote:

> Mail to [email-masked] may go to the host named example.com, or it may go to a host of any other name given in the MX statement for example.com. There is no requirement that pop.example.com host an MTA at all. Am I missing something or are you teasing me?

I was asking for clarification - if you read the next sentence, you'll see me doing that, even mentioning MX records - as you suggested that the role account be on the designated POP or IMAP server.

> 
> Furthermore, there can be no expectation that all email domains will support this protocol - so my expectation is that all email domains that wish to support this protocol for users receiving mail from pop or [email-masked] must have an MTA somewhere that can accept mail for arf@[pop|imap}.example.com. If there is a domain somewhere that wishes to support the protocol, but does not wish to use the naming convention, then they would be left out in the cold. I don't see that as a very big concern.

What if they wish to use the naming convention, but do not wish to use the protocol?

A not unheard of setup for a vanity domain is for all traffic to be served at "example.com" - web, email, everything.

So there's a DNS record "example.com MX 10 example.com", and a POP3 or IMAP server listening on example.com[1].

If the MUA uses the existence of an MX record for the hostname of the POP or IMAP server to decide whether to enable the "TiS" button (an obvious thing to do) then in that case it will be enabled.

If the user hits the "TiS" button, then it'll either cause a rejection, a deferred bounce or (if it's a catch-all domain) deliver the report back to the users inbox.

This violates the UI principle of least surprise, and is part of what I was talking about when I said "namespace pollution".

[1] It may also be listening on imap.example.com, mail.example.com, pop3.example.com and www.example.com, all at the same IP address. As IMAP and POP3 are not name-based protocols, all of these will work. So the end user could put any of these in to their MUA as their IMAP server, and mail will work just fine. Automatic discovery may find one of these and not another, depending on probe order. So if you're relying on the MUAs IMAP server setting as a key, it's not that simple.

> 
> The desire to eliminate all naming conventions strikes me as pointless - they are widespread and quite helpful in my experience. From localhost to 127.0.0.1, to postmaster and abuse what is the downside? Someone may wish to use "localhost" as a hostname? Did they miss the IETF meeting? Then they are out of luck. In any case, at somepoint there has to be a convention, all the protocol can do is add levels of indirection.
> 
> Daniel Feenberg
> 
>> 

Cheers,
  Steve

---

From: Steve Atkins <[email-masked]>
Date: Fri, 5 Feb 2010 10:47:44 -0800

On Feb 5, 2010, at 10:36 AM, Chris Lewis wrote:

>> I don't understand why this is relevant. If the MTA operator doesn't want to support this feature, he doesn't have to. But if he does wish to support the feature he needs to supply an MX record or accept mail on the POP or IMAP server. Is that such a great burden? Compared to the other suggestions here?
> 
> Yes.  Why tie the ARF path to the mailboxes by naming convention?  Don't need to.

It's not an ARF path. ARF is just a mail format, one that is used in many other contexts. I'm going to pretend you said "feedback path" and "[email-masked]" instead. :)

> 
> Use [email-masked].  If they're the same machine, fine, make arf.domain.com alias to imap.domain.com.  If they're not, you don't have to rename your mail infrastructure or screw around with forwarding on the imap machine that you may have no control over.

How does the MUA autodiscover "domain.com", though, so as to create "[email-masked]"?

The only setting that the MUA is likely to have access to is the name of the IMAP or POP3 server. As IMAP and POP3 are not name-based, the entry there could easily be domain.com, mail.domain.com, imap.domain.com or pop.domain.com or smtp.domain.com or even www.domain.com.

One option is to have the MUA "use some heuristic to find the 'domain' associated with that hostname", but past experience with SSP suggests that it makes people point and laugh at you and start mentioning things like imap.aardvark.us.com.

Another would be to prepend "feedback." to the imap server name - so do an MX lookup for "feedback.imap.domain.com" to discover whether it's to enable the TiS button. That'll either need a DNS record added for every possible name for the IMAP server, or accept that it won't autoconfigure unless the recipient uses the name for the IMAP server you're expecting, either of which seems reasonable.

(That doing MX lookups is not something that MUAs typically need code for, and that isn't supported by base API, is a minor issue but worth mentioning).

Cheers,
  Steve

---

From: "Chris Lewis" <[email-masked]>
Date: Fri, 5 Feb 2010 14:15:34 -0500

Steve Atkins wrote:

Okay, but "arf" is so short ;-) And we have to get everybody else to use it.

"feedback" works too.

> The only setting that the MUA is likely to have access to is the name of the IMAP or POP3 server. As IMAP and POP3 are not name-based, the entry there could easily be domain.com, mail.domain.com, i…

It has the default name used in inbound email, as well as (usually) an 
email address used as a userid.  Per delivery server.  It may even be 
able to see the rcpt to (or the MTA could "help".  Oh, never mind).

> (That doing MX lookups is not something that MUAs typically need code for, and that isn't supported by base API, is a minor issue but worth mentioning).

Agreed.  I suspect many MUAs are completely incapable of doing direct to 
MX, and don't do MX lookups.  See other suggestion, where I say "Use 
normal submit mechanism".

---

From: Steve Atkins <[email-masked]>
Date: Fri, 5 Feb 2010 11:29:59 -0800

On Feb 5, 2010, at 11:15 AM, Chris Lewis wrote:

> It has the default name used in inbound email, as well as (usually) an email address used as a userid.  Per delivery server.  It may even be able to see the rcpt to (or the MTA could "help".  Oh, never mind).

Lets look at a concrete example from my MUA

Account type: IMAP
Description: Fruitbat
Email address: [email-masked], [email-masked], [email-masked], ...
Full Name: Steve Atkins
Incoming Mail Server: mail.wordtothewise.com
User name: steve
Password: *******
Outgoing Mail Server (SMTP): mail.wordtothewise.com

Of those, the only thing that's actually associated with the inbound mailbox is the incoming mail server.

In the mail itself, without parsing Received headers the only relevant headers are:

To: Anti-Spam Research Group - IRTF <[email-masked]>

So the only data I'd have to work with as a self-configuring plugin would be the IMAP server hostname, mail.wordtothewise.com.

> Agreed.  I suspect many MUAs are completely incapable of doing direct to MX, and don't do MX lookups.  See other suggestion, where I say "Use normal submit mechanism".

Yeah, the usual submit mechanism is the way to go for actually sending the reports.

But a critical bit of UI design is that it should be clear to the user whether something will happen, or not. So for this to be workable the MUA needs to be able to configure itself to show or hide the TiS button (or grey it out, or whatever UI idiom you like).

The charm of using an MX record to configure this is that the MUA can do an MX lookup to know whether to show or hide the button. That's pretty clean, and if I were coding an MUA I'd be happy to do it that way, but it's not necessarily a _trivial_ thing to add to a codebase, especially via plugin, so it's worth considering.

Cheers,
  Steve

---

From: Daniel Feenberg <[email-masked]>
Date: Fri, 5 Feb 2010 14:54:57 -0500 (EST)

On Fri, 5 Feb 2010, Chris Lewis wrote:

>> to support this feature, he doesn't have to. But if he does wish to support 
>> the feature he needs to supply an MX record or accept mail on the POP or 
>> IMAP server. Is that such a great burden? Compared to the other suggestions 
>> here?
>
> arf.domain.com alias to imap.domain.com.  If they're not, you don't have to 
> rename your mail infrastructure or screw around with forwarding on the imap 
> machine that you may have no control over.

Fine with me. But you really should learn about MX records - they are very 
useful and have been standardized for many years now.

Daniel Feenberg

---

From: Douglas Otis <[email-masked]>
Date: Fri, 05 Feb 2010 11:58:23 -0800

On 2/5/10 11:15 AM, Chris Lewis wrote:
>> The only setting that the MUA is likely to have access to is the name 
>> of the IMAP or POP3 server. As IMAP and POP3 are not name-based, the 
>> entry there could easily be domain.com, mail.domain.com, 
>> imap.domain.com or pop.domain.com or smtp.domain.com or even 
>> www.domain.com.
>
>> One option is to have the MUA "use some heuristic to find the 
>> 'domain' associated with that hostname", but past experience with SSP 
>> suggests that it makes people point and laugh at you and start 
>> mentioning things like imap.aardvark.us.com.
>>
>> Another would be to prepend "feedback." to the imap server name - so 
>> do an MX lookup for "feedback.imap.domain.com" to discover whether 
>> it's to enable the TiS button. That'll either need a DNS record added 
>> for every possible name for the IMAP server, or accept that it won't 
>> autoconfigure unless the recipient uses the name for the IMAP server 
>> you're expecting, either of which seems reasonable.
>>
>> (That doing MX lookups is not something that MUAs typically need code 
>> for, and that isn't supported by base API, is a minor issue but worth 
>> mentioning).
>
> Agreed.  I suspect many MUAs are completely incapable of doing direct 
> to MX, and don't do MX lookups.  See other suggestion, where I say 
> "Use normal submit mechanism".
It seems doubtful that any MUA will be able to properly determine 
origination's of a message without greater insight into their receiving 
administrative domain's architecture. Nor will Authentication-Results be 
bound to specific accounts once placed into a recipient's mailbox.  Any 
meaningful feedback, especially those related to source IP addresses, 
can only be emitted by the receiving administrative domain.  In 
addition, without some type of secured mechanism,  MUAs can not safely 
submit any end user feedback beyond their receiving administrative domain.

-Doug

---

From: "Chris Lewis" <[email-masked]>
Date: Fri, 5 Feb 2010 15:01:41 -0500

> Of those, the only thing that's actually associated with the inbound mailbox is the incoming mail server.

As you suggest, key it to "feedback@feedback.<incoming server name>".

> The charm of using an MX record to configure this is that the MUA can do an MX lookup to know whether to show or hide the button. That's pretty clean, and if I were coding an MUA I'd be happy to do…

 From the perspective of code base, checking for an A record for 
"feedback.<incoming server name>" would be simpler.  The MTA doesn't 
need to use DNS to deliver, and you really don't want the MUA to be 
establishing direct connections anyway.  Fixed route to whereever in the 
MTA.

---

From: Steve Atkins <[email-masked]>
Date: Fri, 5 Feb 2010 12:08:24 -0800

> As you suggest, key it to "feedback@feedback.<incoming server name>".

Yup.

> From the perspective of code base, checking for an A record for "feedback.<incoming server name>" would be simpler.  The MTA doesn't need to use DNS to deliver, and you really don't want the MUA to be establishing direct connections anyway.  Fixed route to whereever in the MTA.

So an A record for feedback.imap.example.com to demonstrate existence, and an MX record for the same to actually control delivery.

So the MUA can lookup the A record for feedback.imap.example.com to enable the TiS button, and when the TiS button is pressed it just sends email, using it's normal submission server, to [email-masked] or something like that, and the smarthost delivers that just as it would any other email.

If the MUA checks for the A record when fetching mail, rather than when displaying it, it'll all work when I'm on a plane too. Yay for store-and-forward!

Cheers,
  Steve

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 05 Feb 2010 12:25:59 -0800

> As you suggest, key it to "feedback@feedback.<incoming server name>".

This covers 3 specific choices, each of which ought to get a bit of discussion.

1. Mailbox name

There is an official list of required/standard email addresses:

    <http://www.ietf.org/rfc/rfc2142.txt>

We should make this exercise be an extension to that.  Offhand, 'feedback' 
strikes me as too generic, for what is actually a pretty specific function.

The existing, relevant reserved mailbox string is 'abuse'.  Should this new one 
be related to it?

2. Sub-domain

Why have a sub-domain?  And to the extent one is needed, why not use the 
developing convention of an underscore name, such as _report.<domain>?

The address to be used is really an 'attribute' of the main domain, and the 
underscore convention has developed as a way of defining additional attributes 
for a domain name.  In addition, the naming convention does not run the risk of 
colliding with an existing use of sub-domains.

3. Domain.

Clients currently have two domains to draw from, posting domain and pickup 
domain.  Choosing incoming probably /is/ best, because that's the place that 
handed the user the problem message and therefore it's the place that ought to 
provide the information about where to report problems.

>> The charm of using an MX record to configure this is that the MUA can
>> do an MX lookup to know whether to show or hide the button. That's
>> pretty clean, and if I were coding an MUA I'd be happy to do it that
>> way, but it's not necessarily a _trivial_ thing to add to a codebase,
>> especially via plugin, so it's worth considering.
>
> "feedback.<incoming server name>" would be simpler. The MTA doesn't need
> to use DNS to deliver, and you really don't want the MUA to be

Just to check:  The choice between using an A or an MX is an optimization, 
rather than strategic, yes?  That is, either is sufficient to the task, so a 
debate is about better?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Chris Lewis" <[email-masked]>
Date: Fri, 5 Feb 2010 15:39:34 -0500

> The existing, relevant reserved mailbox string is 'abuse'.  Should this new one 

That would be okay, but it shouldn't _be_ "abuse".  That's more for 
abuse originating locally, not that originating elsewhere.  We use 
"spam" for spam reporting ;-)

> developing convention of an underscore name, such as _report.<domain>?

Sub-domain because presumably you have incoming mail server already, and 
you don't want to standardize on something that will collide with 
existing infrastructure conventions.  Even if it's mail related.

> colliding with an existing use of sub-domains.

Problem with main domain is trying to figure out what it is, and it may 
not be the registered name.  east.sun.com and west.sun.com may have 
entirely separate infrastructures even if you could derive "sun.com" 
from "blat.for.be.sun.com".  So, it should at worst, be related to the 
naming of the infrastructure you actually use.

> rather than strategic, yes?  That is, either is sufficient to the task, so a 

There are some specific technical advantages to an A for existance 
(enable TiS button), and MX for routing (where submission server sends 
it).  Doing it that way around minimizes extra work, eg: many MUAs might 
not _have_ MX lookup code, but you know they have to have A lookup, so 
"A" is more convenient for what the MUA needs to do (light up the TiS 
button).  The MX makes MTA routing work perfectly sanely.  The A record 
doesn't even have to point at anything useful, because the MUA doesn't 
have to go there (and may not be able to), just exist.

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 05 Feb 2010 12:49:25 -0800

>> 2. Sub-domain
...
>> The address to be used is really an 'attribute' of the main domain,
>> and the underscore convention has developed as a way of defining
>> additional attributes for a domain name. In addition, the naming
>> convention does not run the risk of colliding with an existing use of
>> sub-domains.
>

Sorry for being confusing.  I didn't mean to invoke the long-standing issue of 
the 'core' domain for an organization.

I merely meant the domain name minus its 'attribute' qualifier.  For the 
proposal you guys are making, that would be /all/ of the domain name of the 
incoming host.

>> Just to check: The choice between using an A or an MX is an
>> optimization, rather than strategic, yes? That is, either is
>> sufficient to the task, so a debate is about better?
>

I missed the fact that this was merely a flag and that the IP Address wasn't 
relevant.

In that case, this should be a TXT record.

d/

-- 

   Dave Crocker

---

From: John Levine <[email-masked]>
Date: 6 Feb 2010 00:13:50 -0000

>Fine with me. But you really should learn about MX records - they are
>very useful and have been standardized for many years now.

Thanks, we're familiar with them.  Perhaps you might want to
familiarize yourself with section 5.1 of RFC 5321 which makes it quite
clear that MX records are still optional, and any host with an A or
AAAA record might be a mail domain.

This is what I meant about overloading names, in your case, turning
the host name of the POP or IMAP server into a mail domain.  Without
some other hack like feedback@feedback.<hostname> there's no way to
tell whether your mail host is prepared to accept feedback mail.

R's,
John

---

From: John Levine <[email-masked]>
Date: 6 Feb 2010 00:49:15 -0000

>imap.domain.com or pop.domain.com or smtp.domain.com or even

You know, this is the sort of thing that SRV records were invented to
do.

If the name of the POP or IMAP server is www.domain.com, you do a SRV
lookup and find:

 _arf._tcp.www.domain.com SRV 0 0 25 collectreports.biz

So, using a fixed mailbox name, the address is
[email-masked].  If there's no SRV record, they aren't
prepared to accept reports.

I'm not thrilled about this, since this enshrines the false assumption
that the only ways to pick up mail are POP and IMAP, but at least it
doesn't break anything that works now.

The other reason I'm not thrilled about it is that it assumes that an
MUA remembers where it found each message.  It's not unusual for
people to have multiple POP accounts, and to dump everything into one
local inbox.  There's no need to remember the source of each message,
so I wouldn't want to assume the MUA does so.  That's why I still
prefer something like a note in the Auth-results: header to tell you
where to send the report.  Belt-and-suspenders types might want to add
a SRV lookup to that to deter random hostile misdirection.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 05 Feb 2010 17:06:20 -0800

On 2/5/2010 4:13 PM, John Levine wrote:
> This is what I meant about overloading names,
...

Overloading indeed.

One of the benefits of the suggestion to use the regular posting mechanism is 
that it means that the MUA already knows how to post a message.  It does not 
need the IP Address of a server to post two.

Hence, there are only two possible pieces of information the MUA needs:

      1.  Is the function supported by the operator?

      2.  What address should be used for sending problem messages to, if we 
want to let operators choose their own address; this isn't needed at all if 
there is a global standard.

#1 is one bit of information.  There is no need for an A or MX, nevermind no 
need to debate between them.

#2 is an email address, which neither A nor MX support.

The design right choice, here is a TXT record, under an underscore subdomain.

d/
-- 

   Dave Crocker

---

From: John Levine <[email-masked]>
Date: 6 Feb 2010 01:13:23 -0000

>The design right choice, here is a TXT record, under an underscore subdomain.

What's wrong with a SRV record?  Then we can skip the moaning and groaning
from the DNS crowd about another overloaded TXT record.

R's,
John

---

From: Steve Atkins <[email-masked]>
Date: Fri, 5 Feb 2010 17:34:17 -0800

> from the DNS crowd about another overloaded TXT record.

+1. A TXT record is seldom the right design choice, despite the trail of badly
designed protocols that attempted to argue otherwise.

However...

The right hand side of a SRV record is a hostname, not an email address.

(Trivially worked around in at least two obvious ways).

Also, support for looking up SRV records is even rarer than TXT or MX.

Cheers,
  Steve

---

From: der Mouse <[email-masked]>
Date: Fri, 5 Feb 2010 20:36:02 -0500 (EST)

> One of the benefits of the suggestion to use the regular posting
> mechanism is that it means that the MUA already knows how to post a
> message.  It does not need the IP Address of a server to post two.

However, it assumes that the path for outgoing mail is related to the
path for incoming mail.  I, for example, occasionally get mail from
people whose incoming mail path has nothing, as far as I can see, to do
with their outgoing mail path except for sharing a human at the end of
them.  This is most visible when the person's address is at a mail
provider I don't accept any mail from, thus making it obvious the two
paths differ (because I wouldn't've gotten it if they didn't); I'm sure
there are lots more cases which I don't notice.

If the two paths are not related, then sending something to the
outgoing mail path won't have any effect on incoming mail handling.

Also, everyone's talking about POP and IMAP as if they were all there
is.  What about cases where the user's mailbox is accessed other ways?
Are they rare enough that we (FWVO "we") don't care about them?  As
sane as that often is, in this case I suspect it might not be, because
I suspect that being unusual in that respect and being a comparatively
valuable spam (and unwanted ham) reporter correlate positively, because
each of them correlates relatively strongly with being an
email-competent geek.  (This is admittedly a relatively baseless
suspicion; does anyone have any evidence bearing on its accuracy?)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 05 Feb 2010 17:48:39 -0800

> designed protocols that attempted to argue otherwise.

The recent trend towards using an _underscore.domain model has provided a 
scalable solution to the problem problem with TXT records, namely ambiguity.

> The right hand side of a SRV record is a hostname, not an email address.

right.

If all that's needed is a one-bit "i support the standard reporting address", 
that doesn't need an SRV, A, or MX.  If what's needed is an email address then 
that doesn't need any of those, either.

d/

-- 

   Dave Crocker

---

From: der Mouse <[email-masked]>
Date: Fri, 5 Feb 2010 20:48:10 -0500 (EST)

> (Trivially worked around in at least two obvious ways).

I don't see any obvious ways, unless you really mean "node in the DNS
tree" rather than "hostname".  Am I missing something?  It seems to me
that 2782 specifies that the target really is a hostname, thus making
it impossible to shoehorn an email address in there without (a)
imposing artificial restrictions on its local-part and (b) creating
artificial address records that do not actually make sense...or
ignoring SRV's spec, in which case the case for using SRV strikes me as
significantly weaker.

Of course, this could be finessed by the spec behind this use
(abuse, arguably, in view of its deviations from the spec) of SRV.

> Also, support for looking up SRV records is even rarer than TXT or

There's that.  But I can't really feel it's much of a barrier to anyone
who's gotten past the decision to implement anything even vaguely
TiSish in the first place.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 05 Feb 2010 18:14:51 -0800

On 2/5/2010 5:36 PM, der Mouse wrote:
> path for incoming mail.

Well, before I sent my first post on this, I considered that question, and I 
could argue it either way.  If the requirement is a trusted channel from MUA to 
the reporting mailbox, then yeah, an asymmetry is a problem.  Otherwise, it's ok.

> outgoing mail path won't have any effect on incoming mail handling.

Not quite.  The outgoing mail path is a posting agent, not a delivery agent. 
The /address/ specifies the delivery agent.  That's why this is an issue of 
trust, not routing.  Since the domain name or possibly full email address of the 
reporting destination is taken from the pickup host, there's no question that it 
points to the right place.  Hence, any valid posting server ought to be able to 
get the report there.  The problem is whether the reporting server /believes/ 
that the report is valid.

If there is a configuration asymmetry, then the report will come from outside 
the trust boundary.

> is.  What about cases where the user's mailbox is accessed other ways?

I think the latest round of discussion has eliminated any interest in the 
message retrieval mechanism.

-- 

   Dave Crocker

---

From: "BOBOTEK, ALEX (ATTCINW)" <[email-masked]>
Date: Fri, 5 Feb 2010 18:31:29 -0800

I don't see how this inherently ties the ARF server and/or ARF delivery
protocol(s)
to the mail access protocol (e.g., IMAP, POP, ...).  

A flexible reporting flow could work more like this:

*  MUA/User receive spam
*  MUA/User decide Report Recipient(s) they wish to report spam to
{sending ESP/ISP, receiving domain ESP/ISP, 
   Spam filter provider, SpamCop, and/or ...}.  This may involve header
analysis, which should be supported by 
   including feedback solicitation headers in email.
	* Possibly as a discovery process to support this decision, MUA
may discover available 
        reporting services' protocols and addresses for each Report
Recipient, using DNS (SRV or TXT?) queries if needed
*  Reports are sent using an available ARF submission protocol.  

To whom to report abuse is a can of worms.  For a given message, there
will never be a universally accepted answer.  
I don't see how it's reasonable to do anything except try to support the
range of possibilities.  

BTW, I work mostly with multi-protocol messaging systems (SMTP, SMS,
SIP, IM, MMS, IMAP, POP, proprietary wireless 
protocols, ...), where the complexity is even higher due to multiple
message types in addition to 
multiple (even layer 5 and higher) transport and delivery protocols.  In
these cases it may be impractical or 
inadvisable to use the access protocol as the abuse-report submission
protocol.
Maybe the above is more general than needed for email today.  But this
problem will become more complex as gateways
(such as Blackberry's or CP/M's, ...) become increasingly used.  

Regards,

Alex

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
John Levine
Sent: Friday, February 05, 2010 4:49 PM
To: [email-masked]
Subject: Re: [Asrg] Where to send the ARF report,was Adding a spam
button to MUAs

R's,
John

---

From: John Levine <[email-masked]>
Date: 6 Feb 2010 05:27:05 -0000

>message retrieval mechanism.

Um, this discussion has been about keying the ARF report to the name
of the POP or IMAP server, remember?

I pick up my mail through an SSH tunnel to my imap server, so my MUA
thinks the name of the server is localhost:2143.  I have no idea how
many people use MUAs picking up mail other than by contacting a named
POP or IMAP server, but the number is definitely greater than zero.

Some mail collection methods that break the all IMAP and POP theory:

* WebDAV (Outlook Express has used that to pick up Hotmail)

* Various sorts of tunnels that mask the address of the server 

* Reading the mail store via NFS

* Uucp or other batched delivery to a local mail store

R's,
John

---

From: John Levine <[email-masked]>
Date: 6 Feb 2010 05:30:02 -0000

>(Trivially worked around in at least two obvious ways).

Right.  I suggested using a fixed mailbox name, and there's always
the SOA hack

>Also, support for looking up SRV records is even rarer than TXT or MX.

I don't see any a priori reason to expect MUAs to be any worse at
looking up SRV than looking up TXT.  What does an MUA do now in normal
operation, as opposed to funky plugins, that needs TXT records?

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 05 Feb 2010 21:54:23 -0800

> of the POP or IMAP server, remember?

name of.

not protocols details of.

 > Right.  I suggested using a fixed mailbox name, and there's always

That's very Procrustean of you.

Given that the right hand side can be variable, why proscribe the left hand side 
when that's not necessary, when using a TXT record.

 > looking up SRV than looking up TXT.

What about:  TXT is older and pervasive?

The 'older' means exactly that its, ummmm, a priori...

 > What does an MUA do now in normal

Is there some reason this line of design debate is being based on theory rather 
than empirical knowledge?

Let's choose an inferior RR because it's just as likely to have been implemented 
as a more useful RR (that's been around longer)?

d/
-- 

   Dave Crocker

---

From: John Levine <[email-masked]>
Date: 6 Feb 2010 06:23:22 -0000

>> of the POP or IMAP server, remember?

But if you pick up the mail using something other than POP or IMAP,
there's no server and no name.

>What about:  TXT is older and pervasive?

SRV has been around for 15 years, and it's intended for telling you
where a domain provides a particular service, which is what we're
doing here.  Is there DNS software we care about that can support TXT
with a funny name but not SRV?

>Is there some reason this line of design debate is being based on
>theory rather than empirical knowledge?

I hope not.  If the age of the RR type is important, I would suggest
using HINFO, which was defined four years before TXT was.  If we agree
that's a silly distinction, why is TXT vs. HINFO silly, but SRV
vs. TXT is not?

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 05 Feb 2010 22:40:27 -0800

On 2/5/2010 10:26 PM, John R Levine wrote:
> One of my MUAs picks up its mail using IMAP from localhost:2143.  Another one
> reads a mailstore via NFS.  How do I configre them?

That level of site-specific local specialization needs site-specific local 
configuration capabilities for the reporting info, too.

> Can you explain more clearly what that better functionality is? We're looking
> for the place to send the ARF report, which both TXT and SRV do just fine.

I just know you saw:

> The right hand side of a SRV record is a hostname, not an email address.

TXT can support an email address.  An SRV can't.

And to the extent that there is any possibility of needing to encode other data,
TXT can support that (later) enhancement.

-- 

   Dave Crocker

---

From: Daniel Feenberg <[email-masked]>
Date: Sat, 6 Feb 2010 07:18:03 -0500 (EST)

> POP or IMAP server, but the number is definitely greater than zero.

This is easily overcome.

Make the ARF reporting address a configurable option, but default it to 
a role account at the email domain of the machine from which incoming 
mail is obtained. Surely if the user can tunnel their mail over ssh, they 
can configure the correct option (if they so desire) and if the MTA wishes 
to offer this service. This is a vanishingly small problem, in any case.

Note that the report goes to an email address, the MUA is expected to 
dispatch it using the usual MSA already configured for outgoing mail.

I understand that many POP/IMAP servers do not accept mail on the SMTP or 
MSA ports and there is nothing here to suggest that they should. Only that 
they have an MX record pointing to a machine that will.

The MTA operator is welcome to route the mail to any machine it prefers 
using the well established techniques for doing so. There is no need to 
invent any new procedures.

Surely the need here is for the MUA to communicate some information to the 
system that supplies it with incoming mail. Defaulting to a role account 
on that system surely covers the possibilities. If that system does not 
wish to receive email, then an MX record can divert it to another physical 
system. If it wishes to receive other mail, but not ARF reports, then why 
do ARF reports have this special need that no other role account has?

As to users being confused by MTAs that do not support the ARF reporting 
account and harassing the MTA operator, then perhaps that operator will
change his way, or at least null route that address.

Daniel Feenberg

---

From: John Levine <[email-masked]>
Date: 6 Feb 2010 14:34:22 -0000

>mail is obtained.

Now it's not opt-in by the mailstore provider.

R's,
John

---

From: "Chris Lewis" <[email-masked]>
Date: Sat, 6 Feb 2010 12:29:56 -0500

> Now it's not opt-in by the mailstore provider.

We need to have it self-configuring if the mailstore provides the 
service.  Which either means a standard role account for it, or, some 
way for the mailstore to tell the UA what address to use.

IOW: pure user configurable doesn't do that.

In-stream configuration (via MDA or MTA) would work, but it requires the 
MDA/MTA be modified.  Which we're avoiding.

We've been talking about using DNS for some of the signalling.  You 
could specify a "_report.<mailstore hostname>" TXT record that specifies 
the address (which isn't necessarily in the mailstore's domain) to send 
it _and_ its very existence shows that the mailstore provider supports 
the functionality (and thus the TiS button gets enabled).

Now, if the TXT record doesn't exist, we could suggest that the user 
could set their own abuse report destination.  But I'd rather not get 
into a situation where the user overrides the mailstore's explicit choice.

---

From: Michael Thomas <[email-masked]>
Date: Sat, 06 Feb 2010 09:43:17 -0800

Pardon me since I haven't been paying complete attention, but is there 
any assumption that the
mail store itself is the one that you'd be shipping these arf reports 
to? Given that a lot of them
are Exchange which typically have little to do with anti-spam, that 
wouldn't be a very good
assumption.

Mike, sorry if I'm restating the obvious

Chris Lewis wrote:
> John Levine wrote:
>>> Make the ARF reporting address a configurable option, but default it 
>>> to a role account at the email domain of the machine from which 
>>> incoming mail is obtained.
>>
> In-stream configuration (via MDA or MTA) would work, but it requires 
> the MDA/MTA be modified.  Which we're avoiding.
>
> could specify a "_report.<mailstore hostname>" TXT record that 
> specifies the address (which isn't necessarily in the mailstore's 
> domain) to send it _and_ its very existence shows that the mailstore 
> provider supports the functionality (and thus the TiS button gets 
> enabled).
>

---

From: John Levine <[email-masked]>
Date: 6 Feb 2010 17:55:24 -0000

>the functionality (and thus the TiS button gets enabled).

Right.  It would be a SRV record, but close enough.

I'm still worried about name overloading.  Never in the history of POP
or IMAP has the name of the server been anything other than a handle
to the the IP address to which to connect.  If your server has
multiple names, or no name, that has no effect on its operation.

Here's a concrete example, a customer of mine who uses the hosted mail
service at Tucows:

$ dig pop.philiphazan.com a

;; ANSWER SECTION:
pop.philiphazan.com.	294	IN	CNAME	mail.philiphazan.com.cust.a.hostedemail.com.
mail.philiphazan.com.cust.a.hostedemail.com. 3594 IN A 216.40.42.5

$ dig imap.philiphazan.com a

;; ANSWER SECTION:
imap.philiphazan.com.	300	IN	CNAME	mail.philiphazan.com.cust.a.hostedemail.com.
mail.philiphazan.com.cust.a.hostedemail.com. 3590 IN A 216.40.42.5

Their POP and IMAP servers have thousands of different names, one for
each hosting customer.  If we do a DNS hack, each of those thousands
of customers has to add something to its DNS.  If we do something
where the MDA adds a header, one software upgrade would make it work
for everyone.

This is a common way to set up a mail system for hosting services.  So
you tell me, which approach is "simpler"?

R's,
John

---

From: John Levine <[email-masked]>
Date: 6 Feb 2010 17:58:28 -0000

>Pardon me since I haven't been paying complete attention, but is
>there any assumption that the mail store itself is the one that you'd
>be shipping these arf reports to?

No, the plan is that whoever manages the mailstore tells you where to
send the report, which might or might not have some connection to a
POP or IMAP server.  I expect that in many cases, a mail system might
outsource the report handling to an aggregator.

R's,
John

---

From: Steve Atkins <[email-masked]>
Date: Sat, 6 Feb 2010 10:10:34 -0800

On Feb 6, 2010, at 9:29 AM, Chris Lewis wrote:

> John Levine wrote:
>>> Make the ARF reporting address a configurable option, but default it to a role account at the email domain of the machine from which incoming mail is obtained.
> We need to have it self-configuring if the mailstore provides the service.  Which either means a standard role account for it, or, some way for the mailstore to tell the UA what address to use.
> 
> In-stream configuration (via MDA or MTA) would work, but it requires the MDA/MTA be modified.  Which we're avoiding.

It requires the ability to add a header, for basic usage a constant header. That's a trivial configuration change, nothing more.

(And it avoids all the nasty heuristics people are discussing entirely, while providing way more flexibility).

> We've been talking about using DNS for some of the signalling.  You could specify a "_report.<mailstore hostname>" TXT record that specifies the address (which isn't necessarily in the mailstore's domain) to send it _and_ its very existence shows that the mailstore provider supports the functionality (and thus the TiS button gets enabled).
> 
> Now, if the TXT record doesn't exist, we could suggest that the user could set their own abuse report destination.  But I'd rather not get into a situation where the user overrides the mailstore's explicit choice.

Cheers,
  Steve

---

From: "John R Levine" <[email-masked]>
Date: 6 Feb 2010 01:26:48 -0500

> that just means that the operator needs to configure the report info record 
> for each domain name used for retrieval.
>
> that might or might not be more than one domain name, depending on how they 
> map names to services.

One of my MUAs picks up its mail using IMAP from localhost:2143.  Another 
one reads a mailstore via NFS.  How do I configre them?

> Age does not guarantee utility, and uptake on new RR's has been famously 
> problematic.
>
> But I'm really more interested in the better functionality of using TXT.

Can you explain more clearly what that better functionality is?  We're 
looking for the place to send the ARF report, which both TXT and SRV do 
just fine.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Michael Thomas <[email-masked]>
Date: Sat, 06 Feb 2010 11:10:58 -0800

> with a funny name but not SRV?

I think that the dkim/spf experience is that anything beyond A and CNAME 
causes
some dns providers out there to fail. Text does have the advantage that 
more providers
are supporting it because of dkim/spf. I don't think that srv has the 
same penetration and/or
use.... which is a pity because srv records are actually pretty nice in 
theory.

I'm not sure that it's an exact fit in any case with SRV, so you'd have 
to hack SRV just
like you'd have to hack TEXT records to fit the exact semantics, so it's 
sort of six of
one half dozen of the other on that front.

Mike

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 06 Feb 2010 11:40:54 -0800

> You know, this is the sort of thing that SRV records were invented to

SRV was invented to find a server address.

If the reporting mechanism is defined according to a standard TCP or UDP port, 
then SRV is a reasonable way to go.

If the reporting mechanism is defined according to an email address, then SRV 
does not provide enough information.

d/

-- 

   Dave Crocker

---

From: "Chris Lewis" <[email-masked]>
Date: Sat, 6 Feb 2010 14:43:31 -0500

John Levine wrote:

> each hosting customer.

They've already got the thousands of different names.  Adding a second 
to the DNS provisioning mechanism won't be that hard.  And it allows for 
having per-customer selections.

Alternately, or perhaps as a fallback, you could chain it.  Eg: Take the 
IP of your server (which you have to do already), get the PTR, prepend 
"_report", and do your configuration lookup on _that_ name (SRV or TXT).

I still think it a more general solution than hacking the MTA/MDA.

---

From: John Levine <[email-masked]>
Date: 6 Feb 2010 20:09:21 -0000

>to the DNS provisioning mechanism won't be that hard.

In case it wasn't clear, each customer sets up his own DNS and CNAME.
This means that if the mail provider adds this feature, they have to
contact several thousand resellers and get them all to update their
DNS.  I would characterize that as hard.

> And it allows for having per-customer selections.

Heck, a header added by the MDA allows per-message selections.

>I still think it a more general solution than hacking the MTA/MDA.

Could you explain why?  It strikes me as kludgy and fragile:

* It depends on two mail pickup schemes which, while popular, are not
  universal

* It depends on the MUA remembering the path of each message, which it
  need not do now for POP.

* It depends on the POP or IMAP server having a known name, which it
  doesn't now.  For example if I'm using your POP server, I might have
  my own CNAME or A record pointing at it that you don't even know
  about.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 06 Feb 2010 12:21:21 -0800

> DNS.  I would characterize that as hard.

You've postulated a particular, idiosynchratic operational environment with 
thousands of administers.  There's nothing "wrong" with that environment, but we 
need to be careful that we don't require that it's characteristics dictate 
design requirements for everyone.

Basically, with an environment of the sort you describe, everything is 
relatively more difficult.

While it's fine to try to design something so that it's scaling characteristics 
are /better/ than linear, but it's typically also acceptable for it to be linear.

d/
-- 

   Dave Crocker

---

From: "John R Levine" <[email-masked]>
Date: 6 Feb 2010 15:38:04 -0500

> thousands of administers.  There's nothing "wrong" with that environment, but 
> we need to be careful that we don't require that it's characteristics dictate 

Of course.  But what I've been hearing in this discussion is way too much 
of "that environment isn't like mine, so it's too exotic to worry about." 
A large mail hosting company with thousands of POP and IMAP customers 
should be the ideal environment for an MUA spam button, particularly since 
they already have a button in their web mail.  If we come up with 
something that they can't use, we've failed.

> relatively more difficult.

That hasn't been my experience.  They make all sorts of changes, but they 
don't make changes that require every reseller to change the DNS for every 
customer.

> While it's fine to try to design something so that it's scaling 
> characteristics are /better/ than linear, but it's typically also acceptable 
> for it to be linear.

I really don't understand all the resistance to a header applied by the 
MDA.  Yes, this will require a one-time change to the MDA, but you get a 
much more solid system that doesn't fail in mysterious ways when people 
have legitimate mail setups that happen to differ from the one the 
designer anticipated.  It's not unlike the advantage of DKIM over SPF.

Regards,

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 06 Feb 2010 12:50:15 -0800

On 2/6/2010 12:38 PM, John R Levine wrote:
>       A large mail hosting company with thousands of POP and IMAP
> customers should be the ideal environment for an MUA spam button,
> particularly since they already have a button in their web mail.

But the scenario you put forward is far more specialized that this description. 
  A "large mail hosting company that lets each of its customers configure domain 
names for their retrieval host" is pretty bloody unusual.

Offhand, your model seems to be confusing public domain names -- such as what 
others send email to -- from internal names, such as what is used between the 
hosting service and their direct clients.

Again, I'm not saying that the scenario you put forward is wrong or even a poor 
choice.  Merely that the more distributed the control, the more likely that 
changes to the operation will have a more distributed effect.

> don't make changes that require every reseller to change the DNS for
> every customer.

It's always nice to have scaling effects where massive increases in scale do not 
require significant increases in operations effort.  But it's not mandatory.

>> characteristics are /better/ than linear, but it's typically also
>> acceptable for it to be linear.
>
> MDA.

For one thing, it introduces a somewhat more complicated trust model, and 
probably introduces some undesireable security edge conditions.

> Yes, this will require a one-time change to the MDA, but you get a

"much more solid"???

> designer anticipated. It's not unlike the advantage of DKIM over SPF.

In fact it's quite similar, but the balance is different.  SPF merely requires 
an administrative act to participate on the 'sending' side.  This is hugely 
attractive.  (We'll ignore the fact that it involves the wrong address field.) 
The problem is the fragility of failing to handle multiple MTA hops.

Here', we have a direct -- single 'hop' -- trust-based relationship.  Much simpler.

d/
-- 

   Dave Crocker

---

From: Daniel Feenberg <[email-masked]>
Date: Sat, 6 Feb 2010 16:55:31 -0500 (EST)

On Sat, 6 Feb 2010, Chris Lewis wrote:

> John Levine wrote:
>>> Make the ARF reporting address a configurable option, but default it to a 
>>> role account at the email domain of the machine from which incoming mail 
>>> is obtained.
>> 
> We need to have it self-configuring if the mailstore provides the service. 
> Which either means a standard role account for it, or, some way for the 
> mailstore to tell the UA what address to use.

If a fixed role account is impossible, consider that dhcp already includes 
a standard way to distribute smtp, pop and imap host names, so adding the 
ARF reporting address wouldn't be completely out of character for dhcp. I 
don't know if any clients respect the dhcp MUA configuration data, though.

Daniel Feenberg

---

From: Daniel Feenberg <[email-masked]>
Date: Sat, 6 Feb 2010 17:03:05 -0500 (EST)

> you tell me, which approach is "simpler"?

1) If you have thousands of email domains, then perhaps they are generated
    mechanically, and a small change of code would create thousands of MX
    records.

2) There is always the wildcard, at least in Bind, which would make it a
    one line change.

3) The existence of a handful of sites where implementation would be work
    is hardly a reason to make additional works for millions of sites with
    a single domain.

4) The resistance to adoption will come chiefly from MUA vendors. MTA
    operators may be lax in using the information, but at least some
    of them will process the submissions. Getting even a single widely
    used MUA to adopt this would be a major accomplishment.

Daniel Feenberg

---

From: Daniel Feenberg <[email-masked]>
Date: Sat, 6 Feb 2010 17:11:25 -0500 (EST)

On Sat, 6 Feb 2010, Steve Atkins wrote:

> It requires the ability to add a header, for basic usage a constant 
> header. That's a trivial configuration change, nothing more.
>

Also the ability to delete conflicting headers.

Can you do delete headers in sendmail from the sendmail.mc file, or does 
it require the sendmail.cf file? Editing the later will be a challange to 
many small MTA operators. What about other MTAs?

Daniel Feenberg

---

From: "John R. Levine" <[email-masked]>
Date: 6 Feb 2010 17:34:40 -0500

> hosting service and their direct clients.

Sorry, I don't understand this.  Would you call the host name of the POP 
or IMAP server configured into the user's MUA a "public" or an "internal" 
name?  It hardly matters, since whichever it is, you cannot count on it 
being consistent or even known to the server operator.

Anyway, since this is supposed to be a research group, I did a little 
research to see what other mail hosting providers do:

Rackspace: use their name
Fusemail: per-domain CNAME
Everyone.net: use their name
Godaddy: unclear, examples all say "use your server name"
Yourdomainhost: use their name
runbox: use their name
host45.com: per-domain name (unclear whether CNAME or A)

It's certainly not universal to use per-domain names, but it's not an 
unusual edge case either.

> Here', we have a direct -- single 'hop' -- trust-based relationship.  Much 

And it has the same problem as SPF.  SPF is based on the false premise 
that all mail is sent directly from the originating to the receiving 
server, and the equally false premise that all mail is sent from servers 
managed by the owner of the bounce address domain (or, for Sender ID, the 
false premise that it's servers managed by the From: line domain.)

You're proposing a system based on the false premise that all mail is 
delivered via POP and IMAP, and the equally false premise that all POP and 
IMAP servers are referred to by a single name known to the server 
operator.

In both cases, although the premises are true often enough to be 
superficially plausible, they fail in significant numbers of cases, and 
when they do, you're stuck with ugly complex kludges, or you just give up.

The proposals for Authentication-Results: seem to have workable ways to 
detect fake headers.  What do they know that we don't?

R's,
John

---

From: John Levine <[email-masked]>
Date: 6 Feb 2010 22:54:18 -0000

>    mechanically, and a small change of code would create thousands of MX

Nope, they aren't.

>2) There is always the wildcard, at least in Bind, which would make it a

Could you give an example?  Keep in mind that your wildcard needs to
cover subtrees of several thousand arbitrary domains whose names you
don't know.

>    is hardly a reason to make additional works for millions of sites with

Could you provide pointers to data that show that a) most mail systems
handle a single domain, and b) there are millions of mail servers?  As
far as I know, neither of those are true.

>4) The resistance to adoption will come chiefly from MUA vendors.

Could you explain why that would be the case?  I believe the most
popular MUAs are Outlook, whatever Outlook Express is called these
days, and Thunderbird.  All have provisions for third party plugins,
so even if the vendors were opposed to providing a button (and I see
no reason to think they would be), that doesn't preclude providing
buttons anyway.

R's,
John

---

From: der Mouse <[email-masked]>
Date: Sat, 6 Feb 2010 18:20:21 -0500 (EST)

>>> [...TXT...]
>> [...SRV...]
> I think that the dkim/spf experience is that anything beyond A and
> CNAME causes some dns providers out there to fail.

So what?  No matter what we do, it will cause some providers to fail.
Heck, some of them fail without our doing anything at all.

If anything, this would be a good thing, in that it may lead to such
bustification getting fixed, much the way DKIM/SPF have (in the
evolutionary sense) exerted pressure against unsupport for TXT.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Michael Thomas <[email-masked]>
Date: Sat, 06 Feb 2010 16:38:35 -0800

> evolutionary sense) exerted pressure against unsupport for TXT.
I'm only reporting what we've seen. SRV is likely to be more problematic
because it's less common, but even TEXT isn't without issue.

Mike

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 06 Feb 2010 16:38:58 -0800

On 2/6/2010 2:34 PM, John R. Levine wrote:
>> Offhand, your model seems to be confusing public domain names -- such as
>> what others send email to -- from internal names, such as what is used
>> between the hosting service and their direct clients.
>
> Sorry, I don't understand this. Would you call the host name of the POP or
> IMAP server configured into the user's MUA a "public" or an "internal" name?

It's an internal name.

It's not for use by anyone out there in the open
Internet, the way an MX domain name is.  It's for use by clients with whom the 
operator has an established relationship.  That's internal.

 >   It hardly matters, since whichever it is, you cannot
> count on it being consistent or even known to the server operator.

Actually, it matters quite a lot.  Pre-arranged relationship vs. no prior
relationship carry masses of differences.  This becomes merely one more.

> research to see what other mail hosting providers do:

You left out yahoo, google, comcast, att, and the broad range of non-US-based
major ISPs.  I believe the list I just provided constitutes the vast majority of 
public mailboxes and I believe they all are "use their domain".

The fact that there is more than one provider that suits your scenario does not
automatically remove it from the edge.

And for reference, you are postulating that the DNS-based query is hugely
expensive for those providers using your scenario, but I'm not convinced that it 
does.

They have tailored software to support the scenario:  they have to, to get the 
name-and-address mappings and logins and permissions to all work.  There's a 
considerable administrative engine behind that scenario and I suspect that 
modifying that engine to support this additional function is a long, long way 
from onerous.

> And it has the same problem as SPF.

You appear to be postulating that the DNS query would fail.  Please explain how 
and in what cases.

DNS queries have significantly different characteristics from multi-hop email 
relaying, so I do not see how the problem SPF experience applies to a DNS query.

> IMAP servers are referred to by a single name known to the server operator.

(FWIW, I didn't propose this.  I'm merely supporting it...)

The proposal does not know or care about the retrieval protocol.  What it cares 
about is that the retrieval is based on access using a domain name.  If it has a 
domain name for retrieval, then this scheme is reasonable.

I suspect that the use of detached MUAs (thunderbird, outlook, etc.) based on 
Internet applications employs a domain name for something like six sigmas of the 
Internet user population (that uses MUAs.)

But FWIW, it's ok to specify a mechanism that works for "only" those folk who 
use POP or IMAP...

It's ok for a percentage of cases to need a different mechanism.

> detect fake headers. What do they know that we don't?

I'm not aware of its having enough experience to report back on the trust 
boundary enforcement issues.

I suspect when there is reasoned discussion based on experience, we'll also find 
some important differences in the architecture it is used within, differing in 
one or another important ways from the architecture this mechanism is being 
targeted for.

But perhaps not.

d/

-- 

   Dave Crocker

---

From: John Levine <[email-masked]>
Date: 7 Feb 2010 02:55:37 -0000

>You left out yahoo, google, comcast, att, and the broad range of
>non-US-based major ISPs.

Oh, sorry.  Here you go.  As a free bonus, I did Hotmail, too.  I'm
modestly (but not hugely) surprised that every one of these uses at
least one level of CNAME.  As you may recall, putting something at a
subdomain of a CNAME is rather naughty, so where do you plan to put
your TXT record?

$ dig pop.comcast.net a
;; ANSWER SECTION:
pop.comcast.net.	7200	IN	CNAME	mail.comcast.net.
mail.comcast.net.	900	IN	CNAME	mail.g.comcast.net.
mail.g.comcast.net.	300	IN	A	76.96.30.119

; AT&T DSL POP server
; the first CNAME is also the name used for Yahoo's own POP service
$ dig pop.sbc.yahoo.com a 
;; ANSWER SECTION:
pop.sbc.yahoo.com.	1798	IN	CNAME	pop.mail.yahoo.com.
pop.mail.yahoo.com.	598	IN	CNAME	pop.plus.mail.yahoo.com.
pop.plus.mail.yahoo.com. 298	IN	CNAME	pop.plus.mail.fy4.b.yahoo.com.
pop.plus.mail.fy4.b.yahoo.com. 300 IN	A	206.190.53.11

$ dig pop.aol.com a
;; ANSWER SECTION:
pop.aol.com.		3600	IN	CNAME	open.imap.aol.com.
open.imap.aol.com.	3600	IN	CNAME	open.gopen.imap.aol.com.
open.gopen.imap.aol.com. 4	IN	A	205.188.200.149

$ dig imap.aol.com a
;; ANSWER SECTION:
imap.aol.com.		501	IN	CNAME	open.imap.aol.com.
open.imap.aol.com.	3016	IN	CNAME	open.gopen.imap.aol.com.
open.gopen.imap.aol.com. 10	IN	A	64.12.168.246

$ dig imap.gmail.com a
;; ANSWER SECTION:
imap.gmail.com.		146	IN	CNAME	gmail-imap.l.google.com.
gmail-imap.l.google.com. 146	IN	A	74.125.93.109
gmail-imap.l.google.com. 146	IN	A	74.125.93.111

; POP for Google, also for Virgin.net, the largest cableco in the UK
$ dig pop.googlemail.com a
;; ANSWER SECTION:
pop.googlemail.com.	600	IN	CNAME	googlemail-pop.l.google.com.
googlemail-pop.l.google.com. 300 IN	A	74.125.91.16

; POP server for Hotmail
$ dig pop3.live.com a
;; ANSWER SECTION:
pop3.live.com.		2508	IN	CNAME	pop3.hot.glbdns.microsoft.com.
pop3.hot.glbdns.microsoft.com. 27 IN	A	65.55.32.247

; POP server for BT Internet, the largest ISP in the UK, with mail hosted by Yahoo
$ dig  mail.btinternet.com a
;; ANSWER SECTION:
mail.btinternet.com.	600	IN	CNAME	pop-smtp.bt.mail.yahoo.com.
pop-smtp.bt.mail.yahoo.com. 1800 IN	CNAME	pop-smtp.bt.mail.fy5.b.yahoo.com.
pop-smtp.bt.mail.fy5.b.yahoo.com. 300 IN A	217.12.13.134
pop-smtp.bt.mail.fy5.b.yahoo.com. 300 IN A	217.146.188.192

Here's two different domains at the largest ISP in France that use
different A records to point to the same set of POP servers.  I don't
know whether these are only names that customers use to refer to those
servers.  From what I've seen of France Telecom, I wouldn't count on
them knowing, either.

$ dig pop.orange.fr a
;; ANSWER SECTION:
pop.orange.fr.		514	IN	A	193.252.23.65
pop.orange.fr.		514	IN	A	80.12.242.8
pop.orange.fr.		514	IN	A	80.12.242.14
pop.orange.fr.		514	IN	A	80.12.242.51
pop.orange.fr.		514	IN	A	80.12.242.60
pop.orange.fr.		514	IN	A	80.12.242.90
pop.orange.fr.		514	IN	A	80.12.242.143
pop.orange.fr.		514	IN	A	80.12.242.149
pop.orange.fr.		514	IN	A	193.252.22.85
pop.orange.fr.		514	IN	A	193.252.22.90

$ dig pop.wanadoo.fr a
;; ANSWER SECTION:
pop.wanadoo.fr.		600	IN	A	80.12.242.8
pop.wanadoo.fr.		600	IN	A	80.12.242.14
pop.wanadoo.fr.		600	IN	A	80.12.242.51
pop.wanadoo.fr.		600	IN	A	80.12.242.60
pop.wanadoo.fr.		600	IN	A	80.12.242.90
pop.wanadoo.fr.		600	IN	A	80.12.242.143
pop.wanadoo.fr.		600	IN	A	80.12.242.149
pop.wanadoo.fr.		600	IN	A	193.252.22.85
pop.wanadoo.fr.		600	IN	A	193.252.22.90
pop.wanadoo.fr.		600	IN	A	193.252.23.65

>And for reference, you are postulating that the DNS-based query is
>hugely expensive for those providers using your scenario, but I'm not
>convinced that it does.

No, I'm pointing out that the DNS configuration would often be much,
much more complicated than adding a single TXT record per server, if
it's even possible to do, and is therefore much, much harder to get
right.

>You appear to be postulating that the DNS query would fail.  Please
>explain how and in what cases.

See many prior messages.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 07 Feb 2010 07:47:42 +0100

> It requires the ability to add a header, for basic usage a constant header. That's a trivial configuration change, nothing more.

If we're talking minimal changes, the other header-based approach, 
overloading the existing Autherntication-Results, requires no 
MDA/MTA modifications.

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 07 Feb 2010 09:25:52 +0100

Michael Thomas wrote:
> I think that the dkim/spf experience is that anything beyond A and CNAME causes
> some dns providers out there to fail. Text does have the advantage that more providers 
> are supporting it because of dkim/spf. I don't think that srv has the same penetration 
> and/or use.... which is a pity because srv records are actually pretty nice in 
> theory.

Using SRV records would be consistent with similar email 
auto-configuration records defined in 
http://tools.ietf.org/html/draft-daboo-srv-email

It may be worth to note that such automatic configuration 
specification is arriving after years of manual configuration 
experience. Yet, it does not provide for automatically enabling the 
A-R field defined by RFC 5451 which, for security reasons, requires 
its field to be ignored "unless specifically enabled by the user or 
administrator after verifying that the border MTA is compliant". 
Possibly, such MTA compliance will eventually be flagged using DNS 
RRs as well, but A-R is not yet a widely deployed field.

Seeking auto-configuration for TiS buttons apparently clashes with 
the experience summarized above. Alex has described how flexible 
reporting flow could work, in a recent message. His description 
resembles the way spam complaints have been produced for many years. 
However, the reason why we want TiS buttons is that the volume of 
spam is so high that we cannot keep its pace unless we automate 
reporting. Even then, why do we want the mechanism for automatic 
reporting to also be automatically configurable?

The possible reasons that I can think of are as follows:

* users cannot determine whether their mailbox providers support
   spam reporting,

* MUAs cannot determine which is the last report-supporting MTA, if
   any, that received a given inbound message,

* most users already gave up reporting spam and won't resume unless
   presented with a fully automated tool, won't even go to the
   trouble of configuring it, or

* the reporting address isn't really fixed, and may vary without
   advice, independently of any other mailbox parameter.

Are there more? And which ones are more relevant?

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 08 Feb 2010 11:43:05 +0000

--On 5 February 2010 10:52:51 -0500 Daniel Feenberg <[email-masked]> 
wrote:

>>> I don't understand why this is relevant. If the MTA operator doesn't
>>> want to support this feature, he doesn't have to. But if he does wish to
>>> support the feature he needs to supply an MX record or accept mail on
>>> the POP or IMAP server. Is that such a great burden? Compared to the
>>> other suggestions here?
>>

No, the argument is nothing to do with the left hand side of the address, 
it's to do with the right hand side of the address. "imap.iecc.com" isn't 
an email domain, but it might be one day. "imap.sussex.ac.uk" is not an 
email domain, and it never will be.

In the case where the imap server host name does happen to be an email 
domain, there's a potential name space conflict. ARF@... may well already 
be taken. Clearly there's a possibility for an untaken address to be 
advertised in DNS, or as a property of the server in the POP3 or IMAP 
protocols. IMAP has a suitable extension already, but a special TXT record 
in the DNS would be the most likely option. But would that be advertised by 
the DOMAIN operator, or by the server operator. They're the same (the 
University) for my work domain, but different (me or Gmail) for my personal 
domain.

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 08 Feb 2010 11:50:26 +0000

> AAAA record might be a mail domain.

Which is a real shame. It would be very nice to assume that a domain 
without an MX record isn't an email domain. Too late for A records, but for 
AAAA records....

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 08 Feb 2010 12:00:43 +0000

> designer anticipated.  It's not unlike the advantage of DKIM over SPF.

If I see a message that I think is spam, and it carries a "report-abuse-to" 
header, how do I know that the header was added by the MDA and not by the 
spammer?

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 08 Feb 2010 12:22:30 +0000

> all mail systems are, or should be, just like the mail system they

I'm not making that assumption. I'm simply claiming that the problem isn't 
a single problem (1. "how to report junk messages"). It's two problems: "2. 
how to report junk messages to an IMAP mailstore operator" and "3. how to 
report junk messages to a POP mailstore operator".

I think that there's a simple, efficient, and elegant solution for 2 
(IMAP), that isn't available for 3 (POP).

It may be that a simple, efficient, and elegant solution is available for 
POP. After all, the DELE command uses a message-id argument, so it's 
possible to flag specific messages as deleted, and therefore would not be 
beyond the bounds of possibility to extend POP to permit flagging of junk 
messages.

In both cases, it would not be necessary to download more than the message 
headers in order to file a report. With ARF, you have to download the full 
body if you hope to forward the report.

By solving both the problems with a one-size-fits-all proposal, we're 
looking at a solution that strike me as pretty rubbish for both (especially 
on a narrow-bandwidth connection).

---

From: Daniel Feenberg <[email-masked]>
Date: Mon, 8 Feb 2010 07:49:26 -0500 (EST)

On Mon, 8 Feb 2010, Ian Eiloart wrote:

> it's to do with the right hand side of the address. "imap.iecc.com" isn't an 
> email domain, but it might be one day. "imap.sussex.ac.uk" is not an email 
> domain, and it never will be.
>
> domain, there's a potential name space conflict. ARF@... may well already be

"Cnflict, ARF@" is the left hand side of the address. If imap.iecc.com 
becomes an email address, then it would be a mistake to assign a user the 
username of "arf".

If a role account is assigned to [email-masked] then it 
is a problem if that address is already assigned to a user. It isn't a 
problem with no solution, though. Simply make sure that the RHS of the 
address is different from the already assigned address. This is almost 
always going to be the case for large providers, since machines for pop 
and imap service are distinct from email domain names. If they do not, it
is simple enough to arrange DNS to make that happen, without changing any 
hardware.

Perhaps another character string would lessen the objection on this point. 
The role account could be "arf-submission", although the anti-English 
crowd will complain. There is room for creativity.

Note that when I say "pop_or_imap" it doesn't really have to be restricted 
to those protocols. The MUA can use the hostname for the system providing 
incoming mail, without caring what protocol is actually used, nor is there 
any need for the letters "pop" or "imap" to be requed to be in the name. 
The TO: address ued for the ARF is simply the role account on the system 
providing mail, that will use it to tune content or other spam filters.

Daniel Feenberg

---

From: "Peter J. Holzer" <[email-masked]>
Date: Mon, 8 Feb 2010 14:33:54 +0100

On 2010-02-08 12:00:43 +0000, Ian Eiloart wrote:
> If I see a message that I think is spam, and it carries a 
> "report-abuse-to" header, how do I know that the header was added by the 
> MDA and not by the spammer?

In general you don't. But I don't see that as a particularly bad
problem: The worst a spammer can do is a DDoS attack on a small ESP by
adding a Report-Abuse-To header with the abuse address of that ESP.
That doesn't seem much worse to me than what they can already do by
simply using that address in the sender (which will cause bounces and
complaints to be sent to that address).

If there is a Report-Abuse-To header, I would suggest that it is handled
like this:

A Report-Abuse-To header may be added by any MTA or MDA.

    Rationale: This allows ESPs (especially big freemail providers like
    gmail, yahoo, gmx) to tag outgoing mails with an abuse address.

Any MTA or MDA which adds Report-Abuse-To header MUST prepend it to the
message (just like a Received header).

    Rationale: This provides ordering among Report-Abuse-To headers:
    The first one is the newest and it was added by the MTA which added
    the Received header immediately after it:

	Received: by A from B
	Report-Abuse-To: X
	Received: by B from C
	Received: by C from D
	Report-Abuse-To: Y
	Received: by D

    Assuming that none of the lines was faked, Report-Abuse-To: X was 
    added by B, and Report-Abuse-To: Y was added by D. Anything outside
    your MX is suspect (for example C may be a spammer) but may still be
    useful.

A MUA SHOULD send an abuse report to the address of the first
Report-Abuse-To header it finds.

    Rationale: This is the one which was added last, i.e., closest to
    the recipient - it is therefore most likely to be relevant and least
    likely to be failed.

A MUA MAY do some plausibility checks and warn against sending the
report.

    Rationale: The Report-Abuse-To header may be faked. Analysis of the 
    Received headers may be able to detect the fake, but this is tricky
    and error-prone, so the result of this analysis should only be
    offered as advice.

If there is more than one Report-Abuse-To header, the MUA MAY offer to
send a report to each of them.

    Rationale: If an ESP adds Report-Abuse-To to their outgoing mail,
    they obviously want to be notified about abuse and they can even do
    something about it (e.g., terminate the spammer's account). OTOH,
    you don't know who added the the header, so this should also be
    viewed with some suspicion.

A report handling agent may forward the report if it finds an "upstream" 
Report-Abuse-To header.

    Rationale: As above. The report handling agent may have better
    information about the legitimacy of upstream Report-Abuse-To headers
    than the MUA (or user).

It may be possible to use DKIM (or something similar) to prevent forged
Report-Abuse-To headers, but I haven't thought about this yet.

	hp

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 08 Feb 2010 14:38:05 +0000

--On 8 February 2010 07:49:26 -0500 Daniel Feenberg <[email-masked]> 
wrote:

>> No, the argument is nothing to do with the left hand side of the
>> address,  it's to do with the right hand side of the address.
>> "imap.iecc.com" isn't an  email domain, but it might be one day.
>> "imap.sussex.ac.uk" is not an email  domain, and it never will be.
>>

Yes, you're confusing the two cases. Either the domain is already an email 
domain (in which case a conflict is possible), or it isn't (in which case 
you're asking for creation of an email domain merely to deliver abuse 
reports). That then becomes a whole new domain without reputation which 
spammers can abuse.

> Perhaps another character string would lessen the objection on this
> point. The role account could be "arf-submission", although the
> anti-English crowd will complain. There is room for creativity.
>
> Note that when I say "pop_or_imap" it doesn't really have to be
> restricted to those protocols. The MUA can use the hostname for the
> system providing incoming mail, without caring what protocol is actually
> used, nor is there any need for the letters "pop" or "imap" to be requed
> to be in the name. The TO: address ued for the ARF is simply the role
> account on the system providing mail, that will use it to tune content or
> other spam filters.
>
>
> Daniel Feenberg

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 08 Feb 2010 14:50:13 +0000

> complaints to be sent to that address).

Except that that doesn't happen much these days. The number of bounces that 
I see into my domain is very small compared with even a year ago. What 
you're suggesting here would revive that problem in a new form.

Given that most domains won't immediately deploy this mechanism, my guess 
is that the amount of abuse will exceed the amount of use. I'll be hoping 
that clients won't deploy the mechanism at all.

Administrators will simply advise people to NOT use the junk mail button 
for exactly the same reasons that we advise people NOT to reply to spam.

In fact, my first action will probably be to configure my mail server to 
remove the abuse-report header on inbound, outbound, and forwarded email. 
Will I add an abuse-report header of my own? Probably not, because that'll 
mean (currently) creating a new email domain to collect the reports, trying 
to work out a way of filtering the reports from the spam that reaches the 
same address. And then doing something with the reports.

Probably I won't accept reports on my MX server - there won't be an MX 
record for the domain for that reason. I might permit my SUBMIT server to 
deliver the messages somewhere. But, really, I'd rather the MUA just set a 
junk flag on the imap server.

---

From: John Levine <[email-masked]>
Date: 8 Feb 2010 14:59:17 -0000

>without an MX record isn't an email domain. Too late for A records, but for 

Believe me, I tried when they were working on 5321, but was roundly
shouted down, evidently because the handful of existing MTAs on
IPv6 make it "too late" to change.

R's,
John

---

From: Bart Schaefer <[email-masked]>
Date: Mon, 08 Feb 2010 07:08:22 -0800

On Feb 8,  2:33pm, Peter J. Holzer wrote:
} Subject: Re: [Asrg] We really don't need no stinkin IMAP or POP foram	butt
}
} 
} On 2010-02-08 12:00:43 +0000, Ian Eiloart wrote:
} > If I see a message that I think is spam, and it carries a 
} > "report-abuse-to" header, how do I know that the header was added by the 
} > MDA and not by the spammer?
} 
} In general you don't. But I don't see that as a particularly bad
} problem: The worst a spammer can do is a DDoS attack on a small ESP by
} adding a Report-Abuse-To header with the abuse address of that ESP.

I'd say the worst they can do is to direct the abuse report back to
themselves.  This not only suppresses some fraction of their spam
complaints, but it also confirms valid email addresses and may reveal
information about what MUA is in use, which in turn can be used to
refine the next spam or exploit that they direct to that address.

---

From: John Levine <[email-masked]>
Date: 8 Feb 2010 15:29:58 -0000

>you're suggesting here would revive that problem in a new form.

As Steve noted, very few people press the spam button.  It's not a very
effective way to mailbomb people.

>remove the abuse-report header on inbound, outbound, and forwarded email. 

Outbound I suppose, but why inbound or forwarded?  Stuff that survives
your spam filters is considerably more likely to be from a real sender
than random spam.  And what possible benefit is there to removing a
forwarder's AR?  You want them to filter their spam better, don't you?

>same address. And then doing something with the reports.

Why do you think you can't just set up an address in an existing domain
for the reports and put it in the AR header?  The idea of overloading
the server name as a mail domain was a mistake that we're not doing.

R's,
John

---

From: John Levine <[email-masked]>
Date: 8 Feb 2010 15:33:59 -0000

>refine the next spam or exploit that they direct to that address.

A spammer might collect complaints and listwash, which would mean that
the complainant gets less spam.  I hope we agree that's the goal.

If a spammer wants to confirm receipt, which very few of them do,
he uses web bugs.  I suppose info about the MUA might be marginally
useful, but if I were a spammer and knew that a recipient was
sufficiently annoyed to press the spam button, I'd take them off the
list.  I still have millions of other people to mail to, after all.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 08 Feb 2010 16:44:18 +0100

On 08/Feb/10 13:22, Ian Eiloart wrote:
> [...] I'm simply claiming that the problem
> isn't a single problem (1. "how to report junk messages"). It's two
> problems: "2. how to report junk messages to an IMAP mailstore operator"
> and "3. how to report junk messages to a POP mailstore operator".

Ian, it seems to me that your feeling for problem #2 causes a 
misrepresentation of problem #3. I'd express them as

   Problem A: report spam for complaining (was #3)

   Problem B: tune servers' filters (was #2)

I don't think it's useful to try and solve both of them at the same time.

---

From: Seth <[email-masked]>
Date: Mon, 8 Feb 2010 11:42:37 -0500 (EST)

John Levine <[email-masked]> wrote:

> If a spammer wants to confirm receipt, which very few of them do, he
> uses web bugs.  I suppose info about the MUA might be marginally

But I'd also sell his email address as a "known to exist, known to
look at spam" one :-(

Seth

---

From: Bart Schaefer <[email-masked]>
Date: Mon, 08 Feb 2010 09:44:11 -0800

On Feb 8,  3:33pm, John Levine wrote:
}
} If a spammer wants to confirm receipt, which very few of them do,
} he uses web bugs.  I suppose info about the MUA might be marginally
} useful, but if I were a spammer and knew that a recipient was
} sufficiently annoyed to press the spam button, I'd take them off the
} list.  I still have millions of other people to mail to, after all.

And what if you were not a spammer, but a phisher?

---

From: Steve Atkins <[email-masked]>
Date: Mon, 8 Feb 2010 09:46:38 -0800

> And what if you were not a spammer, but a phisher?

Much the same, as someone who knows that
the mail I'm sending is bogus is not an interesting phish target (heck,
someone who has a TiS button and isn't afraid to use it isn't
an interesting phish target).

Cheers,
  Steve

---

From: "Chris Lewis" <[email-masked]>
Date: Mon, 8 Feb 2010 12:54:23 -0500

Ian Eiloart wrote:
> I'm not making that assumption.

By insisting on MDA-specific methods, it forces the same result as 
making the assumption that all the world is IMAP (+ POP or whatever 
other protocol we deign to notice).  It isn't.

> I'm simply claiming that the problem isn't 

Four: SMTP
Five: Webmail
Six: Microsoft RPC

etc.  We use all five.  Actually more, but, those are very much in the 
weeds.

There is no need to make it MDA specific, everything you can do with 
direct MDA feedback you can do with asynchronous MDA-independent methods.

Someone else seemed to imply that there's an inherent difference between 
"reporting for complaint handling" and "forwarding for filter tuning", 
and MDA-specific methods can only handle the latter.

Nothing could be further from the truth.  We do both, via non-MDA-based 
feedback.

While it might be a bit more convenient for some installations to tune 
_some_ kinds of filters directly with direct MDA submissions, in many if 
if not most cases it makes no difference because it isn't the MDA doing 
the filtering, and there's no reason that a non-MDA reporting 
destination can't adjust the MDA if it actually needs to.

Indeed, tuning MDAs directly (and independently) can introduce severe 
operational inconsistencies and manageability problems.

If we want acceptance of this, we need to make it as universal and 
technology independent as possible.

IOW: while MDA-specific mechanisms can sometimes make part of what 
you're doing a bit simpler, there's nothing that MDA-specific can do 
that MDA-independent can't, and MDA-independent is vastly more 
universally applicable.  Especially in mixed environments.

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 08 Feb 2010 18:55:08 +0100

On 08/Feb/10 17:42, Seth wrote:
> John Levine<[email-masked]>  wrote:

That's the risk we run when _mis_directing ARs. It can be minimized by 
choosing a header that MTAs are aware of and actively zap unless 
trusted, just like the A-R field of rfc 5451. Possible alternatives 
may be to

1. use 5451's authserv-id,
2. create an A-R's extension, or
3. create a brand new header field.

(I'd never go for #3, to avoid duplicating specs. #1 seems good to me, 
as I'm not aware of conflicts with existing deployments.)

Sooner or later we'll have to discuss how MTAs would route ARs in 
order to avoid bad recipients, and this question will be even more 
relevant at that point.

---

From: "Chris Lewis" <[email-masked]>
Date: Mon, 8 Feb 2010 13:36:57 -0500

> 3. create a brand new header field.

I've been glancing at RFC5451, and beginning to realize that 
"destination discovery" by out-of-band methods will make the MUA's job 
quite confusing in the case of multiple MDAs.  How better to direct it 
to the right place if the MDA (or incoming border MTA) can specifically 
identify where the reports should go, in-band?

[Yes, I think I've flip-flopped again :-(]

Could we not do this by extending 5451 semantics to have a "where to 
complain to" cause?

I note that 5451 specifically talks about/permits stripping of upstream 
Authentication-Results:, both where the MTA figures it's being spoofed, 
or simply all upstream at gateways or others as policy dictates.

MUAs could merely take the most recent AR headers that have the 
appropriate complain-to fields.  Exposure is limited to MUAs that will 
do this on MTA/MDAs that haven't done anything about AR headers and 
doesn't insert one of their own.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 08 Feb 2010 10:52:48 -0800

> from the DNS crowd about another overloaded TXT record.
Agree.  The SRV record can even prioritize desired servers, and 
reference third-party service providers who might specialize in 
mitigating 0wned accounts, for example.  The SRV record appears ideal 
for this type of application.  Even Bonjour adopted the SRV service 
naming strategy, so why reinvent the wheel?

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 8 Feb 2010 11:11:36 -0800

> Chris Lewis
> Sent: Monday, February 08, 2010 10:37 AM
> To: Anti-Spam Research Group - IRTF
> Subject: [Asrg] RFC5451 Re: who gets the report, was We really don't
> need
> 

That might work, if there's a reliable way to get that information and relay it to MUAs.

Are you talking about an internal destination for spam reports (e.g. your IT group), or an external one (e.g. abuse@domain)?

---

From: Seth <[email-masked]>
Date: Mon, 8 Feb 2010 14:31:06 -0500 (EST)

Steve Atkins <[email-masked]> wrote:

> Much the same, as someone who knows that the mail I'm sending is
> bogus is not an interesting phish target (heck, someone who has a
> TiS button and isn't afraid to use it isn't an interesting phish
> target).

Why not?  He clearly needs a better quality phish, but at least he's
alive and reading spam.

Seth

---

From: "Chris Lewis" <[email-masked]>
Date: Mon, 8 Feb 2010 15:14:39 -0500

> That might work, if there's a reliable way to get that information and relay it to MUAs.

It's a header in the email, so, and I think most thick clients (suitable 
for implementing the sending of a report) will already have it. 
Webmails, for example, would implement it server-end not (directly) in 
the browser.

> Are you talking about an internal destination for spam reports (e.g. your IT group), or an external one (e.g. abuse@domain)?

Either.  If you have an AR header you trust, there's no reason to refuse 
it giving you an external destination.  Question is, how do we tell it's 
trusted, or do we care (especially with a site that's not 5451 aware)?

If we pitch it towards RFC5451-aware sites, and they pre-strip all 
non-locally originated AR headers (as permitted by RFC5451), there's no 
issue.  Are the sites that won't be a big enough concern?  Dunno.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 8 Feb 2010 12:48:38 -0800

> Sent: Monday, February 08, 2010 12:15 PM
> Subject: Re: [Asrg] RFC5451 Re: who gets the report, was We really
> don't need
> 
> It's a header in the email,

Which one?

> > Are you talking about an internal destination for spam reports (e.g.
> > your IT group), or an external one (e.g. abuse@domain)?
> 
> it giving you an external destination.

Where would you get the external destination to be reported to MUAs?

> Question is, how do we tell
> it's

I think you've answered it; an RFC5451-aware site would include that field only if it's convinced the value it's thus reporting is correct, having gotten it from some new parameter in a DKIM signature or something like that.  Otherwise it would report "abuse@(self-domain)", or nothing at all.

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 09 Feb 2010 11:44:35 +0000

--On 8 February 2010 15:29:58 +0000 John Levine <[email-masked]> wrote:

>> Except that that doesn't happen much these days. The number of bounces
>> that  I see into my domain is very small compared with even a year ago.
>> What  you're suggesting here would revive that problem in a new form.
>

They don't? Well, very few people have a spam button to press. We're hoping 
to change that, aren't we? At least, to open up the possibility that a lot 
more people will have a spam button to press.

Of course, if spam reports are going to innocent third parties, then we'll 
hope you're correct.

> forwarder's AR?  You want them to filter their spam better, don't you?

Why inbound? Because I don't want my users sending spam reports to third 
parties based on a header in the spam message. I want them to send the spam 
reports to me. I guess I might make an exception for gmail if the message 
carries a valid DKIM score. But I certainly won't let these headers survive 
unless there's either an SPF pass or a valid DKIM header.

>
>> Will I add an abuse-report header of my own? Probably not, because
>> that'll  mean (currently) creating a new email domain to collect the
>> reports, trying  to work out a way of filtering the reports from the
>> spam that reaches the  same address. And then doing something with the
>> reports.
>

OK, if you're not doing that, then that's fine. I'd be much happier with an 
address in my existing domain, but not a standard address. It has to be one 
that I can choose. It won't accept mail through my MX servers, though. If 
the SMTP submission isn't authenticated, then I won't have any reason to 
believe it's a valid report.

Even then, I'd still rather simply have a flag set in my IMAP server. I 
don't want reports about messages that I never delivered to the mailbox. I 
don't want reports that carry munged copies of the original message. And, I 
don't want users to have to download messages with malware payloads simply 
to report them. I'd like a user to be able to select a number of messages 
and mark them as junk, without having to download them. I don't want them 
running up large mobile bandwidth bills just to report spam. I don't want 
their clients initiating time or cash costly transactions for the mail that 
the users least want to download.

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 09 Feb 2010 11:52:32 +0000

> trusted, or do we care (especially with a site that's not 5451 aware)?

Yes, we care. Most servers aren't going to add this information. Most of 
the time, it will be provided by the spammer. If clients are going to do 
something with the information, it must be trusted.

Could the MDA add a DKIM signature for the authentication results header?

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 09 Feb 2010 11:58:03 +0000

> an interesting phish target).

I've seen one case where a phishing target responded to the message saying 
"but you keep telling me not to share my password". The phisher responded 
saying "yes, usually we do that, but in this case we really need it". The 
target gave up her password after a couple more exchanges. The phisher 
worked really hard to get that account, which was then used to send more 
phish.

I see a similar scenario like this: target hits TiS button; report goes to 
phisher; phisher replies saying, "no honestly we really need this 
information" in a message that's even more convincing because it's pulled 
additional information from the report (like the user's real name from the 
"From" header, and job title from a sig); target yields password.

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 09 Feb 2010 12:00:36 +0000

--On 8 February 2010 14:59:17 +0000 John Levine <[email-masked]> wrote:

>> without an MX record isn't an email domain. Too late for A records, but
>> for  AAAA records....
>

Do you think a political campaign that resulted in - say - all UK 
educational establishments, or all .gov.uk domains (or both) implementing 
such a rule would change their minds? What if Google also implemented the 
rule.

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 09 Feb 2010 12:08:53 +0000

> I don't think it's useful to try and solve both of them at the same time.

I'm completely confused by this message. I really don't understand at all 
what it is that you're saying. Problem B is about how you handle reports 
once you have them. I don't understand what "Problem A: report spam for 
complaining" means at all.

Are you saying that POP3 managers will process reports differently than 
IMAP managers will? My guess is that the value of the reports will be 
similar, and the actions taken as a result will be similar. Whether POP or 
IMAP, the actions to take might include tuning filters; passing complaints 
back down the delivery path; feeding local or shared reputation services, 
etc.

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 09 Feb 2010 12:21:12 +0000

--On 8 February 2010 12:54:23 -0500 Chris Lewis <[email-masked]> wrote:

> By insisting on MDA-specific methods, it forces the same result as making
> the assumption that all the world is IMAP (+ POP or whatever other
> protocol we deign to notice).  It isn't.
>
>> a single problem (1. "how to report junk messages"). It's two problems:
>> "2.  how to report junk messages to an IMAP mailstore operator" and "3.
>> how to  report junk messages to a POP mailstore operator".
>
> Four: SMTP

You use SMTP to retrieve messages from a mailstore? No, I guess you mean 
that you want to be able to send a report to the operator who forwarded 
spam to your primary mail account. I provide a forwarding service, but if 
the message isn't stored on my system, then I'm not going to trust the 
report. One thing that I know about email that I've forwarded is that it 
doesn't look like the message that I saw originally.

This is already a different problem.

> Five: Webmail

We have a webmail service. It's an IMAP mail client. If yours isn't, then 
the question is "can it flag messages" in the same way that an IMAP client 
can? If it can, then an IMAP flag-like solution could be implemented in the 
client.

> Six: Microsoft RPC

You mean Exchange clients? They also have different problem. For example, 
they haven't preserved the RFC5322 headers properly.

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 09 Feb 2010 15:58:40 +0100

> Could the MDA add a DKIM signature for the authentication results header?

Yes, it could. However, removal of the field on forwarding would then 
break the signature.

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 09 Feb 2010 16:56:33 +0100

On 09/Feb/10 13:08, Ian Eiloart wrote:
> --On 8 February 2010 16:44:18 +0100 Alessandro Vesely <[email-masked]> wrote:
> I'm completely confused by this message. I really don't understand at
> all what it is that you're saying. Problem B is about how you handle
> reports once you have them. I don't understand what "Problem A: report
> spam for complaining" means at all.

Problem B imposes a tight matching between where the original message 
has been filter and where the report is going to be handled. In 
addition, it needs both spam and ham info. Since the main purpose of 
server-based (as opposed to client-based) filtering is to save 
bandwidth, efficiency is a relevant concern.

Problem A has a somewhat wider horizon, as it assumes that reported 
spam may be routed through some trust-chained operators, possibly 
reaching the author of the original message. Although the report may 
also be used for tuning or assessing anti-spam filters, its main 
purpose is to affect the source of the original message. This is a 
generalization --and regularization-- of the FBLs currently used 
between giant mailbox providers and ESPs. My expectation is that it 
will result in important advances in the collective understanding of 
spam, so that massive abuse reporting will not be needed forever. In 
the latter respect, relatively inefficient (inelegant) procedures may 
be acceptable, if they widen the chances of adoption.

Hope this clarifies my point, sorry for the unintended confusion.

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 09 Feb 2010 16:31:46 +0000

--On 9 February 2010 16:56:33 +0100 Alessandro Vesely <[email-masked]> 
wrote:

> Problem B imposes a tight matching between where the original message has
> been filter and where the report is going to be handled. In addition, it
> needs both spam and ham info. Since the main purpose of server-based (as
> opposed to client-based) filtering is to save bandwidth, efficiency is a
> relevant concern.
>
> Problem A has a somewhat wider horizon, as it assumes that reported spam
> may be routed through some trust-chained operators, possibly reaching the
> author of the original message. Although the report may also be used for
> tuning or assessing anti-spam filters, its main purpose is to affect the
> source of the original message. This is a generalization --and
> regularization-- of the FBLs currently used between giant mailbox
> providers and ESPs. My expectation is that it will result in important
> advances in the collective understanding of spam, so that massive abuse
> reporting will not be needed forever. In the latter respect, relatively
> inefficient (inelegant) procedures may be acceptable, if they widen the
> chances of adoption.
>

Yes, that's helpful. You've identified a different dimension in which we 
could divide the large problem (reporting junk mail). That is: the purpose 
to which the report might be applied.

I think that's the third possible dimension that we've identified:

a) purpose (your distinction), reporting up chain would probably require 
SMTP reports, but they could be generated in response to the flagging or 
labelling of messages on mailstores.
b) who's in control (the user or the operator), which bears upon whether to 
use SMTP for reporting.
c) the nature of the mailstore (POP or IMAP), which bears upon the space of 
possible reporting mechansims.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 9 Feb 2010 14:31:55 -0800

> Alessandro Vesely
> Sent: Tuesday, February 09, 2010 6:59 AM
> To: [email-masked]

True, but you don't have to do that.

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 10 Feb 2010 09:06:13 +0100

> True, but you don't have to do that.

But retention is only allowed for trusted internal MTAs.

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 10 Feb 2010 12:07:12 +0000

> But retention is only allowed for trusted internal MTAs.

Right, but the MDA is, by definition (a) not forwarding (it's putting a 
message into a mailstore) and (b) a trusted internal MTA. Isn't it?

I guess there's an issue if the user decides to forward the message.

Since the signature only covers the abuse field, it's not unreasonable to 
remove the dkim signature when removing the authentication results field.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 10 Feb 2010 09:22:54 -0800

> Sent: Wednesday, February 10, 2010 12:06 AM
> To: [email-masked]

More accurately, removal is required if the A-R header claims to be one of yours but it's not coming from an MTA you trust (e.g. one of your border MXes).

An A-R header claiming to be from elsewhere doesn't have to be purged, so a signature covering it would continue to validate.  The MUA, however, is supposed to know to ignore those.

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 10 Feb 2010 19:35:02 +0100

On 10/Feb/10 18:22, Murray S. Kucherawy wrote:
>>>>   Yes, it could. However, removal of the field on forwarding would then break the signature.
>>>

Thanks for the clarification! The last sentence in section 5 kept 
confusing me...

---

From: SM <[email-masked]>
Date: Wed, 10 Feb 2010 10:34:50 -0800

Hi Ian,
At 04:00 09-02-10, Ian Eiloart wrote:
>educational establishments, or all .gov.uk domains (or both) 
>implementing such a rule would change their minds? What if Google 
>also implemented the rule.

I gather that these fine UK educational establishments have read the 
specifications and the discussions leading to it.

BTW, are you suggesting that Internet Standards should be determined 
by what Google does?

Regards,
-sm

---

From: der Mouse <[email-masked]>
Date: Wed, 10 Feb 2010 13:49:10 -0500 (EST)

> BTW, are you suggesting that Internet Standards should be determined

Why not?  The "rough consensus" appears to be that "anything is
acceptable provided Google does it", so on "rough consensus and running
code" grounds, yes, what Google does _should_ set the spec.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Douglas Otis <[email-masked]>
Date: Wed, 10 Feb 2010 11:39:26 -0800

> code" grounds, yes, what Google does _should_ set the spec.
They've likely experienced a fair amount of nuisance traffic generated 
by prolific email abuse.  Why should each host on the Internet publish 
records with a sole purpose of indicating public exchange of SMTP is NOT 
desired?  It should be easy for organizations to make exceptions for 
link-local hosts monitored via email, when too bothered to 
auto-configure MX records.

It would be nice if everyone "formally" adopted their convention of 
noting sender IP address in A-R headers as well, essential for 
uncovering compromised systems.

Those two good behaviors copied at large would indeed help curb much of 
email related abuse.

-Doug

---

From: Ian Eiloart <[email-masked]>
Date: Thu, 11 Feb 2010 13:05:27 +0000

> specifications and the discussions leading to it.

I understand the spec. I've not read the discussions leading to it, but if 
there's a GOOD reason to assume every AAAA record (without a corresponding 
MX record) points to a mail host, then I'd like to hear it.

> BTW, are you suggesting that Internet Standards should be determined by
> what Google does?
>
> Regards,
> -sm

What I'm suggesting is that things currently permitted by standards might 
not be permitted by local policy. I don't like the situation that a DNS 
lookup can't tell me whether an email domain really is supposed to be 
deliverable.

We get lots of mail "from" domains with "A" records and no MX records. It 
turns out that many of these addresses are undeliverable, and life would be 
much easier if that doesn't happen with AAAA records in future. I'm 
inclined to adopt a local policy that requires an MX record in the absence 
of an A record.

I cite Google as a large provider that can influence best practice. I'm NOT 
suggesting their behaviour should set standards. But, if certain practices 
are required to get mail delivered to Google, then they're likely to be 
widely adopted.

---

From: John Leslie <[email-masked]>
Date: Thu, 11 Feb 2010 09:27:28 -0500

> MX record) points to a mail host, then I'd like to hear it.

   There are a number of historical assumptions behind this rule, for
example:

- any email address is an honest attempt to reach a person or process;

- any host connected to the Internet should be able to receive email;

- publishing MX records is difficult for some of these hosts...

   The rule actually made sense when it was first written. I believe the
three assumptions listed above are all false today, but I agreed to
accept the consensus call on this issue for RFC 5321 because with Doug
Otis on one side and Dave Crocker on the other, I didn't want to wait
for one of them to die.

   ;^)

   You can see that the middle assumption is "close enough" to your
question: in actuality, the assumption is that any host with an address
record in DNS, whether IPv4 or IPv6, is worth trying in the interests
of making email delivery reliable.

   We could escape from this rule by issuing a separate RFC listing
justification for exceptions to the rule, but I had to agree with John
Klensin that "fixing" this as _part_of_ the transition from Proposed
Standard to Draft Standard was arguably an over-reach.

--
John Leslie <[email-masked]>

---

From: John Levine <[email-masked]>
Date: 11 Feb 2010 15:39:55 -0000

>MX record) points to a mail host, then I'd like to hear it.

I'm with you.  When they were finishing up 5321, I made the obvious
arguments:

* Fallback to A was a transition that should have been deprecated in 1990

* The vast majority of hosts with A or AAAA but no MX records are not
  mail domains

* Fallback to A makes mail less reliable, since mail sent to a domain
  with an A record on a non-responsive host will take a week to bounce

* The number of IPv6 mail hosts now is tiny, insignificant installed base

* Anyone moving from IPv4 to IPv6 will have to change the DNS anyway,
  so adding an MX record when you add an AAAA is not a big deal

Nonetheless, I lost, they said it was "too much of a change".  Dave was
there and might be able to elucidate.

There is no chance whatsoever that the RFC standards will change.

The idea of not accepting mail from domains with only AAAA records
might be worth pursuing. I agree that despite what 5321 says, it seems
pretty unlikely that such domains would ever send mail anyone wanted
to receive.

R's,
John

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 12 Feb 2010 10:58:31 +0000

> There is no chance whatsoever that the RFC standards will change.

Ever? Even if it became common practice? I guess that the standards process 
isn't going to lead on this question.

> pretty unlikely that such domains would ever send mail anyone wanted

Yes. Hey, I'm not even sure that we'd accept that email right now. I simply 
don't know if my MTA is IPv6 compatible in that way. I guess that I'd 
better find out...

Right, it seems that the MTA is capable, if compiled with IPv6 support, but 
since we've not got any IPv6 routing to the world on our network, our 
sender domain verification tests simply aren't going to work. That's nice. 
I've never had any complaints, and I will ensure when we do deploy IPv6, I 
don't permit email from domains that have AAAA but not A or MX records.

---

From: John Levine <[email-masked]>
Date: 12 Feb 2010 15:15:27 -0000

>isn't going to lead on this question.

Really, I know the people involved, and remember that I feel the same
way you do about fallback from MX to AAAA.

>don't permit email from domains that have AAAA but not A or MX records.

I have a theory that you will never, ever, have any reason to accept mail
from IPv6 networks, since everyone you want to hear from will have an
MTA or gateway on IPv4, but that is a separate argument.

R's,
John

---

From: der Mouse <[email-masked]>
Date: Fri, 12 Feb 2010 15:09:00 -0500 (EST)

> I have a theory that you will never, ever, have any reason to accept
> mail from IPv6 networks, since everyone you want to hear from will
> have an MTA or gateway on IPv4, but that is a separate argument.

Never's a long time.  I think you might be right, but only because I
expect Internet governance to implode before 6 overtakes 4 as the
default IP version.  If not for that, I would expect IPv6 to reach a
point where IPv4 is but a quaint curiosity within times I can
reasonably expect to live to see - say, the next 30 years.

When I worked in Tromsø for the second half of 2002, the house netlink
they set me up with was globally routable - but v6-only.  And that was
over seven years ago.  Adoption is going to be slower in the
world-facing-MTA space, but not so much slower that, well, see above.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: John Levine <[email-masked]>
Date: 12 Feb 2010 20:35:52 -0000

>reasonably expect to live to see - say, the next 30 years.

Given the incredibly botched way IPv6 has been rolled out, e.g., DHCP
still doesn't work, I expect we'll be seeing a lot of it within
networks, but with 6to4 NATs to talk to the rest of the world for a
long time.  Unless v4 goes away completely, there's no disadvantage to
sending it through 6to4, since mail, unlike a lot of other
applications is designed to be proxied and relayed.

R's,
John

---

From: SM <[email-masked]>
Date: Sat, 13 Feb 2010 09:29:09 -0800

>code" grounds, yes, what Google does _should_ set the spec.

If that is the rough consensus, I'll wait for the publication of 
those specifications. :-)

At 05:05 11-02-10, Ian Eiloart wrote:
>What I'm suggesting is that things currently permitted by standards 
>might not be permitted by local policy. I don't like the situation 
>that a DNS lookup can't tell me whether an email domain really is 
>supposed to be deliverable.

If your local policy is to reject my messages, there is nothing I can 
do about it.

>Otis on one side and Dave Crocker on the other, I didn't want to wait

:-)

It was a very long discussion where there was also several other 
parties that debated about both sides of the argument.

Regards,
-sm