Our MTA does RFC5321 syntax check on emails. When I worked on EAI, I noticed many opensource MTAs will in fact accept anything, so as long as they accept 8BITMIME, you can throw at them EAI and they will take it, they don't even need to advertise SMTPUTF8.
There has been little pain for the people that use invalid syntax, fixing this requires the security needs are greater than the inconvenience a group experience (especially when it is not their fault for purchasing devices that the manufacturer is unlikely to understand there is a problem) In fact from my point of view, I notice mainly problems in bounces where the RFC5322.From is set to a bit anything... while it should contain a non null list of email addresses. I want to make sure the people that write to us, have a domain I can write back to. Correcting the syntax at MSA level so the MTA handles compliant emails seems a good strategy. I think the days of accepting crap are slowly going away... cf https://tools.ietf.org/html/rfc7103 https://www.linkedin.com/pulse/20140608094006-86120-the-robustness-principle-and-email On Wed, Feb 3, 2016 at 10:52 AM, Brandon Long <bl...@google.com> wrote: > > > On Tue, Feb 2, 2016 at 5:59 PM, John Levine <jo...@taugh.com> wrote: > >> >return-path address <SRS0=g2..et=OB=example.net=usern...@eigbox.net> >> >rejected by mail1.example.com:25: >> >> > after reading RFC5322 >> >> Um, that's the wrong spec. RFC 5321 describes the rules for SMTP. >> >> >1) Am I correct in believing that two dots with no intervening atext >> >characters are illegal in a return-path? >> >> Yes. The argument of a MAIL FROM is a reverse-path (not a >> return-path), which is a mailbox in < >, and a mailbox can be >> local-part@domain, and an unquoted local part is a string of atoms >> separated by dots, so to be technically correct the local part with >> the two dots should be quoted. I tried sending mail to a double dot >> address at gmail and was surprised to see that they rejected it too, >> so it's a rule that people pay attention to. > > > We rolled out a RFC 5321 compliant parser to smtp in Aug/Sept of last > year, to much gnashing of teeth for a small set of users with some crappy > software. We rolled it back for MSA (just silently replace with the > auth-user), because apparently virtually all embedded devices (security > cameras, mostly) send garbage at MAIL FROM. > > We mostly rolled it out because people would complain that we dropped mail > when instead they were sending from an invalid address that couldn't > receive the bounce. We were seeing a lot of junk, people sending the from > header including comments or display name, multiple addresses separated by > commas, random spaces, invalid hostnames (lots of hostnames with _ in > them). People with their own VERPS or SRS encodings that were invalid were > also in there. > > The top broken address we're seeing is a bad SRS from srs.route.mx, so > some software out there has a crappy SRS impl. > > Brandon > > > > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > >
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
