postfix, fetchmail

Üdv Mindenkinek!

Adott egy gmail-es postafiók. Arra jöttek egy bizonyos feladótól levelek melyekben mp3-ak vannak. Tegnap látszólag le is töltötte a fetchmail, de a postfix nem kézbesítette.
A logban ilyesmit olvastam:


Jul 14 18:11:13 server postfix/smtpd[26693]: NOQUEUE: reject: MAIL from localhost[127.0.0.1]: 552 5.
3.4 Message size exceeds fixed limit; proto=ESMTP helo=<server>
Jul 14 18:11:13 server postfix/smtpd[26696]: connect from localhost[127.0.0.1]
Jul 14 18:11:13 server postfix/smtpd[26696]: 5A18C26A006: client=localhost[127.0.0.1]
Jul 14 18:11:13 server postfix/cleanup[26697]: 5A18C26A006: message-id=<20080714161113.5A18C26A006@s
erver>
Jul 14 18:11:13 server postfix/qmgr[3143]: 5A18C26A006: from=<>, size=2007, nrcpt=1 (queue active)
Jul 14 18:11:13 server postfix/smtpd[26696]: disconnect from localhost[127.0.0.1]
Jul 14 18:11:14 server postfix/smtp[26698]: 5A18C26A006: to=<emailcim@gmail.com>, 
relay=pop.chello.hu[213.46.255.2]:25, delay=1.6, delays=0.08/0.04/1.3/0.15, dsn=4.1.1, 
status=deferred (host pop.chello.hu[213.46.255.2] said: 452 4.1.1 ... 
temporary failure (in reply to RCPT TO command))

A postfix-ben be volt állítva a mailbox_size_limit = 0
Hogyan lehet rávenni a fetchmailt, hogy még egyszer letöltse a gmail-ről a leveleket és a postfix pedig kézbesítse is?

2134 megtekintés

"A postfix-ben be volt állítva a mailbox_size_limit = 0"
Nem mailbox_size_limit, hanem message_size_limit problémája van, mint ahogy az RFC 1893 mutatja is:

X.3.4 Message too big for system
The message is larger than per-message size limit. This limit may either be for physical or administrative reasons. This is useful only as a permanent error.

5.X.X Permanent Failure
A permanent failure is one which is not likely to be resolved by resending the message in the current form. Some change to the message or the destination must be made for successful delivery.

"még egyszer letöltse a gmail-ről a leveleket és a postfix pedig kézbesítse is?"
Mivel permanens hibakódot adó konfigurációs beállításról van szó, ha a fetchmail nem úgy volt beállítva, hogy ne törölje a POP3 szerverről, valószínűleg sehogy.

0 szavazat

A hozzászóláshoz be kell jelentkezni

Közben a message_size_limit-re rájöttem és be is állítottam.
Viszont a fetchmail kérdés még nyitott.

Ez a beállítás a fechmailrc-ben:

poll pop.gmail.com with protocol pop3
user "username" with password "password" is "local_user" here
with options ssl flush

0 szavazat

A hozzászóláshoz be kell jelentkezni

Manual Reference Pages:

"fetchmail will always use the RETR command if "fetchall" is set. fetchmail will also use the RETR command if "keep" is set and "uidl" is unset."

"-k | --keep
(Keyword: keep) Keep retrieved messages on the remote mailserver. Normally, messages are deleted from the folder on the mailserver after they have been retrieved. Specifying the keep option causes retrieved messages to remain in your folder on the mailserver. This option does not work with ETRN or ODMR. If used with POP3, it is recommended to also specify the --uidl option or uidl keyword."

-F | --flush
POP3/IMAP only. This is a dangerous option and can cause mail loss when used improperly. It deletes old (seen) messages from the mailserver before retrieving new messages. ... What you probably want is the default setting: if you don’t specify ’-k’, then fetchmail will automatically delete messages after successful delivery.

Tehát azok az MP3-ak már elvesztek. Küldje újra a feladó, és most már a message_size_limit beállítása után be fog érkezni.

0 szavazat

A hozzászóláshoz be kell jelentkezni

A gmail-en úgy van beállítva a fiók, hogy minden levelet archiváljon. Igy minden levelet az összes levél mappába teszi be. Viszont ha visszateszem a beérkező levelek mappába és olvasatlannak jelölöm őket akkor sem szedi le újra a fetchmail.

0 szavazat

A hozzászóláshoz be kell jelentkezni

Ebből az derül ki, hogy a fetchmail tartja nyilván, hogy mit kért már le. Így hát menjünk egy bekezdést tovább a Manual Reference Pagesben:

-U | --uidl
(Keyword: uidl) Force UIDL use (effective only with POP3). Force client-side tracking of ’newness’ of messages (UIDL stands for "unique ID listing" and is described in RFC1939). Use with ’keep’ to use a mailbox as a baby news drop for a group of users. The fact that seen messages are skipped is logged, unless error logging is done through syslog while running in daemon mode. Note that fetchmail may automatically enable this option depending on upstream server capabilities. Note also that this option may be removed and forced enabled in a future fetchmail version. See also: --idfile.

Nézd meg légy szíves, hogy használ-e UIDL-t a gmail.com felé.

0 szavazat

A hozzászóláshoz be kell jelentkezni

Miután visszatetted a levelet a beérkező levelek mappába nézd meg a gmail fiókodban az alábbit:

Beállítások/Átirányítás és POP/IMAP/Letöltés POP protokollon keresztül/ A POP protokoll engedélyezése minden levélre (a már letöltöttekre is)

Ezután szerintem le tudod tölteni ismét, csak akkor arra vigyázz, ha van a rendszereden a kézbesítésnél (pl. procmail) duplikált levelekre valami beállítva, akkor annak megfelelő helyen keresd.

Egy fetchall opció sem árt a fetchmailrc-be.

Bye, Fifi

1 szavazat