[fetchmail]Rejecting large messages when using "sendmail" for
delivery
Ed W
lists@wildgooses.com
Tue, 28 Jun 2005 23:51:22 +0100
This is a multi-part message in MIME format.
--------------090300040505000203000302
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
>No, not return codes, but MTA error codes. You need to be passing the
>email via SMTP.
>
>
?? Ehh? My first post made it clear that I wasn't passing email via SMTP
because I couldn't get the behaviour I was after (easily). You then
said I could check the spam return codes? I think my confusion is
obvious at this point?
>> The desired behaviour here is to bounce the large message...
>>
>>
>
>Which you can't do. You can either keep repolling it, or delete it.
>
>
How do I delete it (safely) bearing in mind some users may be marking
"option keep" for some servers? I sense that this isn't the correct
solution for me?
>Or, you can either increase the local limit to match the server you're
>pulling from (or talk to them about lowering theirs).
>
>
Hmm, difficult to see how I could ring up huge ISPs and persuade them
that 20Mb was the correct limit for their servers. I doubt this is a
workable suggestion in practice.
>Well, you could always provide the project with a patch :-) All I can
>do is tell you that fetchmail doesn't support the behaviour you're
>looking for.
>
>
Thanks, writing the code would of course probably be trivial.
We seem to be talking cross purposes though - at this stage I'm trying
to configure a complicated tool and have the usual pressures of time. I
was *hoping* just to get a few simple answers as to current capabilities
before I started cracking open code. Perhaps I phrased my original
question badly but I don't feel that I obtained this simple answer very
easily.
Thanks for taking the time (in the end) to clarify the current fetchmail
behaviour. Much appreciated
Ed W
--------------090300040505000203000302
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<blockquote cite="mid43ea8d070506281516376fb02a@mail.gmail.com"
type="cite">
<pre wrap="">No, not return codes, but MTA error codes. You need to be passing the
email via SMTP.
</pre>
</blockquote>
<br>
?? Ehh? My first post made it clear that I wasn't passing email via
SMTP because I couldn't get the behaviour I was after (easily). You
then said I could check the spam return codes? I think my confusion is
obvious at this point?<br>
<br>
<br>
<blockquote cite="mid43ea8d070506281516376fb02a@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">
The desired behaviour here is to bounce the large message...
</pre>
</blockquote>
<pre wrap=""><!---->
Which you can't do. You can either keep repolling it, or delete it.
</pre>
</blockquote>
<br>
How do I delete it (safely) bearing in mind some users may be marking
"option keep" for some servers? I sense that this isn't the correct
solution for me?<br>
<br>
<blockquote cite="mid43ea8d070506281516376fb02a@mail.gmail.com"
type="cite">
<pre wrap="">Or, you can either increase the local limit to match the server you're
pulling from (or talk to them about lowering theirs).
</pre>
</blockquote>
<br>
Hmm, difficult to see how I could ring up huge ISPs and persuade them
that 20Mb was the correct limit for their servers. I doubt this is a
workable suggestion in practice.<br>
<br>
<br>
<blockquote cite="mid43ea8d070506281516376fb02a@mail.gmail.com"
type="cite">
<pre wrap="">Well, you could always provide the project with a patch :-) All I can
do is tell you that fetchmail doesn't support the behaviour you're
looking for.
</pre>
</blockquote>
<br>
Thanks, writing the code would of course probably be trivial. <br>
<br>
We seem to be talking cross purposes though - at this stage I'm trying
to configure a complicated tool and have the usual pressures of time.
I was *hoping* just to get a few simple answers as to current
capabilities before I started cracking open code. Perhaps I phrased my
original question badly but I don't feel that I obtained this simple
answer very easily.<br>
<br>
Thanks for taking the time (in the end) to clarify the current
fetchmail behaviour. Much appreciated<br>
<br>
Ed W<br>
</body>
</html>
--------------090300040505000203000302--