Jim Fenton | 14 Feb 00:43 2016
Picon
Gravatar

Fwd: New Version Notification for draft-fenton-smtp-require-tls-01.txt

Hi,

I have submitted an update to this draft. Thanks to several of you for excellent comments. Significant changes are:

- Conversion of REQUIRETLS from an SMTP verb to a MAIL FROM parameter to better associate REQUIRETLS requirements with transmission of individual messages.

- Addition of an option to require DNSSEC lookup of the remote mail server, since this affects the common name of the certificate that is presented.

- Clarified the wording to more clearly state that TLS sessions must be established and not simply that STARTTLS is negotiated.

- Introduced need for minimum encryption standards (key lengths and algorithms)

- Substantially rewritten Security Considerations section

Further comments are of course appreciated.

-Jim


-------- Forwarded Message -------- Subject: Date: From: To:
New Version Notification for draft-fenton-smtp-require-tls-01.txt
Sat, 13 Feb 2016 15:36:57 -0800
internet-drafts <at> ietf.org
Jim Fenton <fenton <at> bluepopcorn.net>


A new version of I-D, draft-fenton-smtp-require-tls-01.txt has been successfully submitted by Jim Fenton and posted to the IETF repository. Name: draft-fenton-smtp-require-tls Revision: 01 Title: SMTP Require TLS Option Document date: 2016-02-13 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-fenton-smtp-require-tls-01.txt Status: https://datatracker.ietf.org/doc/draft-fenton-smtp-require-tls/ Htmlized: https://tools.ietf.org/html/draft-fenton-smtp-require-tls-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-fenton-smtp-require-tls-01 Abstract: The SMTP STARTTLS option, used in negotiating transport-level encryption of SMTP connections, is not as useful from a security standpoint as it might be because of its opportunistic nature; message delivery is prioritized over security. This document describes a complementary SMTP service extension, REQUIRETLS. If the REQUIRETLS option is used when sending a message, it causes message delivery to fail if a TLS connection with the required security characteristics cannot be completed with the next hop MTA or if that MTA does not also advertise that it supports REQUIRETLS. Message originators may therefore expect transport security to be used for messages sent with this option. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat

_______________________________________________
ietf-smtp mailing list
ietf-smtp <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-smtp
John Levine | 11 Feb 22:54 2016

Re: Draft for compressing SMTP streams

To move the discussion along, here's a draft for the CDAT compressed
data command.

https://datatracker.ietf.org/doc/draft-levine-smtp-compress/?include_text=1

R's,
John

_______________________________________________
ietf-smtp mailing list
ietf-smtp <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-smtp

Wiley, Glen | 3 Feb 15:00 2016
Picon
Gravatar

using DMARC to signal policy for email canonicalization, signing and encryption

In light of all of the discussion about how the LHS of email addresses are normalized and encoded/hashed in order to be used to publish certificates and keys via DANE records like SMIMEA and OPENPGPKEY we have put together an approach that lets a zone owner signal the policy that is used for their domain by adding a few keywords to the DMARC record.


I also posted this in the DMARC and DANE lists, Kurt Andersen posed a few good questions so I have included my answers here:

  1. Although this proposal appears to be an MUA feature, it has meaningful relevance to the typical transfer agent as well.  If it is fair to summarize DMARC as a means for reducing the delivery of forged email then this proposal fits in nicely.  If an MTA can determine for example that a domain enforces a policy of signing all outbound messages (by the email sender, not using DKIM) and can easily locate the sender’s signing  key with an appropriate chain of trust then the MTA can make a reliable decision about whether that email originated from the sender’s domain.  This “feels” very similar to the way we use SPF and DKIM now. 
  2. Signaling mechanisms are most effective when they can leverage a beachhead already established by a deployed technology.  DMARC has a growing deployed base with building momentum so it makes an attractive mechanism for signaling.
