|
From: Darren B. <db...@Be...> - 2010-09-18 16:31:31
|
Bug: fetchmail continues to retrieve a specific message from pop server
after SMTP server provides error that it cannot accept it (due to size)
>From fetchmail FAQ re reporting bugs:
1. Operating system: Arch Linux
2. Compiler version: N/A
Fetchmail package: Arch Linux package "fetchmail 6.3.17-1"
3. SMTP server: Arch Linux package "postfix 2.7.1-1"
4. Command Line options: -v -v -f,
options in fetchmail rc file:
poll XXXXXX
proto pop3
user AAAAAAAA is BBBBBBBBBBB here
password PPPPPPPPPP
ssl
fetchall
smtphost localhost
no rewrite
5. fetchmail -V
This is fetchmail release 6.3.17+SSL+NLS.
6. Fetchmail output (1):
This is all the log information I have for the actual issue without
recreating the situation.
fetchmail: SMTP< 220 XXXXXXXX.YYYYY.ca ESMTP Postfix
fetchmail: SMTP> EHLO XXXXXXXX.YYYYY.ca
fetchmail: SMTP< 250-XXXXXXXX.YYYYY.ca
fetchmail: SMTP< 250-PIPELINING
fetchmail: SMTP< 250-SIZE 2097152
fetchmail: SMTP< 250-VRFY
fetchmail: SMTP< 250-ETRN
fetchmail: SMTP< 250-ENHANCEDSTATUSCODES
fetchmail: SMTP< 250-8BITMIME
fetchmail: SMTP< 250 DSN
fetchmail: forwarding to localhost
fetchmail: SMTP> MAIL FROM:<XXXXXX@XXXXXXXXXXXX> SIZE=3091253
fetchmail: SMTP< 452 4.3.4 Message size exceeds fixed limit
fetchmail: SMTP error: 452 4.3.4 Message size exceeds fixed limit
fetchmail: SMTP> RSET
fetchmail: SMTP< 250 2.0.0 Ok
............................................................................
.....
... Multiple lines ...
............................................................................
.....
not flushed
fetchmail: POP3> QUIT
fetchmail: POP3< +OK Logging out.
fetchmail: SMTP> QUIT
fetchmail: SMTP< 221 2.0.0 Bye
Fetchmail output (2):
This is a -vvv log for complete interaction details for POP server,
although not likely relevant for my claim:
$ LC_ALL=C fetchmail --nodetach -vvv --nosyslog -f .fetchfile
Old UID list from mail.XXXXXXXXXX.com: <empty>
Scratch list of UIDs: <empty>
fetchmail: 6.3.17 querying mail.XXXXXXXXXX.com (protocol POP3) at
Fri Sep 17 22:47:34 2010: poll started
Trying to connect to ---.--.--.128/995...connected.
fetchmail: Certificate chain, from root to peer, starting at depth
1:
fetchmail: Issuer Organization: Equifax
fetchmail: Unknown Issuer CommonName
fetchmail: Server certificate:
fetchmail: Issuer Organization: Equifax
fetchmail: Unknown Issuer CommonName
fetchmail: Subject CommonName: *.XXXXXXXXXX.com
fetchmail: mail.XXXXXXXXXX.com key fingerprint:
B9:DE:3F:47:D5:6E:9D:AA:EA:72:EA:4F:37:EA:1C:B8
fetchmail: POP3< +OK POP3 ready
fetchmail: POP3> CAPA
fetchmail: POP3< +OK Capability list follows
fetchmail: POP3< TOP
fetchmail: POP3< UIDL
fetchmail: POP3< RESP-CODES
fetchmail: POP3< PIPELINING
fetchmail: POP3< USER
fetchmail: POP3< SASL PLAIN LOGIN
fetchmail: POP3< SASL LOGIN PLAIN
fetchmail: POP3< .
fetchmail: POP3> USER HIDDEN-USER@HIDDEN-DOMAIN
fetchmail: POP3< +OK
fetchmail: POP3> PASS *
fetchmail: POP3< +OK Logged in.
fetchmail: selecting or re-polling default folder
fetchmail: POP3> STAT
fetchmail: POP3< +OK 0 0
fetchmail: No mail for HIDDEN-USER@HIDDEN-DOMAIN at
mail.XXXXXXXXXX.com
fetchmail: POP3> QUIT
fetchmail: POP3< +OK Logging out.
fetchmail: 6.3.17 querying mail.XXXXXXXXXX.com (protocol POP3) at
Fri Sep 17 22:47:35 2010: poll completed
New UID list from mail.XXXXXXXXXX.com: <empty>
fetchmail: not swapping UID lists, no UIDs seen this query
fetchmail: Query status=1 (NOMAIL)
fetchmail: normal termination, status 1
Referring to fetchmail log (1) above, the issue is "fetchmail continues to
retrieve a specific message from pop server after SMTP server provides error
that it cannot accept it (due to size)"
This claim being made from interpreting the log in that it appears:
A) fetchmail connected to the SMTP server before retrieving message from
pop server, advising smtp server of the message size.
B) smtp server returned error as it's message size limit was 2MB, and the
message in this case was ~3MB
C) fetchmail still retrieved the message item from the pop server, to only
have it discarded locally
D) fetchmail must have figured out something was wrong and it did not flush
the item from the pop server, leaving it there for the scenario to repeat
over and over again until it was detected.
I assert that SMTP error 452 4.3.4 should trigger fetchmail to not RETR or
DELE the message. It has it half right in that it does NOT DELE it. It's
just wasting time and resources to RETR it as well.
--
Darren
|