Debug SMTP component

Mail Daemon does not work well with iCloud Mail. It can receive (imap.mail.me.com:993 with TLS) but it can’t send (smtp.mail.me.com:587 with STARTTLS).
I hope this is relatively simple to fix but to do that I need to attach debugger to /boot/system/add-ons/mail_daemon/outbound_protocols/SMTP to understand what happens there.
I can attach Debugger to the image used by mail_daemon but it does not have debugging symbols and can’t link it to the source code.
Here are two questions:

  1. How do I compile just the SMTP component with debug info?
  2. How can I replace the original with it since it is on a read-only folder?

Maybe there are resources already available but I was not able to find them.
Thanks for you help!
Davide

PS: for those iCloud Mail users out there, there is a possible very dirty workaround to have iCloud work and it requires Beam.
Beam is able to send through iCloud SMTP but inbound system is broken. We can combine both and let Beam sync with the system mail folder. Use Beam then to open/read and send your emails while receiving is done by mail_daemon.
Otherwise use Claws Mail which works great with iCloud but it does not support queries, Deskbar replicant and notifications…

3 Likes

Just use launch_roster to stop the mail_daemon

then launch your own version in the terminal, this will also give you stdout to debug with.

for compoling it it should likely be goong to sec/servers/mail (or where it is exactly in the sourcetree) and doing DEBUG=1 jam.

alternatively you can use a userbuildconfig to add DEBUG for that path explicitly so it is always build like that (you van also invoke jam from the root with the component name, shoudl be DEBUG=1 jam mail_daemon iirc)

there is no need to replace the system version on the file system. If you really want to you can however blacklist the normal file in the package (probably haiku) and the add your own service that uses the mail_daemon in non-packaged/bin instead.

I know this post is a bit vague, I hope it helps you still, am not near my computer anytime soon :g

1 Like

It is very detailed, indeed. Thanks a lot!
I’ve already tried to run mail_daemon via Terminal (actually you pointed me in that direction in an old conversation) but the SMTP log doesn’t go through it, unfortunately.
The only messages I get are in a floating window. Something like “can’t connect to server” and “General OS error”, IIRC.

That’s not really the correct way to set the DEBUG variable. When you do this, you set the DEBUG variable for whatever jam needs to rebuild during this specific run. Some old targets built in release mode may be reused, so in the end you have no idea what is built in debug and what is built in release mode.

The recommended way (by me) is to use the UserBuildConfig file (build/jam/UserBuildConfig). There is a README and a sample file in that directory. There you can add invocations of SetConfigVar DEBUG to set the DEBUG variable to 1 for specific directories in the source tree (in your case src/servers/mail or src/add-ons/…/smtp).

1 Like

Gents, I successfully followed your indications and found out that the smtp connection fails very early in the process while establishing a connection with the socket:

BNetworkAddress addr(address);
	if (addr.InitCheck() != B_OK) {
		BString str;
		str.SetToFormat("Invalid network address for SMTP server: %s",
			strerror(addr.InitCheck()));
		ShowError(str.String());
		return addr.InitCheck();
	}
		
	if (addr.Port() == 0)
		addr.SetPort(port);

	if (use_ssl)
		fSocket = new(std::nothrow) BSecureSocket;
	else
		fSocket = new(std::nothrow) BSocket;
	
	if (!fSocket)
		return B_NO_MEMORY;
	
	if (fSocket->Connect(addr) != B_OK) {

I need to debug the Network Kit function, I think.
Any thoughts?

1 Like

You can extend the unit tests for the network kit :grinning:

If your unit tests depend on an external service they’re not unit tests. Socket issues are notoriously hard to debug!

Tests are overrated anyway!