http://permalink.gmane.org/gmane.ietf.smtp hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.smtp/9705 <pre> --On Tuesday, May 07, 2013 22:05 +0200 "Rolf E. Sonneveld" &lt;R.E.Sonneveld&lt; at &gt;sonnection.nl&gt; wrote: Let me say what may be the same thing a little differently. The delivery MTA ("receiving server") pretty much has to know all of the domains under which it will receive mail. Certainly that is a necessity for any sort of rewriting. If that server rewrites things incorrectly, or fails to account for the side-effects of rewriting, various bad things will happen. The effects on signed headers or fancy attempts to match header information with additional (non-address, non-MX) information in the DNS (including, but not limited to SPF and DKIM) are just some of those bad things. john _______________________________________________ ietf-smtp mailing list ietf-smtp&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-smtp </pre> John C Klensin 2013-05-08T12:39:17 http://permalink.gmane.org/gmane.ietf.smtp/9704 <pre> +1 Agreed, with only one remark: the receiving server that rewrites the domainpart of RFC5321.MailFrom and/or RFC5322.From before performing SPF and/or DKIM verification, loses the ability to _reliably_ perform SPF and/or DKIM verification after rewriting. /rolf _______________________________________________ ietf-smtp mailing list ietf-smtp&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-smtp </pre> Rolf E. Sonneveld 2013-05-07T20:05:48 http://permalink.gmane.org/gmane.ietf.smtp/9703 <pre> Well, that was pretty unanimous. Thanks to everybody who answered! hp </pre> Peter J. Holzer 2013-05-07T12:56:35 http://permalink.gmane.org/gmane.ietf.smtp/9702 <pre> Back in 1987 when the DNS was young, CNAMEs were invented to describe short nicknames for long host names, or as a transition aid when a host's name was changing. The rule for SMTP was that if you saw a CNAME you should rewrite it to the CNAME's target, since the CNAME was just a nickname for the host's real name. These days, perhaps 1% of CNAMEs are used that way, and the other 99% are used to do long term DNS management, by allowing a name in one part of the DNS tree to alias to a name somewhere else to outsource the management of the first name to the second. In this usage, rewriting CNAMEs is obviously not a good idea. While you will still find people who insist that you should rewrite a CNAME in a mail transaction (do not ever, EVER, ask this questionon the dnsext list) they are wrong. RFC 5321 still says that the HELO/EHLO name has to resolve directly to an A or AAAA, not a CNAME. I don't know if anyone pays any attention to that. R's, John _______________________________________________ ietf-s</pre> John Levine 2013-05-06T14:25:48 http://permalink.gmane.org/gmane.ietf.smtp/9701 <pre> On May 6, 2013, at 2:43 PM, Bart Schaefer &lt;barton.schaefer&lt; at &gt;gmail.com&gt; wrote: +1. CNAMEs (or NSes) at the DNS level shouldn't affect anything at the SMTP level other than by the MX and address records returned by the resolver. (Though some software used to - and likely still does - rewrite addresses in this way.) Cheers, Steve _______________________________________________ ietf-smtp mailing list ietf-smtp&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-smtp </pre> Steve Atkins 2013-05-06T14:01:25 http://permalink.gmane.org/gmane.ietf.smtp/9700 <pre>http://cr.yp.to/im/cname.html He is wrong in his interpretation of the spec, but correct in the conclusion. All features of "Canonicalisation" can be handled more effectively with current MX records, and by having the receiving server correctly recognise all of the names for which it's responsible. Cheers, Sabahattin _______________________________________________ ietf-smtp mailing list ietf-smtp&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-smtp </pre> Sabahattin Gucukoglu 2013-05-06T13:54:20 http://permalink.gmane.org/gmane.ietf.smtp/9699 <pre>The relay should not rewrite the address. The receiving server can treat the address any way it wants to. _______________________________________________ ietf-smtp mailing list ietf-smtp&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-smtp </pre> Bart Schaefer 2013-05-06T13:43:41 http://permalink.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://permalink.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://permalink.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://permalink.gmane.org/gmane.ietf.smtp/9695 <pre>Hi Timo, On 11 Apr 2013, at 20:10, Timo Sirainen &lt;tss&lt; at &gt;iki.fi&gt; wrote: (I have limited Internet connectivity, so might have missed a part of the discussion. My apologies if this was already discussed.) If you want to return extra information on DATA, I suggest you put it after the Enhanced Status Code (if any), as many response parsers are expecting Enhanced Status Codes to come first. E.g.: 250 2.0.0 [localcopy] Message accepted Or 250 [localcopy] Message foo is on its way. _______________________________________________ ietf-smtp mailing list ietf-smtp&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-smtp </pre> Alexey Melnikov 2013-04-12T09:16:24 http://permalink.gmane.org/gmane.ietf.smtp/9694 <pre> Isn't this sort of advice already passed around by a number of email clients as the Fcc: (file carbon copy) header? Yes, that header is typically removed by the client before message submission, but perhaps a reasonable approach here is for the server to advertise at EHLO that it supports an Fcc extension. The client can then choose to (a) include the Fcc to ask the server to store the mail, or (b) store the mail itself (locally or by IMAP) and omit the Fcc, or even (c) store the mail itself and also assert something like Fcc: /dev/null to force the server to discard its copy. _______________________________________________ ietf-smtp mailing list ietf-smtp&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-smtp </pre> Bart Schaefer 2013-04-11T21:54:04 http://permalink.gmane.org/gmane.ietf.smtp/9693 <pre> I tend to agree that this functionality should be configured server side using some external means (e.g. web UI) instead of doing it in the SMTP protocol. Otherwise it adds more complexity than necessary. All I really want is for an SMTP client to know whether the local copying happened or not. Even if Gmail implemented a configuration flag to disable the behavior, it wouldn't solve what I'm trying to solve. I like that behavior. I want to make it more popular, not less popular. To do that would require making it easy for clients to support it. If the total amount of code to change in both server and client side is just a few lines, and the gain would be to avoid re-uploading the mail, I think it would quickly get popular. (As opposed to BURL, which requires a ton of new code and a whole new way of doing the submission.) Sure, I agree. A single flag in some reply would be ideal solution for everyone I think, unless it breaks something I didn't realize could cause breakage. My IMAP-specific ideas were </pre> Timo Sirainen 2013-04-11T19:10:48 http://permalink.gmane.org/gmane.ietf.smtp/9692 <pre>On 11/04/2013 16:07, John C Klensin wrote The problem is always that users are thick, so automating it would be a good thing Personally, I'd go for a simple and crude method - have a standardised response in the 250 after DATA. If the client understands it, you win. If it doesn't, you lose nothing over the current situation 250 2.0.0 Ok: queued as 6AA4E3C6224 [copiedto:sent] No negotiations needed, trivial server-side programming, and simple client-side programming. If the server was going to support a more complex method, they'd certainly support an option to turn off server-side copying for people who want that. If the client was going to support a more complex method, it can handle just skipping the IMAP APPEND stage. - Paul Smith Computer Services Tel: 01484 855800 Vat No: GB 685 6987 53 _______________________________________________ ietf-smtp mailing list ietf-smtp&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-smtp </pre> Paul Smith 2013-04-11T15:25:07 http://permalink.gmane.org/gmane.ietf.smtp/9691 <pre> --On Thursday, April 11, 2013 12:07 +0300 Timo Sirainen &lt;tss&lt; at &gt;iki.fi&gt; wrote: I wasn't suggesting changing the current default behavior at all. Instead, I was suggesting that they could add a new and thoroughly optional flag to the profile that would default to the current behavior but that would, if set by the user, disable the copying of the outgoing message. Current users and users favored the copies wouldn't need to do a thing. I think you've missed my point. I think that what you are looking for is a configuration option on either the client or the server, not a protocol matter. Trying to make a protocol change to avoid configuration options -- especially when that protocol change has to affect both SMTP and IMAP in the general case-- is unwise architecturally and philosophically. More important from your point of view, if you don't believe Google would implement a configuration flag that could disable the message-copy behavior, why is it reasonable to believe that they would implement a prot</pre> John C Klensin 2013-04-11T15:07:23 http://permalink.gmane.org/gmane.ietf.smtp/9690 <pre> Always a problem with protocol upgrades :-) I wonder if it makes sense to add a parameter to the EHLO keyword giving the default, e.g. GMail would say: 250-LOCALCOPY YES and the client could state its preference which overrides the default: MAIL FROM:&lt;...&gt; LOCALCOPY=YES MAIL FROM:&lt;...&gt; LOCALCOPY=NO I wonder how to handle per-user localcopy settings. I think you would need a command to query in that case. e.g. an EHLO reply like 250-LOCALCOPY USER The LOCALCOPY command could retrieve both the option's state and the disposition of the last MAIL transaction, if there was one. Ugh I don't like the mixture of 250 5.2.2 :-) There is the potential to fix a long-standing nastiness, which Lemonade missed: a good implementation could ensure that message submission and saving a local copy either both fail or both succeed. Speaking of Lemonade, I wonder about combining with BURL ... MAIL FROM:&lt;...&gt; LOCALCOPY=MOVE ? Getting into dangerous over-engineering territory. Tony. </pre> Tony Finch 2013-04-11T09:31:41 http://permalink.gmane.org/gmane.ietf.smtp/9689 <pre> Gmail is unlikely to implement that, since that would require changing their current default behavior and breaking users' configuration. So it's not going to get wide adoption. EHLO advertisement itself isn't enough, since this may be a user-specific setting and I don't think clients re-EHLO after AUTH. Something that could work is something like: C: EHLO .. S: 250-LOCALCOPY S: .. C: AUTH .. S: .. C: MAIL FROM &lt;..&gt; (LOCALCOPY) S: 250-LOCALCOPY S: 250 2.1.0 Ok Where the above server notifies that the user will get a local copy, while: .. C: MAIL FROM &lt;..&gt; (LOCALCOPY) S: 250 2.1.0 Ok Here the server doesn't store a local copy. Except if the local copy saving fails (e.g. user over quota), should the server now also fail the DATA? So maybe instead: C: MAIL FROM &lt;..&gt; (LOCALCOPY) S: 250 2.1.0 Ok .. C: DATA C: .. S: 250-LOCALCOPY S: 250 2.0.0 Ok: queued as 6AA4E3C6224 That would also allow more complexity like: 250-LOCALCOPY 2.0.0 Ok 250-LOCALCOPY 5.2.2 You are over quota 250-LOCALCOPY 2.0.1 IMAP 1234567</pre> Timo Sirainen 2013-04-11T09:07:01 http://permalink.gmane.org/gmane.ietf.smtp/9688 <pre>Hi Timo, At 16:33 10-04-2013, Timo Sirainen wrote: Their recommendation is for the mail client not to save sent messages to the (IMAP) server. The idea of suppressing the IMAP APPEND may work. I would not suggest doing it as it can affect other functionality that is not currently available. Regards, -sm _______________________________________________ ietf-smtp mailing list ietf-smtp&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-smtp </pre> SM 2013-04-11T06:23:52 http://permalink.gmane.org/gmane.ietf.smtp/9687 <pre>wfm. d/ On 4/10/2013 5:12 PM, Tony Finch wrote: </pre> Dave Crocker 2013-04-11T01:52:07 http://permalink.gmane.org/gmane.ietf.smtp/9686 <pre> --On Thursday, April 11, 2013 01:12 +0100 Tony Finch &lt;dot&lt; at &gt;dotat.at&gt; wrote: Yes. But it seems to me that the problem Timo is trying to solve involves submission via Gmail and not being able to turn off its saving a copy of the sent message. It seems to me that problem doesn't involve the IMAP server at all except insofar as the sending client chooses to send the SMTP message and then use IMAP APPEND or equivalent to put a copy somewhere. It seems to me that problem is easily solved using the well-known maxim: Patient: "Doctor, it hurts when I do xyz." Doctor: Have you considered not doing xyz?" Option 1: Persuade the Gmail folks to allow a profile flag that would _not_ save everything to the /Sent folder but would allow explicit copies to it. Option 2: Fix the relevant client to support a per-submission-server flag that determines whether or not to append copies of outgoing messages to some selected folder. However easy or difficult those options might be, they have the advantage of requi</pre> John C Klensin 2013-04-11T00:59:54 http://permalink.gmane.org/gmane.ietf.smtp/9685 <pre>The proper ESMTP style for this would be (1) an EHLO keyword to say the server supports the feature (2) a MAIL parameter for the client to enable the feature Do you need more signalling than that? I think adding syntax to the message body reply would be a bad idea, since that is usually used to feed back trace info (queue ID). Perhaps you could have a new command to be used (pipelined) after the body to retrieve the IMAP status. Would that make the MAIL parameter redundant? Tony. -- f.anthony.n.finch &lt;dot&lt; at &gt;dotat.at&gt; http://dotat.at/ _______________________________________________ ietf-smtp mailing list ietf-smtp&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-smtp </pre> Tony Finch 2013-04-11T00:12:06 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.smtp