[quote user="Thomas R. Stephenson"]
Are you testing sending to a remote address?  Authentication is not required when you are delivering mail to an account on the server.
[/quote]

Ah, stupid of me. It was test mail to myself (on same provider), sorry.

[quote user="Thomas R. Stephenson"]
Nothing about any anti-virus software even surprises me anymore.  I'm not sure the people that do anti-virus POP3/IMAP4/SMTP proxies have even read the RFC.
[/quote]

I agree. I shouldn’t, and now I don’t use the proxy for SMTP, I will have a closer look at the other as well.

[quote user="Thomas R. Stephenson"]
That depends on the SMTP server software.  However, the username actually could  be in the body of the RFC 2822 message in other places as well since it is generally (but not always) part of the senders email address.
[/quote]

Ah, correct, forgot about that. As you say it can be part of the email address. But also, sometimes, it is only part of the "original address" given by the email provider and is changed by the user to something they want to use, such as: john.doe@etc, i.e. some sort of alias, I don't know what it's called. Then the username is only used at POP & SMTP.

To summarise this thread and what my problem was all about, as I understand it now:

• Some time ago an email I sent "bounced", the AV proxy couldn't connect to my email provider's server. A test email to myself also stopped in the AV proxy. I don’t know the cause.
• I turned off the AV email scanner proxy and changed back to the

  original definitions in Pegasus. This worked. This original SMTP

  definition probably had authentication enabled. I don’t remember if the

  first mentioned SMTP definition using the AV proxy had authentication

  enabled, don’t think so, AVG says that one should use it in the client,

  if needed.

• Later when troubleshooting, I recreated the SMTP definition using the

  AV proxy, as well as recreating the AV proxy settings from scratch.

  This did not work, and I had to use original sans AV.

• When I recreated the SMTP definition for AV proxy above, I enabled

  authentication. I now know that this most probably is the cause to why

  it doesn’t work.

Since I don’t have older logs, and not detailed enough from the first event I don’t know. But it could either be that:

•  When the mail bounced, for some reason, I enabled auth. in the process, and it stopped working, or
• Since it seems the server could use several AUTH mechanisms (as

  Pegasus) and AVG especially mentions CRAM-MD5, it could be that

  something changed on the server side at that event, and I had authentication enabled

  in Pegasus, and suddenly AVG doesn’t work due to changed AUTH mechanism.

Anyhow, outgoing mail isn’t interesting to scan, the memory resident AV will take care of it before, but I have never had any virus.

So, when it comes to questions about authentication etc. I trust you here 100 %, as I always have trusted Pegasus. Having been in the business for so long time, there is so much knowledge behind that program (thanks to David Harris). And with very knowledgeable users as you, it is easy to feel secure when using Pegasus Mail.

Thanks for your comments.

I have a setup with an AV email scanner and using SSL in POP3/SMTP and some weeks ago sending stopped working. If I change back to the original settings (POP3/SMTP definitions) saved, my connections work.

Since I had done nothing (as we all say) and had sent some mail an hour before, I first thought something had changed at the ISP/email provider. But as mentioned original settings, sans AV, worked. I then turned to the AV program and deleted the POP3/SMTP email scanner settings and recreated new ones. Didn't work. I then deleted the POP3/SMTP definitions that used the AV in Pegasus and created new ones. Still don't work. See error from AV and Pegasus below.

I have talked briefly with my email support, but at level 1 they are pretty clueless, and yes they don't give support on AV or individual email clients anyway.

I have looked over at AVG Free (the AV program), but their general recommendation is to add a number of files to the firewall and give them full access and server rights (!). That is nothing I: a) would like to do, and b) see any need for, since the firewall would mention if the program needed access. I already had the two needed; one for updates, and one for the email scanner. And anyhow it worked up until three weeks ago. But adding the 5 extra files as they wished did nothing, of course. So away they went.

Now it starts to get real sad; not an email provider problem (as it seems); Pegasus works without the AV scanner in the definitions; AVG support can’t give any help. I didn’t think of it at first, but obviously since I am using a local port it could be used by something else, but if so, why did that start all of a sudden. And it is certainly not mentioned over at AVG.

The setup that doesn't work is as follows:
AVG 8 Free with Personal Email scanner setup since no plugin for Pegasus. This was not a problem earlier; AVG 7 worked with and without SSL, and AVG 8 worked until some weeks ago. When using SSL I have to setup AVG with my email providers server name and port, activate SSL, and also give it a local port used in Pegasus.

So, in Pegasus it is for POP3:
Server: 127.0.0.1
Port: 5100
User name & password: same as before (in original def. without AVG).
Encryption: NONE (SSL disabled)
And for SMTP:
Server: 127.0.0.1
Port: 5200
Authentication: same as before (in original def. without AVG; in my case I point to the corresponding POP3 definition).
Encryption: NONE (SSL disabled)

