RFC 821, (SMTP).... The authority???

[Tiger Shark]

I have been having a problem with a major high speed ISP in that some of their emails inbound are being blocked by my firewall - in accordance with RFC 821, (SMTP), because they are sending line lengths in the data portion of the transaction that exceeds 1,000 characters without a CR/LF. Testing proved that they were exceeding 2,000 characters and I gave up at that point.

The ISP in question does not handle it's own email system.... .... so we had a conference call and I was told that it wasn't their problem.... Then we reproduced the issue for them that showed that some of their servers are compliant and some aren't. Then I found further evidence that the ISP in question was causing issues for others with my make/model of firewall for the same reason and it all started in July which is about when our issues were brought to my attention.

So, today I heard - _off_ the record - that this ISP does no enforce RFC 821 but, rather, they use RFC 822 as their standard. So I take a quick look:-

RFC 822 is the RFC for the "Standard for ARPA Internet Text Messages" and supercedes RFC 733. I cut to the quick and looked in the syntax section and there are none of the basic SMTP commands included, (HELO, RCPT TO, etc.). There are some equivalent commands for some of the data fields but that's somewhat academic. Furthermore, there is no reference to the 1,000 character limit without a CR/LF or any other reference to a "line break" etc.

Now, (and I'm already pretty sure of the answer but I'd like someone else's opinion who has some understanding of this and the relation to the various RFC's), I understand that SMTP is a text based protocol... BUT.... can anyone sensibly impose RFC 822's rules over and above the rules laid down in RFC 821 or am I being bullshitted by a major company, (the email provider not the ISP), in the hope I will shut up......

[EDIT]

Ok, I found RFC 2821... But I quote from it:-

This document is a self-contained specification of the basic protocol
for the Internet electronic mail transport. It consolidates, updates
and clarifies, but doesn't add new or change existing functionality
of the following:

- the original SMTP (Simple Mail Transfer Protocol) specification of
RFC 821 [30],

So.... They can't use that one either....

[/EDIT]

Thoughts?

[HTRegz]

Hey Hey,

Not sure if this will be of any help to ya or not but it seems that GroupWise has some problems staying within the 1000 character line limit.

Source: http://www.cit.cornell.edu/computer/...groupwise.html

Some e-mail client programs can be configured (or are configured by default) to send each paragraph as one long line. Some e-mail systems such as Groupwise (and apparently Lotus Notes), have a single setting in the server (the Message Transfer Agent, which may include a SMTP gateway) which either wraps all outgoing e-mails of all users to a particular line length, or sends all e-mails of all users with each paragraph as an arbitrarily long line (unless the user manually sets the line length by pressing "enter"). In neither case does the user control this single, system-wide, setting. Nor may the server's wrapping correspond to what they see on screen when writing.

Arbitrarily long lines can be sent within SMTP standards using the "quoted-printable" MIME type.

If such arbitrarily long lines are sent as plain text, then the 1,000 character limit of SMTP may be reached and the sending client or system may wrap the line arbitrarily there, or may send it out longer than 1,000 characters. If this happens, a recipient SMTP server may reject it, or break the line. In one instance a plain text e-mail from Groupwise 4.2 exceeded the 1,000 character per line limit. That paragraph, of 1,253 characters was broken in mid word by a SMTP server just before the 1,000th character. This and later versions of Groupwise are used in a significant number of VET institutes, where the system is valued for many functions apart from its Internet e-mail capabilities

Also the postfix configuration file let's you specify the line length it uses... It's default is 990 but this can be changed (smtp_line_length_limit variable) and in older versions actually set to 2048...

Also I'm wondering (not sure if it applies.. but I'll mention it anyways.. RFC 1652 ...

it states

Although SMTP is widely and robustly deployed, various extensions
have been requested by parts of the Internet community. In
particular, a significant portion of the Internet community wishes to
exchange messages in which the content body consists of a MIME
message [3] containing arbitrary octet-aligned material. This memo
uses the mechanism described in [5] to define an extension to the
SMTP service whereby such contents may be exchanged. Note that this
extension does NOT eliminate the possibility of an SMTP server
limiting line length; servers are free to implement this extension
but nevertheless set a line length limit no lower than 1000 octets.
Given that this restriction still applies, this extension does NOT
provide a means for transferring unencoded binary via SMTP.

To me that means that servers using this extension would pretty much have to exceed the 1000 octet limit...

Peace
HT

[Tiger Shark]

It's quite possible that HT is a genius.....

I ran a packet capture on my mail server and sent it an EHLO. It responded with the 8BITMIME keyword....

What is happening is that domains that send an EHLO _and_ have a message longer than 1000 characters are sending the message encoded in 8 bit MIME which, as noted by the venerable Mr. Regz, does not require the lines to be broken into any specific chunks. My firewall isn't capable of understanding the fact that since the 8BITMIME was returned that it shouldn't enforce the 1000 character limit it should under RFC 821, so it does.... and the mail fails.

Neither the firewall nor the mail server, (IIS 5.0), are configurable from the normal configuration screens to allow such transactions to go unmolested. However there is a way to have IIS 5.0 stop advertising that it will accept an 8 bit MIME transmission. For the benefit of others the information can be found here. It's a pain but it works. A subsequent packet capture indicates that the 8BITMIME keyword is no longer returned in response to an EHLO.

I am awaiting some tests to arrive but I am pretty confident that HT pointed me exactly where I needed to go - Thanks HT.

[HTRegz]

Hey Hey,

Glad to be of assistance. Throw up a quick reply when you get the results of your tests and give us the good ol' thumbs up or thumbs down.

Peace,
HT

[Tiger Shark]

This is getting funnier now....

Testing is ongoing because the ISP has numerous servers and while they claim they are all configured the same we have already proved to them that they are not. We have, however, had one success and one failure.

Aside from this the ISP has informed us that it does not comply with RFC 821 and have no intention of doing so.

This caused me to dig some more.

RFC 821 was changed from an RFC to an STD. An STD is a standard..... ie, as far as I can see, it is _the_ way it is done. However, STD 821 has been obsoleted by RFC 2821. I quote from RFC 2821:-

This document is a self-contained specification of the basic protocol
for the Internet electronic mail transport. It consolidates, updates
and clarifies, but doesn't add new or change existing functionality
of the following:

- the original SMTP (Simple Mail Transfer Protocol) specification of
RFC 821 [30],

In their most recent communication they did not re-iterate that they are RFC 822 complaint which, as far as I can see has absolutely nothing to do with SMTP but we have requested that we have their statement of non-compliance in writing.

If they aren't going to comply with the standard and they aren't going to comply with the RFC that obsoleted the standard but did not change it, (and maintains the same language regarding the 1,000 character limit), what the hell else could they sensibly claim to be compliant with for Simple Mail Transfer?

This is beginning to peeve me because I can see the old "Listen, I'm Mr. HUGE company and you don't matter to us. Your problem doesn't cause us sufficient problems for us to do anything about it - Goodbye"..... Which leaves my ass swinging in the breeze with even though I am convinced they are wrong......