I'm having a bit of an argument with a customer over the command syntax in RFC 2821 that shows command arguments for MAIL/RCPT commands in brackets, i.e.:
Our mail servers reject connections that don't follow the RFC. Am I wrong to do this? This guy certainly thinks so, even after I've cited the RFC and appropriate section, his arguments is "even hotmail does not keep up the standards" and if we ignore them as well. Hotmail at least follows this rule... am I wrong to require the brackets?
his arguments is "even hotmail does not keep
up the standards" and if we ignore them as
It sounds like he's admitting that the RFC is correct, but since Hotmail
will accept "malformed" messages, so should everyone else. He basically
wants you to adjust your server to be more lax so he doesn't have to
adjust his to get in line with the RFC. Depending on your business and
how important mail is you may or may not be able to tell him to fix his
MTA. Personally, if his mail isn't spam I'd lean more toward the "let
it through" side of the argument for the sake of cooperation, though if
he followed the standards there wouldn't be a problem to begin with.
That may be worth pointing out.
Our mail servers reject connections that don't follow the RFC. Am I
wrong to do this? This guy certainly thinks so, even after I've cited
the RFC and appropriate section, his arguments is "even hotmail does not
keep up the standards" and if we ignore them as well. Hotmail at least
follows this rule... am I wrong to require the brackets?
"The" RFC is amusing WRT email. In this case, you are ignoring 3464,
section 2 "Format of a Delivery Status Notification", viz:
Whenever an SMTP transaction is used to send a DSN, the MAIL FROM
command MUST use a NULL return address, i.e., "MAIL FROM:<>".
RFC 1122 (Requirements for Internet Hosts - Communication Layers)
section 1.2.2 (Robustness Principle):
"Be liberal in what you accept, and
conservative in what you send"
Which has done nothing but allow countless Exchange server to HELO with exchange.local and other such idiocy, not to mention contribute to the spam problem.
Every time you try to configure your server for strict parsing to help block spam, you get an email from some admin who doesn't know the first thing about SMTP but wants to know why you're blocking their email.
Nope. His software is either misconfigured or broken.
I'm aware of the be-liberal-in-what-you-accept philosophy (and followed
it for many years, still do in some cases), but no longer think it's
applicable to inbound SMTP. The way I've put it is that the more
someone's SMTP sender looks like a spam source -- say, missing rDNS or
HELOing as something invalid or not sending valid SMTP commands -- the
more likely it is that someone's mail system will reject, defer or
quarantine the traffic. So it's in everyone's interest to make sure
their outbound SMTP traffic is as compliant with de jure and de facto
requirements as they possibly can -- doubly so given that this is
quite often something as simple as fixing a HELO string or creating
a single PTR record or something similar.
The best reason I've come up with for rejecting mail from software so totally
brain-dead that they can't get the < > around an address right is this:
If they botch this, they've probably botched a bunch of other stuff, and
accepting mail from them is almost certain to lead to grief once you send the
'250 OK' after DATA.
If they couldn't get < > *around* the address in the MAIL FROM:, what makes
you think the address is valid? Where does any ensuing bounce end up?
And more importantly, can you find out what crapware is that brain-dead and
let us know, so that those of us who believe in enforcing standards can shun it?
> Our mail servers reject connections that don't follow the RFC. Am I
> wrong to do this?
Seth,
RFC 1122 (Requirements for Internet Hosts - Communication Layers)
section 1.2.2 (Robustness Principle):
"Be liberal in what you accept, and
conservative in what you send"
I would say this quotation of RC1122 1.2.2 seems a little bit out of context.
"being liberal in what you accept" in terms of such egregious errors
as a mailformed
destination address does not mean you necessarily pass the message on.
The robustness principal doesn't say you have to correct the error and
accept the message,
continuing normally, as if there was no error, it says you're prepared for it
To be robust, your SMTP server implementation must not crash if a user
omits the
angle brackets, it must be prepared to accept the malformed text, and
respond accordingly,
I.E. Refuse the message, with an error response, if it doesn't
recognize the proper destination
format.
The following paragraph of RFC1122 states:
"Software should be written to deal with every conceivable error, no matter how
unlikely; sooner or later a packet will come in with that particular
combination of errors
and attributes, and unless the software is prepared, chaos can ensue.
In general, it is best to assume that the network is filled with
malevolent entities that will
send in packets designed to have the worst possible effect. This
assumption will lead to
suitable protective design, although the most serious problems in the
Internet have been
caused by unenvisaged mechanisms triggered by low-probability events;
mere human malice would never have taken so devious a course!
"
