--On 28 October 2010 23:29:33 +0400 Pavel Sutyrin <pavel.sutyrin@???>
wrote:
> On 28.10.2010 11:27:40, Ian Eiloart wrote:
>
>> Can you explain the problem more clearly, please?
>>
>> What's the connection between your Exim installation and Gmail? Oh,
>> looks like you're using Exim with mutt, to submit mail to Gmail.
>>
>> Can you include the relevant parts of your configuration file?
>
> Ian, thanks for you patience. :)
>
> Yes I'm using mutt, which sends mail to local exim, which in turn pushes
> it over to gmail smtp (TLS). Everytime when exim tries to connect
> smtp.gmail.com after some while (say, over 5 minutes after last connect),
> it is unable to authenticate and freezes the message. It logs like this:
>
> 2010-10-28 16:00:38 1PBR9j-0000YD-7G ** pavel.sutyrin@???
> R=smarthost T=remote_smtp_smarthost: SMTP error from remote mail
> server after MAIL FROM:<> SIZE=16259: host gmail-smtp-msa.l.google.com
> [74.125.79.109]: 530-5.5.1 Authentication Required. Learn more
> at\n530 5.5.1 http://mail.google.com/support/bin/answer.py?answer=14257
> x54sm730179eeh.23
>
> Then, if at once I manually force delivery of the very same message (sudo
> exim4 -M <id>), it succeeds. Looks like some timeout at the server? Gmail
> is somewhat known of such behaviour.
Well, I guess you could set auto_thaw to some low value, like 300s? That'll
be fine if you don't get lots of other messages frozen. If all you're doing
is sending to Gmail, then this should work nicely. Also, you can use
freeze_tell to get notified when your messages fail. But, if your inbox is
Gmail, this'll only keep track of what's happening after the fact.
Or, just use -qqff with your queue runner. If all your messages are routed
through Gmail, qq will be slightly faster than q, and ff will force
attempted delivery of frozen emails.
> So I see a dumb straight solution to make exim just ignore authentication
> failures at gmail (because I'm pretty sure my passwords are okay).
>
> Attached (sorry for that) are relevant parts of my .muttrc and exim
> configs, bzipped to save traffic.
>
> Thanks again,
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see
http://www.sussex.ac.uk/its/help/
