Re: [Asrg] We don't need no stinkin IMAP or POP, was Adding a spam button to MUAs

Daniel Feenberg <> Sat, 06 February 2010 12:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3F4A23A7095 for <>; Sat, 6 Feb 2010 04:18:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.442
X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Uv3zVYWvDwXS for <>; Sat, 6 Feb 2010 04:18:32 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5AFF23A6835 for <>; Sat, 6 Feb 2010 04:18:31 -0800 (PST)
Received: from ( []) by (8.14.3/8.13.8) with ESMTP id o16CJK85017287 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sat, 6 Feb 2010 07:19:21 -0500 (EST) (envelope-from
Received: from (localhost []) by (8.13.8+Sun/8.12.10) with ESMTP id o16CI30Y011616; Sat, 6 Feb 2010 07:18:03 -0500 (EST)
Received: from localhost (Unknown UID 1079@localhost) by (8.13.8+Sun/8.13.8/Submit) with ESMTP id o16CI39c011613; Sat, 6 Feb 2010 07:18:03 -0500 (EST)
X-Authentication-Warning: Unknown UID 1079 owned process doing -bs
Date: Sat, 6 Feb 2010 07:18:03 -0500 (EST)
From: Daniel Feenberg <>
To: Anti-Spam Research Group - IRTF <>
In-Reply-To: <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.39/RELEASE, bases: 20100205 #3432814, check: 20100206 clean
Subject: Re: [Asrg] We don't need no stinkin IMAP or POP, was Adding a spam button to MUAs
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <>
List-Id: Anti-Spam Research Group - IRTF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 06 Feb 2010 12:18:34 -0000

On Sat, 6 Feb 2010, John Levine wrote:

>>> 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?
>> I think the latest round of discussion has eliminated any interest in the
>> 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.

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

> 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
> _______________________________________________
> Asrg mailing list