Thunderbird violates SMTP protocol
hector
protocol.. Here is example of a captured session with TBIRD as a client on a
non-routable address (intranet sub-net) machine.
********************************************************
Wildcat! SMTP Server v6.1.451.9
SMTP log started at Mon, 06 Nov 2006 19:14:50
Connection Time: 20061106 19:14:50 cid: 00007126
SSL Enabled: NO
Client IP: 72.144.114.198 (unknown)
19:14:50 S: 220 winserver.com Wildcat! ESMTP Server v6.1.451.9 ready
19:14:50 C: EHLO [192.168.1.103]
19:14:50 S: 501 Invalid EHLO client address.
19:14:50 C: HELO [192.168.1.103]
19:14:50 S: 501 Invalid HELO client address.
19:14:50 C: MAIL FROM:<xxxx...@xxxxxxxx.com>
19:14:50 S: 503 Send HELO first.
19:14:52 ** Completed
Two problems here with TBIRD
1) It doesn't seem to have an option to to set the client domain name
(ELHO/HELO). It is fixated at using domain literals which will fail when the
TBIRD client is on an intranet subnet, as it was in this case at
192.168.1.103. The outbound machine is at 72.144.114.198.
Using a standard internal network domain literal will immediately violate
RFC 2821 for client domain domain literals requiring to match the IP
address.
What you see above is an advanced SMTP server who did the check and saw that
connecting IP did not match. What most modern MUA software do is use the
FQDN or if it can't it use the local machine computer name. That is what
Outlook, Eudora and other MUAs does - TBIRD does not.
2) Even then, TBIRD completely ignored the SMTP protocol state machine by
ignoring the 501 response codes and continuing with commands like if
"something" is going to change and allow it in. This is a big no-no.
IP Analytics and session behavior like the above can put users at risk in an
increasing modern world of strict SMTP servers like the one above by
erronenously flagging them as spammers or malicious transactions.
Sorry, if I sound harsh, but this is too blatant for the high standards the
TBIRD development team seem to have established. It should fixed. Sorry
if I sound harsh, so I apologize but it pisses me off because I have to
support customers who have begun to use this mail client with a fundamental
mail protocol flaw and I hate passing the buck to others if I can help it.
I hate telling people "its TBIRD problem. Call them!"
So if there is a fix for this let me know.
Thanks
Hector Santos, CTO
http://www.santronics.com
Wildcat! Internet Net Server
Wildcat! Sender Authentication Protocol (WCSAP)
hector
I am only highlighting key points for developers to consider changing:
a) Option to use local computer name
In nsSMTPProtocol.cpp, the GetUserDomainName() needs to read an user
interface option to use the Local Computer Name instead of using the domain
literal as the function is hardcoded to do.
I suggest an option for the SMTP Output Servers Setup with a new checkbox:
[X] Use FQDN, if found, or Local Computer name for HELO/EHLO
You need to remember the RFC is just a "GUIDELINE" and hardcoding it domain
literals creates more problems for client machines are on an intranet.
But using a domain literal, you are forcing middle man proxies to be used.
The HELO/EHLO is historically weak, but not with domain literals. Modern
SMTP server are becoming very strict with matching domain literals and the
connection IP address. We can tell you by our own statistics, over 12% of
all transactions are spammers using bad domain literals. By continuing
in this mode for the user, it puts the user at risk with erroneous blocks
and red flags.
b) Honoring the SMTP state machine.
In all cause the SMTP client must not CONTINUE to a new state when a
negative response is provided at any state. This is clear in the specs:
section 4.1.4
If the EHLO command is not acceptable to the SMTP server, 501, 500,
or 502 failure replies MUST be returned as appropriate. The SMTP
server MUST stay in the same state after transmitting these replies
that it was in before the EHLO was received.
In the same vain, it must not issue a fall back to HELO unless a 500
negative response is provided. The RFC is very clear with this too,
further in the same section 4.1.4:
If the transaction beginning command argument is not acceptable, a
501 failure reply MUST be returned and the SMTP server MUST stay in
the same state. If the commands in a transaction are out of order to
the degree that they cannot be processed by the server, a 503 failure
reply MUST be returned and the SMTP server MUST stay in the same
state.
In short, it should continue to ignore negative responses in the modern era
of SMTP servers paying strict attention to client transactions at the SMTP
level.
TBIRD has gone out of its way to establish new Anti-Spam features for end
users. This current behavior goes against this new level of practice.
Thanks
Hector Santos, CTO
http://www.santronics.com
Wildcat! Internet Net Server
Wildcat! Sender Authentication Protocol (WCSAP)
"hector" <foo...@foobar.com> wrote in message
news:CaudnW03zKjpt83Y...@mozilla.org...
Tony Mechelynck
report at https://bugzilla.mozilla.org/ ?
If you aren't yet registered with Bugzilla, then start with:
- Create a (free) account: https://bugzilla.mozilla.org/createaccount.cgi
- Bugzilla Etiquette: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
- Bug Writing Guidelines: https://bugzilla.mozilla.org/bugwritinghelp.html
Best regards,
Tony.
hector
Jokes to the side, because I simply don't have the time to learn something
new, creating yet another account, follow ups, etc, etc. This is most
likely a short one time visit here. I will just report it here where
developers hang out and let the smart developers handle from there. If a
bug report must be catelogged, I will hope someone else will do it. I have
strong faith in good engineering principles being followed here so I have
no reason to presumed it will be ignored and not addressed in future
versions. :-)
If they need my assistance on finer points of SMTP protocol behavior, I will
be glad to assist. They can email at hsantos AT domain indicated below.
Hector Santos, CTO
http://www.santronics.com
Wildcat! Internet Net Server
Wildcat! Sender Authentication Protocol (WCSAP)
"Tony Mechelynck" <antoine.m...@belgacom.net> wrote in message
news:mvqdncu8Gqbf2s3Y...@mozilla.org...
Michael Lefevre
[snip]
>
> Two problems here with TBIRD
>
> 1) It doesn't seem to have an option to to set the client domain name
> (ELHO/HELO). It is fixated at using domain literals which will fail when the
> TBIRD client is on an intranet subnet, as it was in this case at
> 192.168.1.103. The outbound machine is at 72.144.114.198.
>
> Using a standard internal network domain literal will immediately violate
> RFC 2821 for client domain domain literals requiring to match the IP
> address.
>
> What you see above is an advanced SMTP server who did the check and saw that
> connecting IP did not match. What most modern MUA software do is use the
> FQDN or if it can't it use the local machine computer name. That is what
> Outlook, Eudora and other MUAs does - TBIRD does not.
First you talk about standards, and then "what most modern MUA software
do". Using the local computer name is also a violation. If Thunderbird
gets the domain literal right, then it's actually doing better than things
which just use the computer name. The RFC says the client should send the
FQDN, or if that's not possible, then it should send an address literal.
In cases where the computer submitting the message doesn't know either of
those (which is often the case with Windows desktops behind NAT), there is
no way of complying with the RFC.
Why should the server reject non-matching IP addresses, but accept random
strings which don't have dots in? Aside from the fact that doing one will
only affect Thunderbird, which makes an effort to get it right more of the
time, and the other will block Outlook Express and Outlook, which are far
more widely used?
> 2) Even then, TBIRD completely ignored the SMTP protocol state machine by
> ignoring the 501 response codes and continuing with commands like if
> "something" is going to change and allow it in. This is a big no-no.
This does indeed seem to be rather broken.
> So if there is a fix for this let me know.
Not much chance of that unless you help out with fixing it (not that I'm a
developer)...
--
Michael
hector
"Michael Lefevre" <news+07...@michaellefevre.com> wrote in message
> On 2006-11-07, hector <foo...@foobar.com> wrote:
> [snip]
>>
>> Two problems here with TBIRD
>>
>> ..
>> What you see above is an advanced SMTP server who did the check and saw
>> that
>> connecting IP did not match. What most modern MUA software do is use
>> the
>> FQDN or if it can't it use the local machine computer name. That is
>> what
>> Outlook, Eudora and other MUAs does - TBIRD does not.
>
> First you talk about standards, and then "what most modern MUA software
> do". Using the local computer name is also a violation. If Thunderbird
> gets the domain literal right, then it's actually doing better than things
> which just use the computer name. The RFC says the client should send the
> FQDN, or if that's not possible, then it should send an address literal.
> In cases where the computer submitting the message doesn't know either of
> those (which is often the case with Windows desktops behind NAT), there is
> no way of complying with the RFC.
Right, there are standards and then BCP (best current practices).
The point I was making is that by using the Domain Literal, it has raised
the bar for tighter scrunity and in today's environment, TBIRD will have
more difficulty than not.. Using it is not incorrect, it is when it is
ignorant (in a nice way) of the fact it is using a 192.* or 10.* sub net
which will very likely fail the IP test at the application level.
Other MUAs recognize this, thus the BCP is to err on the safe say with the
local computer name.
Related issues was recently (last year) discussed in the SMTP working group.
I will raise the issue again with Klensin for possible RFC 2821bis
considerations.
But from an application standpoint, TBIRD needs to make it optional
otherwise it will hinder installations on desktops behind NATs thus
requiring additional network preparations.
> Why should the server reject non-matching IP addresses, but accept random
> strings which don't have dots in? Aside from the fact that doing one will
> only affect Thunderbird, which makes an effort to get it right more of the
> time, and the other will block Outlook Express and Outlook, which are far
> more widely used?
Historistically any HELO/EHLO validation is unreliable. However, when a
domain literal is presented then it opens itself up for reliable validation.
This is the modern direction with higher security SMTP servers. So its
better to not use a domain literal when its knows the peer address is not
going to be the same or if it can't figure that out for itself, then allow
for user configuration.
Also consider systems that are now using SPF which does a domain::IP
association check for the return path domain (MAIL FROM) and possibly the
HELO/EHLO domain (per the official RFC). The rule of thumb is if you see a
domain, then it must be a valid domain or literal. Otherwise, it falls back
to basically no validation done (legacy operations).
>> 2) Even then, TBIRD completely ignored the SMTP protocol state machine by
>> ignoring the 501 response codes and continuing with commands like if
>> "something" is going to change and allow it in. This is a big no-no.
>
> This does indeed seem to be rather broken.
Right, I can probably understand if the server indicated it was using the
PIPELINING extension but it did not present that information In the end,
TBIRD acts or behaves as a bulk mail sender and this is a clear
indicator/red flag for spam attacks when it ignores any such pipelining
activation and all negative responses. So this is probably a more important
fix than the IP/DOMAIN issue. :-)
>> So if there is a fix for this let me know.
>
> Not much chance of that unless you help out with fixing it (not that I'm a
> developer)...
Given my lack of time, the best I can do is look at the code and suggest the
changes to make and pass it on the cog engineer here working on this
component. Is this sufficient and is this the proper avenue to suggest the
special code changes?
Wayne Mery
> Hi Michael,
>
> "Michael Lefevre" <news+07...@michaellefevre.com> wrote in message
>
>> On 2006-11-07, hector <foo...@foobar.com> wrote:
>> [snip]
>>> ignoring the 501 response codes and continuing with commands like if
>>> "something" is going to change and allow it in. This is a big no-no.
>> This does indeed seem to be rather broken.
>
> Right, I can probably understand if the server indicated it was using the
> PIPELINING extension but it did not present that information In the end,
> TBIRD acts or behaves as a bulk mail sender and this is a clear
> indicator/red flag for spam attacks when it ignores any such pipelining
> activation and all negative responses. So this is probably a more important
> fix than the IP/DOMAIN issue. :-)
>
>>> So if there is a fix for this let me know.
>> Not much chance of that unless you help out with fixing it (not that I'm a
>> developer)...
>
> Given my lack of time, the best I can do is look at the code and suggest the
> changes to make and pass it on the cog engineer here working on this
> component. Is this sufficient and is this the proper avenue to suggest the
> special code changes?
the proper venue to report a bug and/or suggest code changes is to create/file a
bug. Doing so doesn't obligate one to look at the code, patching or even
recommending how to fix (even if you know how) - though coders are welcome and a
suggested patch is icing on the cake for a developer.
creating a bz account is nothing more than a pwd and your email address
https://bugzilla.mozilla.org/createaccount.cgi
Mike Cowperthwaite
I think bug 244030 is already addressing at least part of the issue
you're reporting.
Wayne Mery
> I think bug 244030 is already addressing at least part of the issue
> you're reporting.
oops, I forgot this IS a dev forum.
Hector, if you want to see the resolution of the bug or follow it's progress
you'll need to cc: yourself in the bug, commenting does not automatically add you.
hector
"Wayne Mery" <vsee...@lehigh.edu> wrote in message
news:9KidnXEz8uuNZc3Y...@mozilla.org...
hector
sufficiently. The other is how TBIRD ignores the state machine negative
response codes. Do you know is there is an existing or related bug already
catalogged? I don't want to duplicate it.
---
HLS
"Wayne Mery" <vsee...@lehigh.edu> wrote in message
news:9KidnXEz8uuNZc3Y...@mozilla.org...
Tony Mechelynck
... and, hector, "bug 244030" means
https://bugzilla.mozilla.org/show_bug.cgi?id=244030
You can view it without a Bugzilla account but you need one to comment.
Best regards,
Tony.
Mike Cowperthwaite
> "Wayne Mery" <vsee...@lehigh.edu> wrote in message
> news:9KidnXEz8uuNZc3Y...@mozilla.org...
>> On 11/7/2006 3:06 PM, Mike Cowperthwaite wrote:
>>> I think bug 244030 is already addressing at least part of the issue
>>> you're reporting.
>> oops, I forgot this IS a dev forum.
>>
>> Hector, if you want to see the resolution of the bug or follow it's
>> progress you'll need to cc: yourself in the bug, commenting does not
>> automatically add you.
>
> sufficiently. The other is how TBIRD ignores the state machine negative
> response codes. Do you know is there is an existing or related bug already
> catalogged? I don't want to duplicate it.
Could you bottom-post in these newsgroups, please?
I tried searching the Networking:SMTP component, for "501" OR "block" OR
"state", but didn't locate anything. "error" had a few matches but none
that sounded like this one. I'd just open a new bug, if I were you;
feel free to add mc...@well.com to the CC list.
hector
Sorry, I'm been cyberspacing and designing mail related products for far too
long to have any regrets about how you feel whether I should top, inline or
bottom feed you.
Thanks
---
HLS
"Mike Cowperthwaite" <mc...@well.com> wrote in message
news:CO6dnQ4PdcAAlM_Y...@mozilla.org...
Tony Mechelynck
[...]
> Sorry, I'm been cyberspacing and designing mail related products for far too
> long to have any regrets about how you feel whether I should top, inline or
> bottom feed you.
>
> Thanks
>
> ---
> HLS
It's not a question of regrets but a question of netiquette. On the Mozilla
newsgroups (with the exception of the accessibility newsgroups),
bottom-posting (or inter-posting when replying to large, complex posts) is the
rule. Everyone should comply, no matter how long (s)he has been "designing
mail-related products".
Best regars,
Tony.
hector
Thanks
---
HLS
"Tony Mechelynck" <antoine.m...@belgacom.net> wrote in message
hector
"Mike Cowperthwaite" <mc...@well.com> wrote in message
> I tried searching the Networking:SMTP component, for "501" OR "block" OR
> "state", but didn't locate anything. "error" had a few matches but none
> that sounded like this one. I'd just open a new bug, if I were you; feel
> free to add mc...@well.com to the CC list.
The new bug #360118 was added. I hope it was done to yours or bugzilla
standards. :-)
Thanks
--
Tony Mechelynck
THE
AS
DO
ROME
IN
hector wrote:
> Worry about the product in hand and not my habits.
>
> Thanks
>
> ---
> HLS
>
>
> "Tony Mechelynck" <antoine.m...@belgacom.net> wrote in message
[...]
Leonidas Jones
> ROMANS
> THE
> AS
> DO
> ROME
> IN
Tony, can I steal that??
Lee
Tony Mechelynck
Go ahead, I stole it from someone else, and I don't even remember who.
Best regards,
Tony.
hector
> Leonidas Jones wrote:
It would of been cute, if it was correct. I was scratching my head
wondering if you just a wannable net cop moron or didn't know what they hell
you were writing.
You're missing a "WHEN" and another "DO"
The phrase is:
"When in Rome, do as the romans do!"
and it would of been enough to just say in most conversations:
"When in Rome........"
and most people will grasps its meaning. Then if you had did that, I would
of said,
"TOUCHE! Bravo, Tony, Bravo!"
<g>
---
HLS
Tony Mechelynck
Mr. Hector the nitpicker, I should have quoted it in my native language. So
please delete my previous statement: here is what it should have been:
ROMAINS
LES
COMME
FAITES
ROME,
À
...which translates as "In Rome, do as the Romans", a perfectly valid English
sentence, if maybe somewhat old-fashioned in its form, notwithstanding the
fact that the Concise Oxford Dictionary of English (ISBN 0-19-860441-6, ©
1998-2001) quotes it the way you do. However, I don't have the edition
published when _I_ learnt English, in the Sixties.
And by the way, since you're so uptight on English syntax, let me point in my
turn: It would *have* been cute, if it *had been* correct... wondering if you
*were*... what *the* hell... it would *have* been enough *just to* say... most
people would *grasp*... if hou had *done* that, I would *have* said:
*/Touché!/* -- the latter in italics and with an e-acute, since it is a French
word not adapted to English orthography (where it would be, but isn't,
"Tooshay" or else, translated, "Touched" or, better, "A hit!"; maybe even
"Bull's-eye").
Best regards,
Tony.
John Sheu
-John Sheu