It appears that what Norton is doing is allowing the SMTP commands
that define the sender and recipients to pass through to the SMTP
server, so that it can synchronously report any errors in those
commands (e.g., and invalid recipient). Then it resets the connection,
collects the body of the message, and saves it for later. When you close
the connection, it collects all the saved data, replays the commands to
define the sender and recipients (which it expects to succeed based on
the previous attempt), sends the data for the body of the message this
time, and really closes the connection.
Of course, there can still be failures when sending the body of the
message, such as the server's disk being full. I have no idea how
they handle such failures.
So, this isn't as bad as I feared, but it's still somewhat questionable.
And I'm sure there's some error cases that it won't handle well.
Tell me again, how is this causing you problems?
It looks like the connection to the server is made when you call
Transport.connect, and the connection is closed when you call
Transport.close. It's just that all the interesting work isn't done
when you call Transport.sendMessage, but instead is delayed until
you call Transport.close.
Artur Silveira da Cunha wrote on 11/03/2010 06:19 PM:
> Hi,
>
> My thanks about your interventions concerning this problem.
> .
> I agree that it seems the Norton feature behaves like it is an SMTP server relay
> and its behavior is different from the SMTP client. Looking how it works it
> seems some bugged work, mainly because the emails are flushed only when the
> connection is closed. For me this forbidden the usage of Transport connection to
> send more than one email. .
>
> I take some time to create a small program that creates emails to permit an easy
> check of the results. You can parameter:
> - smtpServer
> - toAddress
> - fromAddress
> - subjectText body
> - #emails
>
> I include in this email the source program and the packet captures where the
> Norton feature "is activated" and "not activated".
>
> You will find:
> SimpleSender.java - the source program
> SimpleSender.class - java compiled
> nortonStopped.pcap - Wireshark capture of SimpleSender execution with 3 emails.
> The Norton feature "Protection du courrier electronique"* is OFF. We see that
> emails are sent in a synchronous way.
> nortonActivated.pcap - Wireshark capture of SimpleSender execution with 3
> emails. The Norton feature "Protection fu courrier electronique"* is ON. We see
> that that the headers are sent first and the body are sent when "tr.close" is
> reached!!!.
>
> Note: Concerning these 2 tests, I receive in my Thunderbird not all the emails.
> I don't know if they are lost or if they have been deleted by the firewall in my
> 'to' address. Tomorrow I will look this more deeply.
>
> I will follow your opinion and try to contact Symantec and perhaps they will
> reply!!!
>
> Regards
>
> Artur
>
> * Norton French version: Protection du courrier electronique. In english: Email
> protection ???
>
> Le 03/11/2010 23:35, Bill Shannon a écrit :
>> martijn.list wrote on 11/ 3/10 01:25 PM:
>>>> But when I activate the "2010 Norton Internet Security" the behaviour
>>>> changes, where with the same lengthen or small emails, the
>>>> t.sendMessage() is no more synchronous and it returns in a fast way. My
>>>> test flow of about 30 messages is very fast executed. During this loop,
>>>> the Wireshark spy show that only the email headers for 30 emails are
>>>> sent to the smtp server. It is only when I "close" the transport
>>>> connection that all the "30 body email contents" are flushed from the XP
>>>> to the smtp server. I could check later in my receiver thunderbird that
>>>> I could found all emails.
>>>
>>> My experience in the past (a couple of years ago) is that virus scanners
>>> act as a SMTP 'man in the middle'. The email sent from an email client
>>> is not directly sent to the external SMTP server. The message is
>>> intercepted first then scanned and then forwarded to the real SMTP
>>> server. What could happen in your case is that the email is received
>>> locally by Norton. Because this happens locally, it's much faster than
>>> sending it to the remote SMTP. Norton then scans the message and sends
>>> the message to the remote SMTP. This will take some time, roughly the
>>> same time it takes to send an email when Norton is disabled. I'm not
>>> sure whether this is what happens in your case but most virus scanner
>>> work this way.
>>>
>>> Kind regards,
>>>
>>> Martijn Brinkers
>>
>> What I expected is that the virus scanner would scan the message
>> as it passed through, preserving the original conversation with the
>> mail server, but just slowing it down while it performed the scan.
>>
>> If instead it's acting as a mail server itself, queuing all the messages
>> until they're scanned, and then sending them on, you lose the ability to
>> get synchronous errors from the real mail server. That seems like a serious
>> design error in these products.
>