We use the jaxax.mail interface to send email with our actual product
and we have had some returns from customers where they had problems with
email servers the emails goes to error in another cases that the emails
servers seems saturated, etc.
The big problem is that the returns originates from users sending
emails, these errors comes from exchanges between their computer and an
external email server that can be localized indoors or outdoors. From an
user point view an SMTP exchange don't concerns them. Our support team
reacts in the same way how to understand the user problem.
They ask me to me to harden a little more the email function, they could
check in some cases that the email servers could be saturated. Perhaps
including include "burst mode with parameter sleeping time", "parameter
sleeping time between each email".
While studying the problem I find that we are using the static Transport
function that opens a connection for each sent email and in the case
with many email to send, we could face an uncontrolled number parallel
connections with the email server.
I thought that if we limit the number of connections with the email
server could be a way to regulate the exchanges between the email client
and the email server. A rate can be easily calculated and if a user has
many emails to send, he can also wait more time to end its work. And
problems be more easily understand while comparing "slow email
transfers" with errors like network saturation, email server crashes, etc.
My actual situation is the following:
- use the old way of static jaxax.mail sendTransport
Consequences: too many open connections returns from the email
server, we will continue to have support calls from our users
- limit the number of connections to send emails
- it could be a good way to avoid email server saturations, the speed
transfer be adapted with the real capability of the email server. But
this only works if antivirus is not checking the email transfers and
worsts the relay antivirus stores the email body and attachments while
waiting for the "bye" from the user side. In the case of lengthen emails
what is the buffer capability of the antivirus relay and in the case of
errors during the email contents transfer, these errors can't be
returned to the user side.
In conclusion, I will stay with the static sendTransport way and perhaps
adapt a regulated sleeping time between each connection, but adequate
probes are to be created.
artur
Le 04/11/2010 04:44, Bill Shannon a écrit :
> 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.
>>
>