Some of my users are getting Subject: failure notice emails because
someone is trying to send email as them, but is failing the
SMTP authentication... so they get the error notice.
Is there any way I can just trash these emails that are failing SMTP auth?
--tim
Greetings all:
I have 2 QMT servers that need to share a SQL (user) database. I have
tried synching them, but when the synch gets lost all hell breaks loose
and it makes me look bad. What I'd really like to do is to allow
(through IPTables) for the main mail server (where all inbound mail is
Have you looked at them?
I've only seen spam or backscatter get stranded like that.
Which queue are they in?
--
-Eric 'shubes'On 12/03/2013 08:46 PM, Linux wrote:
Eric,
It passed more than 24 hrs, but some mails are still in queue, and these
mails are important, we cannot delete.
OK, I found my own answer:
Since all I'm working with is the qmail-toaster smtp daemon, and it
uses vpopmail for auth, I found the database connection specified in
/home/vpopmail/etc/vpopmail.mysql
I changed the first 2 entries, so it reads instead:
On 12/04/2013 08:07 AM, Tim Whitaker wrote:
Some of my users are getting Subject: failure notice emails because
someone is trying to send email as them, but is failing the
SMTP authentication... so they get the error notice.
Is there any way I can just trash these emails that are failing SMTP
Thanks Dan. You beat me to it. :)
FWIW, I hope to get QMT to a point where vpopmail itself can be
implemented on its own host, and allow access via network connections
for all dependent packages (qmail, dovecot, vqadmin, qmailadmin). That's
going to take some doing, but will alleviate the
On 12/4/2013 4:31 PM, Eric Shubert wrote:
I've completed the lion's share of scripts that handle automated
builds, and all of the packages for the upcoming QMT release are
available via yum.
I'm presently beginning beta testing of the packages, and expect to be
tweaking things along the way.
