bug#35682: 27.0.50; Weird failure to authenticate in smtpmail

[Robert Pluim <rpluim@gmail.com>]

>>>>> On Sat, 11 May 2019 09:12:40 -0400, Stefan Monnier <monnier@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