Is dma(8) using LOGIN by default?

Status
Not open for further replies.
S

symlink

I find dma(8) quite convenient, so I'm using it also on other operating systems.
By casually observing the system log on a debian machine, I've noticed that something (I think it's cron) is desperately trying to send some email:

Dec 17 14:30:03 <hostname> dma[195472]: Server greeting successfully completed
Dec 17 14:30:03 <hostname> dma[195471]: Server does not support STARTTLS
Dec 17 14:30:03 <hostname> dma[195472]: Server does not support STARTTLS
Dec 17 14:30:03 <hostname> dma[195471]: Server supports LOGIN authentication
Dec 17 14:30:03 <hostname> dma[195472]: Server supports LOGIN authentication
Dec 17 14:30:03 <hostname> dma[195471]: using SMTP authentication for user <abridged>@fastmail.com
Dec 17 14:30:03 <hostname> dma[195472]: using SMTP authentication for user <abridged>@fastmail.com
Dec 17 14:30:05 <hostname> dma[195472]: remote delivery to smtp.fastmail.com [103.168.172.60] failed after final DATA: 551 5.7.1 Not authorised to send from this header address
Dec 17 14:30:05 <hostname> dma[195471]: remote delivery to smtp.fastmail.com [103.168.172.60] failed after final DATA: 551 5.7.1 Not authorised to send from this header address
Dec 17 14:30:05 <hostname> dma[195472]: can not bounce a bounce message, discarding
Dec 17 14:30:05 <hostname> dma[195471]: can not bounce a bounce message, discarding
Click to expand...

As I understand from the documentation, LOGIN should be the default, and STARTTLS is enabled only if the option of the same name is specified in the configuration file. Is my interpretation correct?

For the record, this problem only happens on debian: my freebsd machines work as normal. Yet it doesn't look like the debian package is patching it to behave differently.

Any idea on what is going on?
 
LOGIN should be the default, and STARTTLS is enabled only
Click to expand...

Not sure what you're getting at here. LOGIN & STARTTLS achieve different things. STARTTLS is advertised by servers that support TLS connections and I would expect dma to spot this and use TLS if possible by default as SMTP over TLS is pretty much industry standard now.

LOGIN is one of the methods an SMTP client can use to authenticate with the server. Interestingly, dma is logging that LOGIN is available even though when I just tested, smtp.fastmail.com doesn't advertise this as available unless you are using a TLS connection (a fairly standard and reasonable security measure to stop authentication over plain-text SMTP), which doesn't really match up with the "does not support STARTTLS" message. dma can't possibly know that LOGIN is available unless it has created a TLS encrypted session. The only thing I can think is that you've configured it to connect to the SMTP-TLS port (465) which is TLS by default and therefore does not advertise STARTTLS, in which case this message is irrelevant as the connection is already secure.

Either way, the main error above seems to be "Not authorised to send from this header address". This suggests that your client has connected and logged in successfully, attempted to send an email, but when getting to the final step, the server has rejected the sender address. As it has got to the DATA command, your client has already logged in and provided the sender address, recipients as well as the content of the message.

I would check what address your Debian machine is putting into the From header. It's common for SMTP servers to only allow using your registered email address in the email to stop people logging into their servers using a valid account, but then spamming out emails pretending to be from random addresses like support@microsoft.com; More often than not this is a sign of someone who's had their credentials compromised and a 3rd party is trying to send unsolicited emails via their account.
 
Status
Not open for further replies.
Back
Top