If a domain originating email signals a policy that all outbound messages are signed and the recipient is unable to validate that signature then the recipient should do something interesting with the message.  Bear in mind that the domain originating the records will have published the keys using a DNSSEC signed domain and will have published keys/certs for the users who originate mail from the domain.  There would need to be a DNS resolution failure in order for a recipient to not be able to locate the key.  Although there are currently still some deficiencies in the DNSSEC deployment, the operational picture for DNSSEC is continuing to improve. This proposal anticipates DNSSEC reaching critical mass.

We welcome discussion about this approach.
-- 
Glen Wiley
Principal Engineer
Verisign, Inc.
(571) 230-7917

A5E5 E373 3C75 5B3E 2E24  
6A0F DC65 2354 9946 C63A
_______________________________________________
ietf-smtp mailing list
ietf-smtp <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-smtp
Paul Smith | 3 Feb 11:32 2016
Picon

Mail forwarding to Gmail problem/question

Hi, I just wondered if anyone here had any suggestions for this issue we 
constantly have...

We provide a paid SMTP relay service to some of our customers who have 
ISPs with awful SMTP relay services.

One constant issue we have is that several of our customers insist of 
setting their internal mail servers up to forward all mail for certain 
users back out to gmail addresses. That means that they send bucketloads 
of spam (incoming spam to them, which then gets forwarded back to our 
servers). What then happens is that Google (reasonably understandably) 
start limiting our servers from sending mail to them, and they even seem 
to start rejecting legitimate mail just because it's come through our 
servers which are also sending 'spam' to them.

We do tell the customers not to do this. They do it so they can get 
their mail at home, so we tell them it's probably better to simply allow 
access to their internal mail server from the Internet (they have IMAP4, 
so it's a nice user experience as well), but they still want to forward 
the mail back out again regardless.

What I've started doing is detecting this indiscriminate forwarding from 
the customers' MTAs and route that mail to one particular MTA which is 
only used for sending the forwarded messages on to Google. Hopefully 
that will limit the 'bad reputation' to just that one server's IP address.

We could start passing the outbound mail through our own spam filter as 
well, but that's something we're reluctant to do because it'll lead to 
false positives.

Any other ideas or thoughts?

Am I right in interpreting Google's behaviour, or are they clever enough 
to detect MTA forwarded messages and not assign poor reputation to the 
forwarding MTA in that case?

Is there something clever we should be doing to tell Google what's 
happening?

_______________________________________________
ietf-smtp mailing list
ietf-smtp <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-smtp

Brandon Long | 28 Jan 22:42 2016
Picon

Compressing SMTP streams

Has there been any previous discussion on having a COMPRESS like extension for SMTP?

Similar to RFC 4978 for IMAP.

I was hoping we could get this for free with TLS, but few libraries implement it and https://en.wikipedia.org/wiki/CRIME seems to have made them leary about it.  I don't think SMTP is implicated because it doesn't use cookies/etc, but anyways.

There seems to have been some discussion ~13 years ago, but it went no where.

As for my reasoning, at least for us:

1) CPU is cheaper than bandwidth
2) message sizes are increasing, but base64 isn't going away

Theoretically, switching to some combination 8BITMIME, CONTENTBINARY and BDAT, we'd save nearly as much bandwidth since a good fraction of the compression is going to be recovering the base64 encoding overhead on attachment types that aren't likely to compress much.  That said, with the advent of DKIM, we can't easily change the encoding of messages without breaking signatures, so we're kind of stuck using base64.

DKIM and ARC are also leading to larger headers, which should compress relatively well, not to mention larger HTML text parts.

Of course, email is only a fraction of modern networks, but the overall volumes at medium to large esps would still make a useful reduction.

Brandon
_______________________________________________
ietf-smtp mailing list
ietf-smtp <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-smtp
Jim Fenton | 10 Jan 23:27 2016
Picon
Gravatar

Fwd: New Version Notification for draft-fenton-smtp-require-tls-00.txt

