http://blog.gmane.org/gmane.ietf.smtp hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.smtp/9698 <pre>Hello everybody, this is a somewhat theoretical topic, but it seems to come up every few years in usenet discussions, so I'll ask for clarification/opinions. Consider this DNS configuration: A.example.com. CNAME M.example.com. M.example.com. MX 10 S.example.com. S.example.com. A 192.0.2.1 Now an MTA receives a message addressed to &lt;user&lt; at &gt;A.example.com&gt;. This MTA is a relay system and has no special configuration with regard to A.example.com. RFC 5321, section 5.1 specifies how to resolve "A.example.com", so by following the chain A.example.com -&gt; M.example.com -&gt; 192.0.2.1 the MTA will end up connecting to 192.0.2.1. We now have an SMTP connection and I will call this MTA the client and 192.0.2.1 the server. Which address should the client use in the RCPT TO command? 1) &lt;user&lt; at &gt;A.example.com&gt;, because a relay must pass on the message unmodified. 2) &lt;user&lt; at &gt;M.example.com&gt;, because M.example.com is the canonical name of the recipient domain. 3) Undefined behaviour. The MTA could even have reje</pre> Peter J. Holzer 2013-05-06T08:56:18 http://comments.gmane.org/gmane.ietf.smtp/9697 <pre>Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without</pre> johnsonhammond2< at >hushmail.com 2013-04-27T16:52:14 http://comments.gmane.org/gmane.ietf.smtp/9696 <pre>Hi, Section 4.1.2 of RFC 5321 states the following ABNF production: Argument = Atom Strangely, I cannot find where this production is referenced or used. In the preceding obsoleted RFC2821, the situation seems identical and in RFC 821 that production didn't exist. So, what is this used for? Regards, Stephan. _______________________________________________ ietf-smtp mailing list ietf-smtp&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-smtp </pre> Stephan Bosch 2013-04-23T23:10:37 http://comments.gmane.org/gmane.ietf.smtp/9681 <pre>GMail's submission server saves all the submitted mails to the sender's Sent mailbox. After this most IMAP clients with their default configuration will again save the same mail to the Sent mailbox. I'm not sure if GMail removes one of them as a duplicate or not. I've been considering doing a similar feature to Dovecot (it will most likely have a proxying submission server in near future), but it would be nice to tell the SMTP clients that this auto-saving is happening, so they could skip the IMAP APPEND part with default configuration. Of course there are the LEMONADE extensions that are supposed to solve this same issue, and Dovecot will support those as well, but I think it's going to take a while for clients to actually implement those. There's likely much better chance of them implementing a small check for "oh, the mail was already saved, I'll just skip the IMAP APPEND." Even if any clients themselves didn't implement this, it would make it possible to implement a simple SMTP+IMAP proxy locally that c</pre> Timo Sirainen 2013-04-10T21:22:10 http://comments.gmane.org/gmane.ietf.smtp/9670 <pre>Hi, Once again I am faced with the question of what to do (as a "Dumb" SMTP client) when my outgoing interface has a private IP address and the name is locally administered. I checked RFC 5321 and can't get a *definitive* answer concerning whether or not a name like "Computer-Name.local" or "something.lan" is actually fully-qualified or not; certainly it is not *publicly* resolvable, but it is resolvable within the environment. My feeling is that it does not meet the definition of an FQDN. I cannot determine my name with only a private address, and my name is likely to be meaningless if I resolve it. So, what should I do when sending the HELO/EHLO command again? Is it worthwhile providing a "What is my name?" callback (that can be overridden) to try and automagically detect whether or not our name is likely to be meaningful based on domain suffix or IP address, and if not, use address literal? Or, given how some sites hate address literals, would it be easier and simpler to just churn out</pre> Sabahattin Gucukoglu 2013-03-26T16:17:21 http://comments.gmane.org/gmane.ietf.smtp/9667 <pre>Colleagues, (with apologies for the cross-posting if you get more than one copy of this) As you may have seen already, I'm working on a revision to RFC5451. A Proposed Standard "bis" effort always benefits from describing extant implementations. I know about the ones I've written, and about some very public uses of it (Gmail, Yahoo, for example). If there's anyone in this audience that knows of others, I'd love to hear about it. Reviews of the update are also welcome: https://datatracker.ietf.org/doc/draft-kucherawy-rfc5451bis/ Thanks, -MSK _______________________________________________ ietf-smtp mailing list ietf-smtp&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-smtp </pre> Murray S. Kucherawy 2013-03-22T17:01:00 http://comments.gmane.org/gmane.ietf.smtp/9666 <pre>More from Steve... ---------- Forwarded Message ---------- Date: Thursday, March 21, 2013 12:23 -0400 From: Steven Bellovin &lt;smb&lt; at &gt;cs.columbia.edu&gt; To: John C Klensin &lt;klensin&lt; at &gt;jck.com&gt; Subject: Re: [ietf-smtp] When using TLS, would randomizing the order of the EHLO response be helpful? One last word on the RC4 issue... See http://www.theregister.co.uk/2013/03/15/tls_broken/ and note this: "It's not a very practical attack in general, requiring at least 16,777,216 captured sessions, but as mentioned, attacks will only improve in time," said Arnold Yau, lead developer at mobile security firm Hoverkey. "I think it'd be wise for TLS deployments to migrate away from RC4 as advised." 2^24 sessions before a few bytes are readable, per http://www.isg.rhul.ac.uk/tls/ "Don't panic". ---------- End Forwarded Message ---------- _______________________________________________ ietf-smtp mailing list ietf-smtp&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-smtp </pre> John C Klensin 2013-03-21T17:12:23 http://comments.gmane.org/gmane.ietf.smtp/9658 <pre>This is a question for folks that actually know crypto, and also know SMTP. A common theme of many of the recent statistical attacks on TLS (BEAST, Lucky 13, the ABPPS RC4 attack) has been knowing that some early part of the plaintext was constant. Knowing that some of the early bytes are limited to a range, or even fully known, was even more helpful. On every SMTP server in the world, the first 100 to 250 bytes send by the server after TLS negotiation completes are both constant and known: they're the EHLO response. So that got me wondering if randomizing the EHLO response could be helpful in mitigating statistical attacks. Obviously the degree of "randomizing" is limited; RFC 5321 requires the first line to be the FQDN of the receiver, and every line will contain "\r\n\220-". The most I can do is randomize whole lines. But I don't have an intuitive feel for what might be effective in disrupting these statistical code-breaking techniques; hence the question. I fully understand that fixing the </pre> Carl S. Gutekunst 2013-03-21T07:47:00 http://comments.gmane.org/gmane.ietf.smtp/9595 <pre>Just an idea... maybe it's silly or not worth investigating, but I thought it wouldn't hurt to ask for comments. Thanks, Evert # Reject messages on backup mail exchangers when primary MX is online --- TODO: - Cascading? Like: test all MXs with lower preference number. - Check with [RFC 5321]. - Error messages: correct numbers? Ask for opinions. Negative replies can be permanent (5xx codes) or transient (4xx codes). - Discuss in newsgroup. - Test. - Write RFC. --- Author: Evert Mouw &lt;post&lt; at &gt;evert.net&gt; History: - 2013-02-06 first version ## Problem Multiple incoming mail servers (Mail eXchangers; MX) may be configured for a DNS domain. The MX with the highest priority, that is, the *lowest* preference number, MUST be contacted ([RFC 5321]) by the mailserver of another domain if that other mailserver wants to send mail. The MX with the lowest priority number is therefore called the *primary* MX. The other MXs are *backup* servers. The backup servers will be used by the sending party if the primary M</pre> Evert Mouw 2013-02-23T17:57:43 http://comments.gmane.org/gmane.ietf.smtp/9586 <pre>Does anyone here know of a legitimate MTA, proxy/filter, IDS, or similar critter that sends this verb before sending EHLO? FCCKV2 zQUdwkgzYhu/noMgcNtA0wvhrV0T9SThL3koEfk= I'm suspicious that it's a malware infection on the sender's host, but before I start making accusations I wanted to check around. Various web forums have also reported seeing this as an X-bar header line in HTTP requests, without identifying what it was. &lt;csg&gt; _______________________________________________ ietf-smtp mailing list ietf-smtp&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-smtp </pre> Carl S. Gutekunst 2012-09-28T21:26:48 http://comments.gmane.org/gmane.ietf.smtp/9584 <pre>The below should be of interest to members of these lists too. Tony. </pre> Tony Finch 2012-06-27T19:15:02 http://comments.gmane.org/gmane.ietf.smtp/9579 <pre>If this is not the right mailing list to ask my question, I apologize that. But I failed to find out any mailing list which is better than this. Configuring MUA, like Thunderbird, iMail or Outlook, is quite annoying for me because I have to know many configuration values; protocol, hostname, port, username, password, authentication method or more. If there is a protocol to negotiate the protocol to transport mails between mail client and server, based on preferences or capabilities of the both side, MUA could configure itself automatically without asking to user questions except mail address and password. For example, mail client asks to server(the domain part of the given mail address) which protocol it can use, and mail server replies that SMTP and IMAP is acceptable, and then mail client configures itself as server replies. Other configuration fields also could be filled in this way. Does anyone know a protocol such like that? _______________________________________________ ietf-smtp mailing </pre> Yi EungJun 2012-06-21T16:25:38 http://comments.gmane.org/gmane.ietf.smtp/9578 <pre> A new IETF non-working group email list has been created. List address:ietf-smtp&lt; at &gt;ietf.org Archive: http://www.ietf.org/mail-archive/web/ietf-smtp/ To subscribe: https://www.ietf.org/mailman/listinfo/ietf-smtp Purpose: Discussion of issues related to Simple Mail Transfer Protocol (SMTP) [RFC 821, RFC 2821, RFC 5321] Notes: This replaces the existing ietf-smtp list hosted at imc.org, and subscriptions will be automatically transferred from that list to this. For additional information, please contact the list administrators. _______________________________________________ ietf-smtp mailing list ietf-smtp&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-smtp </pre> IETF Secretariat 2012-06-18T15:09:57 http://comments.gmane.org/gmane.ietf.smtp/9546 <pre> I have just submitted an I-D describing how to use DANE with SMTP. All comments welcome. Tony. </pre> Tony Finch 2012-05-25T17:15:36 http://comments.gmane.org/gmane.ietf.smtp/9529 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SMTP Service Extension for Greylisting Operations Author(s) : Hector Santos Evan Harris Filename : draft-santos-smtpgrey-02.txt Pages : 20 Date : 2012-04-27 GREYLIST is a SMTP extension to formalize the widely supported Greylisting mail filtering method and to help support SMTP rejected transports by following a new formal structured 4yz server temporary rejection response by including a "retry=time-delay" tag string which SMTP clients can use to optimize the rescheduling of the mail delivery attempts. With adoption, network overhead reduction in wasteful mail delivery attempts will be realized. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-santos-smtpgrey-02.txt http://tools.ietf.org/html/draft-santos-smtpgrey-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf</pre> Hector Santos 2012-04-27T23:10:22 http://comments.gmane.org/gmane.ietf.smtp/9528 <pre> Hi, I am going to be updating this I-D tonight to rev-02. I am wondering if there any implementations of the I-D. Its been six months since we implemented and its been 100% successful in minimizing mail send attempts to 2 and the minimizing the 2nd attempt delay to the greylisting server recommended wait time value. Thanks </pre> Hector Santos 2012-04-27T21:21:22 http://comments.gmane.org/gmane.ietf.smtp/9525 <pre> All, as you may know, an IETF working group is reviewing the SPF spec. The evaluation of current deployment is nearly completed, but thus far only analyzes published SPF records. Please contribute to a better understanding by completing the survey: https://www.surveymonkey.com/s/SPF-deployment-survey It will only take three minutes (ten questions on a single page). Please help reaching all mail admins by forwarding this prompt to specialized mailing lists and mail admins you are in touch with, worldwide. Thank you in advance! </pre> Alessandro Vesely 2012-04-27T06:07:33 http://comments.gmane.org/gmane.ietf.smtp/9524 <pre> Please comment on the apps-discuss list if you have any input. -----Original Message----- From: apps-discuss-bounces&lt; at &gt;ietf.org [mailto:apps-discuss-bounces&lt; at &gt;ietf.org] On Behalf Of Alexey Melnikov Sent: Tuesday, April 24, 2012 10:25 AM To: apps-discuss&lt; at &gt;ietf.org Subject: [apps-discuss] Call for Adoption: draft-kucherawy-received-state-02.txt Murray presented this draft in at least one of the face to face IETF meetings and my recollection is that general feedback on this document was positive. So I would like to initiate acceptance call for processing this document in the APPSAWG. Please indicate your support or objection, and opinions thereto before the close of business on May 1st. Alexey, as an APPSAWG co-chair _______________________________________________ apps-discuss mailing list apps-discuss&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss </pre> Murray S. Kucherawy 2012-04-24T17:44:43 http://comments.gmane.org/gmane.ietf.smtp/9442 <pre> Mails are allowed to have multiple addresses in the from header as long as they also have a sender header. However, in basic testing, I have yet to find a MUA that even displays multiple entries for from. Has anyone seen such a user agent? Functionally, should multiple from addresses be considered a deprecated feature? Thanks, Peter </pre> Peter Bowen 2012-02-27T18:35:38 http://comments.gmane.org/gmane.ietf.smtp/9425 <pre> Well, this is sad: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian &lt;http://www.washingtonpost.com/national/on-innovations/va-shivaayyadurai-inventor-of-e-mail-honored-by-smithsonian/2012/02/17/gIQA8gQhKR_story.html&gt; d/ </pre> Dave CROCKER 2012-02-18T23:07:25 http://comments.gmane.org/gmane.ietf.smtp/9423 <pre>Does anyone know of any MTAs that implemented the SUBMITTER extension, defined in RFC4405? -MSK </pre> Murray S. Kucherawy 2012-02-17T19:13:27 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.smtp