Alexey Melnikov | 29 Mar 17:36 2014

Registration request for smtp:// and submit:// URI schemes (draft-melnikov-smime-msa-to-mda-04)

I wanted to use smtp:// URIs in X.509 URI subjectAltName values. My use 
case is returning such URIs in S/MIME certificates of S/MIME capable 
Mail Transfer Agents (MTAs). My colleague pointed out that smtp:// URIs 
are not registered with IANA (despite being used by several products, 
including at least one open source), so here is my attempt to register 
it. I am also registering submit:// URI scheme, which is a similar URI 
schemes, but for designating Mail Submission Agents.

SMTP URI registration

       URI scheme name: smtp

       Status: permanent

       URI scheme syntax:
       smtpuri = "smtp://" authority ["/" [ "?" query ]]
       authority = <defined in RFC 3986>
       query = <defined in RFC 3986>
       If :<port> is omitted from authority, the port defaults to 25.
       The query component is reserved for future extensions.

       URI scheme semantics:
       The smtp: URI scheme is used to designate SMTP servers (e.g.
       listener endpoints, S/MIME agents performing Domain signing), SMTP
       There is no MIME type associated with this URI.

       Encoding considerations:

(Continue reading)

Paul Smith | 26 Mar 17:57 2014

Re: confirm 8bdfea7f026277ef3569cabfc9e9ce16d6648021 (fwd)

On 26/03/2014 16:54, John Levine wrote:
> Hi.  I certainly haven't been unsubscribing from lists.  Any idea
> what's going on?
Maybe someone was trying to get you off the list for some reason?

In which case... did you really want to post the confirmation request 
you got? - someone could actually unsubscribe you now (unless you edited 
the confirmation code before posting it)


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

ietf-smtp mailing list
ietf-smtp <at>

Murray S. Kucherawy | 5 Mar 19:20 2014

Per-Recipient Data Responses

How come this never got adoption?  It comes up from time to time in "We really should do this" sorts of discussions, but it doesn't seem like anyone ever took the plunge and it just expired.  Is it just that nobody does it because nobody else does it?

ietf-smtp mailing list
ietf-smtp <at>
georgehanes | 30 Jan 23:07 2014

Be cautious of this computer science conference

Be cautious of this computer science conference

If you have any thought of attending the world’s biggest 
f-a-k-e conference in computer science  you should visit 
any websites below 

The organizer of this conference is H-amid A-rabnia  a professor from University 
of Georgia, Athens, US.  He already earned millions of 
dollars from the registration fee. He recently started 
a new conference CSCI due to his hunger for money 

He did not reveal the reviews and reviewers' information 
for all the papers he received, despite repeated requests 
and challenges. The reason for his failure is there are 
no reviews and reviewers and he just cheated the research 
community for more than a decade by announcing that each 
draft paper is reviewed by two experts. We challenge him 
to publish these details at the conference website. 
Where are your experts? Where are your reviews? 

Soon he comes up with a story announcing that he lost all 
the information having reviews and reviewers because of 
computer crash or theft.

DBLP stopped indexing these conferences since 2011 and 
displayed an explicit message; 
"The DBLP Advisory Board decided to discontinue indexing 
of this conference series". Visit 
as a sample.

He was forced to remove his name, the university of Georgia 
name, and university of Georgia email address from the 
conference’s contact page because the University has 
banned him from doing that. Do not spoil your resume by 
publishing in this conference.

Apologies for posting to multiple mailing lists. Spreading 
the news is the only way to stop this conference from 
harming innocent researchers.


Many researchers cheated by these conferences

ietf-smtp mailing list
ietf-smtp <at>
SM | 18 Oct 02:48 2013

Re: Request for discussion of Mandatory Secure Mail Delivery proposal (draft-wchuang-msmd)

Hi Wei,
At 10:02 17-10-2013, Wei Chuang wrote:
>Agreed this was useful to look at.  Was the I-D for RFC 6710 
>discussed on this mailing list? or if you happen to know the I-D 
>name, I can try to search for it. The discussions would be interesting.

The I-D name is draft-melnikov-smtp-priority.  It was discussed on 
apps-discuss <at>  There is a (previous) thread at

>If this is a pattern, I wonder if a common platform could be built 
>to support specifying behavior at mail delivery and having the 
>propagate along with the message and derivatives?  This is what this 
>proposal is trying to do for the more specific mail delivery security context.

It's an interesting question.  I'll comment below.

>I would answer with something wishy washy like "more safe".

That's a step forward.  This is a quick thought.  I would explore 
"hand-off of responsibility".


ietf-smtp mailing list
ietf-smtp <at>

Brandon Long | 16 Oct 23:46 2013

Gmail NDNs (was Request for discussion of Mandatory Secure Mail Delivery proposal (draft-wchuang-msmd))

