GNU bug report logs - #35682
27.0.50; Weird failure to authenticate in smtpmail

Previous Next

Full log

View this message in rfc822 format

From: Robert Pluim <rpluim <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 35682 <at> debbugs.gnu.org
Subject: bug#35682: 27.0.50; Weird failure to authenticate in smtpmail
Date: Sat, 11 May 2019 16:47:09 +0200

>>>>> On Sat, 11 May 2019 09:12:40 -0400, Stefan Monnier <monnier <at> iro.umontreal.ca> said:
    >> Talk to your SMTP admin, they've messed something up. 453 is
    >> basically 'go away, Iʼm not accepting messages'. 530 is 'go
    >> away, you haven't authenticated yourself'.

    Stefan> Yet the text they return says pretty much what you
    Stefan> describe of 530.

Yes, but 

1. That text has no semantics in SMTP, itʼs only for humans
2. The extended error code they send is 4.7.1, which is 
   a) Not meant to be used with 453
   b) Means "you are not allowed to send to this specific destination"
   
They should be sending 530, like SMTP servers have forever (and then
smtpmail won't care about the specific extended error).

    >> Iʼm assuming you donʼt have an authinfo entry for this user?

    Stefan> Indeed.

    >> If I remember correctly, when you do have such an entry
    >> (including a passwordless one) smtpmail.el will proactively
    >> authenticate, rather than wait for a rejection. (see
    >> smtpmail-try-auth-methods)

    Stefan> Shouldn't smtpmail.el also proactively authenticate when
    Stefan> smtpmail-smtp-user is set?

Not unless you want to change longstanding default behaviour, Iʼm sure
people will object (although I personally think itʼs a good
change). Is there a reason you canʼt put the entry in authinfo
(without a password)?

Robert

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.