Below is the announcement of a draft I just submitted that may be of interest to this list. The approach here is complementary to the other proposals I have seen along these lines (e.g., smtp-sts).

Thoughts, reviews, etc. welcomed.

-Jim


-------- Forwarded Message -------- Subject: Date: From: To:
New Version Notification for draft-fenton-smtp-require-tls-00.txt
Sun, 10 Jan 2016 14:21:37 -0800
internet-drafts <at> ietf.org
Jim Fenton <fenton <at> bluepopcorn.net>


A new version of I-D, draft-fenton-smtp-require-tls-00.txt has been successfully submitted by Jim Fenton and posted to the IETF repository. Name: draft-fenton-smtp-require-tls Revision: 00 Title: SMTP Require TLS Option Document date: 2016-01-10 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/internet-drafts/draft-fenton-smtp-require-tls-00.txt Status: https://datatracker.ietf.org/doc/draft-fenton-smtp-require-tls/ Htmlized: https://tools.ietf.org/html/draft-fenton-smtp-require-tls-00 Abstract: The SMTP STARTTLS option, used in negotiating transport-level encryption of SMTP connections, is not as useful from a security standpoint as it might be because of its opportunistic nature; message delivery is prioritized over security. This document describes a complementary option, REQUIRETLS, which causes message delivery to fail if a TLS connection with the required security characteristics cannot be negotiated with the next hop MTA or if that MTA does not also support REQUIRETLS. Message originators may therefore expect transport security for messages sent with this option. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat

_______________________________________________
ietf-smtp mailing list
ietf-smtp <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-smtp
Wei Chuang | 17 Dec 02:42 2015
Picon

Start discussion for draft-wchuang-grunion-01

Hi all,