In AVG for SMTP it is:
Fixed host (with port mentioned: xyz.xyz.com:465
Local port (used in e-mail client): 5200
Connection: SSL

 It could perhaps have been a change at my email provider, since I am not sure if I had authenticate settings in earlier Pegasus SMTP definition when using AV (it's there in the original definition). Maybe they allowed SMTP without authenticate for some time, then changed. I don't know how AVG passes that info. But that doesn't explain the "15: Peer connect failure (the host has refused the connection)".

---------------------
Error reports and logs:
The first error I got three weeks ago (before troubleshooting) was from the email scanner (an administrative “email” sent back to port 5100/POP3):

Undelivered Mail Returned to Sender
[…]
Cannot open SMTP connection to 'xyz.xyz.com'
HELO: > 4  command unrecognized
[…]
After that "bounce" I sent a test mail, which generated this back:
Undelivered Mail Returned to Sender
[…]
DATA: RCPT TO:<example@xyz.com> OK
[…]
---------------------
Since that day and after recreating definitions and AVG settings when sending I get the well known dialog box:

SMTP Network or Protocol Error sending mail
Hostname: 127.0.0.1
Name of SMTP profile: […]
Description of error: A network error occurred during connection to the host.

Trace showing end of transaction

15: Peer connect failure (the host has refused the connection).
---------------------
And if I create a session log, for sending it is obviously as short:
--- Fri, 17 Oct 2008 17:13:21 ---
Connect to '127.0.0.1' port 5200, timeout 30.
17:13:22.203 15: Peer connect failure (the host has refused the connection).
---------------------
Now it seems I cannot connect at all to 5200.
I have not used Telnet for years, and don't know it so well but I get:
telnet localhost 5200
Connecting to localhost...Could not open connection to the host, on port 5200: Connect failed.
---------------------
In TCPView (Sysinternals) when trying to send, the following flashes:
winpm-32.exe:2820    TCP    127.0.0.1:1306    127.0.0.1:5200    SYN_SENT    
---------------------
POP3 works all the time, and can look like this in TCPView:
winpm-32.exe:2324    TCP    127.0.0.1:1307    127.0.0.1:5100    ESTABLISHED
---------------------

Thanks in advance for any help. Sorry for the lengthy post.

I would like to ask a very much related question, to why I couldn't send using the method described above,  about authentication. Even if the problem above didn't indicate a Pegasus related problem, this forum is the only one that can give some feedback on problems when using Pegasus in combination with other software, OS, email provider etc.

At the AVG Free Anti-Virus site they mention in their FAQ for the latest version, AVG 8, under "E-mail Scanner", related to the use of authentication and some problem with "Earthlink SMTP server" (this is not my provider, but same command could be in use):

"AVG Free Edition doesn't allow you to send any e-mail through Personal e-mail scanner using the Earthlink?
This issue is not caused by the AVG E-mail Scanner, but by the properties of the Earthlink SMTP server.

Sending e-mails to the Earthlink SMTP server is not supported because the Earthlink e-mail client is using command AUTH CRAM-MD5 which is not included in the SMTP protocol specification. Only the Earthlink server understands this command, and scanning of outgoing e-mails by AVG 8.0 Free Edition cannot be used."

The solution is to deactivate the AVG proxy for sending.

Any comments on this? It perhaps isn't part of that protocol, but is the use of CRAM-MD5 uncommon? I don't know anything, or very little about CRAM-MD5.

But in a session log I can see:
250-AUTH=LOGIN\0D\0A
250-AUTH LOGIN CRAM-MD5 DIGEST-MD5 PLAIN\0D\0A

At the moment it seems:
- I can send without authentication (as a test, without AVG proxy)
- I can send without authentication (as a test, WITH AVG proxy)
- I cannot send with authentication (as a test, WITH AVG proxy)

Solution is obviously simple, do not scan outgoing, and it isn't even the default in AVG, but an outgoing proxy should not be a problem and work together with an incoming, and even if not scanning it can alert about problems. But I have it disabled now.

Any comments on this? It perhaps isn't part of that protocol, but is

the use of CRAM-MD5 uncommon? I don't know anything, or very little

about CRAM-MD5.

CRAM-MD5 is quiite common and the only really secure method of doing SMTP authentication.

Thanks for your reply.

As I mentioned I know very little about the different protocols, their extensions or a particular authentication mechanism etc. since I'm only an ordinary user.

I guess my email provider, since some time, require authentication to prevent other from using it to relay. But it doesn't explain why I can send without authentication (as a test), either it must be because it's not yet a demand, or because I'm on their net (ISP=email provider) somehow.

I understand that SMTP Authentication is a bit complex and its use depends on several things; protocols, different implementations of SASL etc.

If the AUTH mechanisms are: LOGIN, PLAIN, CRAM-MD5, the latter, as you say, must be the secure method to use.

Then it seems odd that the AVG email scanner doesn't support it.

Another question not related to my original problem, but on the subject authentication: In the message headers it is sometimes possible to see:

Received: from [...] (...) by xyz.xyz.xyz.xyz (...) (authenticated as Username)

When someone has sent a mail and used authentication, is it meant that their username should be in plain text in the message headers?

Thanks again for your comments.

I guess my email provider, since some time, require authentication to

prevent other from using it to relay. But it doesn't explain why I can

send without authentication (as a test), either it must be because it's

not yet a demand, or because I'm on their net (ISP=email provider)

somehow.

Are you testing sending to a remote address?  Authentication is not required when you are delivering mail to an account on the server. 

Then it seems odd that the AVG email scanner doesn't support it.

Nothing about any anti-virus software even surprises me anymore.  I'm not sure the people that do anti-virus POP3/IMAP4/SMTP proxies have even read the RFC.

 When someone has sent a mail and used authentication, is it meant that

their username should be in plain text in the message headers?

That depends on the SMTP server software.  However, the username actually could  be in the body of the RFC 2822 message in other places as well since it is generally (but not always) part of the senders email address.