On Wed, Oct 16, 2013 at 11:40 AM, John C Klensin <john+smtp <at>> wrote:
> Given where you and your colleagues work, it may be appropriate
> to note that, empirically, gmail is one of the systems that
> cannot be relied upon to generate and deliver NDNs.

I realize I should have been on this list years ago, but my quick
perusal of the last couple years in the archives didn't enlighten
me... can you explain this?

We pretty strictly adhere to a "deliver or block/bounce" philosophy
for mail for Google's systems, outside of some deliberately configured
noreply addresses or some exceedingly rare (and usually admin
requested) firefighting, we don't drop messages.

I do know that Gmail is very aggressive about spam foldering bounce
messages if we can't determine that the bounce is legitimate (ie, the
original message is in the user's sent label), not sure if that
accounts for your view or not.

ietf-smtp mailing list
ietf-smtp <at>

SM | 16 Oct 16:45 2013

Re: Request for discussion of Mandatory Secure Mail Delivery proposal (draft-wchuang-msmd)

Hi Wei,
At 12:31 15-10-2013, Wei Chuang wrote:
>Request for discussion (draft-wchuang-msmd) of a proposal to secure 
>mail from eavesdropping and MitM attacks.  All comments welcome on 
>this thread.  I'm mentioning the proposal also to apps-discuss <at>  and 
>saag <at>  lists as this may be of interest to them too, but redirecting 
>discussion to this list so its all happening in one place.

There has been some discussion about opportunistic on the (IETF) 
perpass mailing list.  The problem, if I can call it that, is the 
assumption that "the destination will honor maintaining the MSMD 
protocol".  There have been several proposals previously which have 
tried to maintain that in various ways.

I suggest taking a look at RFC 6710.  If I recall correctly there was 
some discussion about why the assumptions being made might not work 
out well in general.  It may be possible to find out whether the 
"might not work out well" is incorrect as there are implementations 
of the specification.

I hope that my comments are not discouraging.  It is good to have a 
proposal such as draft-wchuang-msmd-00 as it provides a starting 
point to identify what could be done to get secure mail delivery.

I'll ask an unfair question.  Would you provide me with the assurance 
that I will be safe if I use a mail provider which supported the 
proposal?  I am aware that it is a high bar.  That's one of the 
drawbacks of using the word "secure".


ietf-smtp mailing list
ietf-smtp <at>

Wei Chuang | 15 Oct 21:31 2013

Request for discussion of Mandatory Secure Mail Delivery proposal (draft-wchuang-msmd)

Hi ietf-smtp,

Request for discussion (draft-wchuang-msmd) of a proposal to secure mail from eavesdropping and MitM attacks.  All comments welcome on this thread.  I'm mentioning the proposal also to apps-discuss <at> and saag <at> lists as this may be of interest to them too, but redirecting discussion to this list so its all happening in one place.

Here's the abstract:
Opportunistic SMTP TLS does not enforce electronic mail delivery using TLS leading to potential loss of privacy and security. We propose an optional mail header extension "mandatory-secure-mail- delivery:" and SMTP EHLO response extension "MSMD" that indicates mail must be delivered privately using TLS and with integrity using DKIM, and thereby provide a security guarantee to the user. When mail is sent with the header indicating privacy and integrity and if the receiving party does not support this, the mail is instead bounced. To protect the mail after delivery, the destination SMTP server must advertise its capabilities as part of the EHLO response, and the sender can choose whether the destination is able to honor the privacy requirements specified on the mail header.

Link to the proposal here:


PS Pardon for any IETF formatting or etiquette errors as I'm very new to the IETF process.
ietf-smtp mailing list
ietf-smtp <at>
John Levine | 22 Sep 17:23 2013

BCP or similar on list validation by partial SMTP session

Some mailers attempt to clean their address lists by going through the
list and doing EHLO, MAIL FROM, RCPT TO, and dropping the ones where 
the RCPT TO fails.

We all know why this is abusive, and why it doesn't work (greylisting,
wildcards, reject after data, etc.) but is that written down anywhere?

keld | 14 Sep 03:56 2013

guidance on how to secure against sniffing and paid backdoors

Recently there has been reports in newspapers about powerful organisations that
can sniff on wires and has paid for backdoors and compromising cryptographic implementations.

Would it be a good idea to make a document describing best practices trying
to protect against such actions, to guide implemetors and service providers?

best regards
ietf-smtp mailing list
ietf-smtp <at>

keld | 23 Aug 03:27 2013

test for port 25 of sending MTA - for spam detection


Just a thought I had for spam detection: what about testing if you could
connect to port 25 on the sending MTA? Zombies behind a NAT would not be 
able to be reached. I think there are some web-based mailers that could be hurt,
but maybe one could make a whitelist  for those. Is this a known
scheme, and what are the pros and cons?

best regards
ietf-smtp mailing list
ietf-smtp <at>