I would like to start discussion on draft-wchuang-grunion-01 (https://tools.ietf.org/html/draft-wchuang-grunion-01) now that some of the discussion of shutup <at> is resolving.

Very quick summary of wchuang
- Use S/MIME, and use rewrap the messages to provide additional header content privacy.
- Use intermediary proxy sender and recipients that hide the true sender and recipient.
  - Proxies unwrap the message and forward
- Find the proxy sender and recipient through either X.509 certificate extension
  or CMS extension.
- Differentiate privacy required by the proxies i.e. what message content can been seen
by the proxy sender and recipients SMTP MTA.
Details of this can be found in draft-wchuang-grunion-01.

Some top level discussion points. First I wanted to contrast and show similarities between ehip <at> (draft-wchuang-grunion-01) from shutup <at> (draft-josefsson-email-received-privacy-00).  Both proposals are attempting to improve header privacy.  However josefsson is particularly interested in Received headers, while wchuang is interested in hiding the sender and recipient from the delivery path such that a MitM cannot find out simultaneously who the true sender and true recipient are though the adversary might find one or the other.  wchuang does mention that Received headers are particularly difficult case to handle and mentions some scenarios where it can be supported or suggests it might have to be dropped.  wchuang does go into some different details than josefsson since it specifies S/MIME.  This proposal makes some new requirements SMTP MTA to support S/MIME processing to support unwrapping the proxied messages and then forwarding the message.  As this forwarding process affects the mail delivery path, wchuang also discusses supporting the NDR or bounced mail case to return back along this altered path while maintaining privacy.

Another detail to discuss / understand is how the proxy selection occurs.  While at some level conceptually similar to TOR / onion routing there are several differences to call out.  wchuang proposes that these proxies are pre-determined statically and described in previously sent messages while in TOR while the sender queries a directory server.  More specifically in wchuang the sender finds from previously received messages the S/MIME signature containing X.509 certificates with a new extension describing the proxy adresses or similarly from the signature's CMS.  To prevent traffic analysis, the proposal does suggest that the sender may choose from a list of proxies, and that these proxies ought to have sufficient traffic volume to make traffic analysis difficult.

That's a summary of what's being proposed.  I look forward to any discussion.

-Wei
_______________________________________________
ietf-smtp mailing list
ietf-smtp <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-smtp
Brandon Long | 4 Dec 01:47 2015
Picon

Received header corretness (was Proposed Charter for the "SMTP Headers Unhealthy To User Privacy" WG)



On Tue, Dec 1, 2015 at 9:51 AM, Ned Freed <ned.freed <at> mrochek.com> wrote:
Ned Freed writes:
> Gmail:   Webmail does not disclose originating client IP, apparently using
>         invalid Received: field to avoid doing so.

Invalid, how so?

I looked at one now, and the oldest Received contained "by", "with" and
"id" received-tokens. 5322 says all received-tokens are optional, 5321 says
that SMTP servers MUST add a "from" received-token, but that Received
wasn't written by an SMTP server and 5321 3.7.2 explicitly allows other
software to be different. 2476 says nothing.

What am I overlooking?

In my testing I saw the following sorts of fields:

(webmail)

Received: by lffz202 with SMTP id z202so35306770lff.3 for
<ned.freed <at> mrochek.com>; Wed, 21 Oct 2015 22:32:47 -0700 (PDT)

(submit)

Received: by pasz6 with SMTP id z6so88255027pas.2 for <Ned.Freed <at> mrochek.com>;
Thu, 22 Oct 2015 07:30:31 -0700 (PDT)

That's added by the outgoing smtp server, but it didn't receive the message "with" SMTP.  Unfortunately, we can't just say "with gRPC" since the with value has to be IANA registered.  I guess we could make it an X-Received header instead, or just add the from clause.  That said, we also use "with HTTP" and no one has complained about those, so maybe...  OTOH, I was once told to use "with UTF8" to know that a message was RFC 6532 instead of RFC 5322, so that wouldn't be very helpful unless we also had a 'with gRPCUTF8'

Brandon

_______________________________________________
ietf-smtp mailing list
ietf-smtp <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-smtp
Brandon Long | 4 Dec 01:36 2015
Picon

Levels of proposals

The WG proposal seems to imply taking all IPs out.  The discussion has mostly been about submission.

It seems to me that there are at least three different IPs used, and some of these are going to be visible regardless of intent.

Ie, there is the submission IPs, there are "internal" IPs, and external ones.

Submission IPs seem like the largest level of risk, and from my gross understanding of anti-spam, pretty minor.  I'm not sure what the current source levels are, but submission IPs would be most useful in the case of hijacked account spam or abusive account spam.  Presumably, if spam reports about such are forwarded to the MSP, then the MSP can easily store the information somewhere other than the easily forged headers and take the appropriate action.  Only if the answer is "they don't take action" would you need more.

Also, if the previous thread's list of large MSPs inclusion of submission IPs is correct, then >2 out of the top 3 have already removed them (ie, only a fraction of Gmail mail has them at this point).

Internal IPs, this hardly seems controversial.  If any mail system did that, not sure if anyone would bat an eye.

External IPs, ie server to server... I guess one may learn "something" if you can tell which submission server they talked to, we certainly have servers across the world... but even with 20 odd locations, I doubt that would be that specific.

So, I would recommend concentrating on submission IPs.  I might also include a recommendation for submission servers to store the IPs for some length of time to allow for abuse handling, or even to include an encrypted version in the message.

Brandon
_______________________________________________
ietf-smtp mailing list
ietf-smtp <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-smtp
Jacob Palme | 3 Dec 14:44 2015
Picon
Picon

Anti-spam - paid network

The main reason for the proliferation of spam is that the cost of sending a message is so small for the sender.
The real cost - for delivery, anti-spam tools, personal reading and rejection of spam, is a cost for the
recipient, not for the sender. I myself spend about 15 minutes a day on opening and rejecting spam
messages, even though I use multiple spam filter. The total cost for all internet mail users is billions of dollars.

I think that the only workable method of getting rid of spam is to charge the sender of messages a price of
perhaps 0.10 $/recipient for sending messages.

To implement this, we should set up a network of smtp stations (MTAs) which charge a price of perhaps 0.10 $
for receiving a message and transmitting it to its recipient. We might perhaps call such stations CMTA
(for Charged Message Transfer Agents) This network should be separate from the existing network of mail
transfer agent. a CMTA should not charge for messages coming from other CMTAs) A secure method must be
defined so that a recipient can distinguish between messages from the CMTA from messages from other
non-charged MTAs. Probably some kind of cryptographic method has to be defined. A way of reducing the
right to act as a CMTA must be found for CMTAs who represent spammers.

