Re: Microsoft takes over British Telecom

Paul Smith <[email protected]>
Newsgroups gmane.ietf.asrg
Message-ID <[email protected]>
On 29/10/2011 02:38, Paul Smith wrote:
> On 28/10/2011 19:28, Douglas Otis wrote:
>> There are many methods that might be used to authenticate outbound 
>> MTAs, such as SMTP Auth.  Ideally SMTP would include DANE extensions 
>> used in conjunction with Kerberos.  If it were not for DKIM ignoring 
>> prepended headers, it would have merit as an anti-phishing strategy.  
>> Since DKIM does not verify who sent what to whom, it can only 
>> identify domains considered "too big to block" as well.
>
>
> (Still doesn't solve forwarding without return path rewriting, or the 
> general authorisation problem, but authenticates the sender MTA 
> effectively, AFAICS)

I've been thinking about forwarding

If you have A -> B, then server B forwards to server C, C can't do any 
authentication based on A, because A doesn't know about the forwarding 
(or it would, presumably, just send to C directly).

So, all sender domain authentication fails (without return path rewriting)

So, what you need is for C to be able to give B an authentication key 
for the forwarding. Then, B could pass that back to C with the message 
(possibly as a parameter to the RCPT command). The issue with this is 
that user intervention would be needed - so every time a user wants to 
subscribe to a mailing list,or set up a forwarding to their gmail 
account, they would need to go to the destination server, get a key from 
it, and give it to the forwarding server. This could show consent for 
any anti-spamming legislation, but could also be too complicated for 
many users to handle.

The authentication key would need to allow B to send *anything* to C for 
the relevant recipient, so ideally the key that C gives would be 
specific to B (to allow it to be revoked in the case of abuse)

Technically this wouldn't need to be hard at all, it's just the manual 
requirement for key exchange that would be an issue for many people.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.