I believe that people will be willing to accept the complication of receiving messages from two SMTP
networks, the conventional network and the new CMTA network. Mailing lists must be handled within the
CMTA network, so that the sender of a message to a mailing list need only pay 0.10 $ for sending the message to
all members of the mailing lists. I am not yet sure how to avoid spammers from misusing large mailing lists,
but probably a human has to approve every message before it is distributed to members of mailing lists.

The income, 0.10 dollars per recipient, can be used to set up and manage the network of CMTAs, paying for the
human monitors of messages to mailing lists. Any surplus might go to IETF. We should avoid systems run by
private companies for their own profit.

Invoices sent by conventional e-mail should be invalid, and the recipient need not pay such invoices.

My proposal will not stop such spam where the sender is willing to pay 0.10 $/recipient to submit the
message. But propably this will be a very small percentage, perhaps 1 % och 0.1 %, of the present amount of spam.

Recipients should set up their mailers so that messages coming from CMTAs get higher priority and messages
coming from the old mail network will get lower priority, or perhaps dismissed without being read.
Possibly put charged messages into a different mailbox than no-charged messages.

There are several technical details to be resolved to realize the network of CMTAs, but IETF should be able
to resolve these details and define a variant of SMTP for transmissions to and between CMTAs. And I do not
think any other anti-spam method will work. Details to resolve:

- How to handle the payments for sending mail to CMTAs and distributing the income.
- How to block malicious fake CMTAs.
- How to send and receive charged messages.
- How much to charge for sending a message, price per recipient.
- How to set up the network of CMTAs.
- How to handle mailing lists, where the price for the sender cannot be 0.10 $ per member of the mailing list.
--
Professor emeritus Jacob Palme <jpalme <at> dsv.su.se> (Stockholm University)
for more info see URL: http://www.dsv.su.se/jpalme/

_______________________________________________
ietf-smtp mailing list
ietf-smtp <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-smtp

Richard Clayton | 2 Dec 11:02 2015
Gravatar

Re: [Shutup] Proposed Charter for the "SMTP Headers Unhealthy To User Privacy" WG (fwd)


In message <20151201234708.GA6229 <at> lapsedordinary.net>, Martijn Grooten
<martijn <at> lapsedordinary.net> writes

>On Tue, Dec 01, 2015 at 09:10:20PM +0000, Richard Clayton wrote:
>> If you want to have very limited data in your email header fields then
>> you should look at the systems that you operate yourself and clean up
>> the information at that point. You'll probably get a poorer delivery
>> experience when sending to MAGY and others -- but that's your tradeoff.
>
>Sure, making such changes on your own is probably going to hurt more
>than it helps. Which seems a good argument in favour of some kind of
>RFC, 

I think you have misunderstood my point (which Chris Lewis also made)... 

If you discard all the data that identifies that you were the origin of
this email then your previous good reputation will not count towards
ensuring that another email from you is treated favourably.

It doesn't matter a jot whether or not that discarding is done on the
basis of the rules set out in an RFC or otherwise.

>or at least a WG discussing whether one is needed.

you should note that IP addresses acquire reputation because of the
prefix they are within, because of the AS that announces that prefix and
because of the country that AS operates from...   replacing an IP with a
blob will remove those opportunities for you to inherit some kudos from
your neighbours and fellow citizens

this WG is going to have to come with something fairly clever to avoid
making things worse  (and please don't forget about loop prevention)

--

-- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755


Gmane